[Bug 233683] IPv6 ND neighbor solicitation messages fail to arrive

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233683

Paul Webster <paul.g.webster@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul.g.webster@googlemail.c
                   |                            |om

--- Comment #3 from Paul Webster <paul.g.webster@googlemail.com> ---
I also appear to be suffering from this same problem.

I have a /64 assigned to my host (which works perfectly fine) as well as three
bridges:


bridge102: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:ff:e2
        inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255
        inet6 fe80::5a9c:fcff:fe10:ffe2%bridge102 prefixlen 64 scopeid 0x3
        inet6 2a01:4f8:190:1183::102:1 prefixlen 64
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        groups: bridge
        nd6 options=63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR>
bridge103: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:ff:f5
        inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255
        inet6 fe80::5a9c:fcff:fe10:fff5%bridge103 prefixlen 64 scopeid 0x4
        inet6 2a01:4f8:190:1183::103:1 prefixlen 64
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap1033 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 9 priority 128 path cost 2000000
        member: tap1032 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 2000000
        member: tap1031 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 11 priority 128 path cost 2000000
        member: tap1030 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 10 priority 128 path cost 2000000
        groups: bridge
        nd6 options=63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR>
bridge104: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:00:05:61
        inet 192.168.104.1 netmask 0xffffff00 broadcast 192.168.104.255
        inet6 fe80::5a9c:fcff:fe00:561%bridge104 prefixlen 64 scopeid 0x5
        inet6 2a01:4f8:190:1183::104:1 prefixlen 64
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        groups: bridge
        nd6 options=63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR>


Any vm though, that is attached in this case to bridge103; 
        inet6 2a01:4f8:190:1183::103:1 prefixlen 64


cannot even ping '2a01:4f8:190:1183::103:1'; given these commands in the vm:
  ifconfig vtnet0 inet6 2a01:4f8:190:1183::103:2 prefixlen 64

It should be able to ping 2a01:4f8:190:1183::103:1 irregardless, however.
  root@sitehost:/var # ping6 2a01:4f8:190:1183::103:1
  PING6(56=40+8+8 bytes) 2a01:4f8:190:1183::103:2 --> 2a01:4f8:190:1183::103:1

And the host:
root@de1:/usr/venv/bhyve/init # tcpdump -vvi bridge103 icmp6
tcpdump: listening on bridge103, link-type EN10MB (Ethernet), capture size
262144 bytes
20:11:53.073960 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2a01:4f8:190:1183::103:2 > ff02::1:ff03:1: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2a01:4f8:190:1183::103:1
          source link-address option (1), length 8 (1): 00:d3:4d:be:3f:ab
            0x0000:  00d3 4dbe 3fab
20:11:54.120586 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2a01:4f8:190:1183::103:2 > ff02::1:ff03:1: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2a01:4f8:190:1183::103:1
          source link-address option (1), length 8 (1): 00:d3:4d:be:3f:ab
            0x0000:  00d3 4dbe 3fab
20:11:56.214303 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32)
2a01:4f8:190:1183::103:2 > ff02::1:ff03:1: [icmp6 sum ok] ICMP6, neighbor
solicitation, length 32, who has 2a01:4f8:190:1183::103:1
          source link-address option (1), length 8 (1): 00:d3:4d:be:3f:ab
            0x0000:  00d3 4dbe 3fab


It is plain to see that the bridge device has no idea how to answer, because it
simply does not know who 2a01:4f8:190:1183::103:2 is, despite it being a bridge
member.

-- 
You are receiving this mail because:
You are the assignee for the bug.