Date: Sat, 26 Feb 2022 19:13:23 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 233683] IPv6 ND neighbor solicitation messages fail to arrive Message-ID: <bug-233683-7501-dt7rvoTpnI@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233683-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-233683-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233683 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 th= ree bridges: bridge102: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mt= u 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=3D63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR> bridge103: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mt= u 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=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 9 priority 128 path cost 2000000 member: tap1032 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 8 priority 128 path cost 2000000 member: tap1031 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 11 priority 128 path cost 2000000 member: tap1030 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 10 priority 128 path cost 2000000 groups: bridge nd6 options=3D63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR> bridge104: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mt= u 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=3D63<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_RADR> Any vm though, that is attached in this case to bridge103;=20 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=3D40+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, becaus= e it simply does not know who 2a01:4f8:190:1183::103:2 is, despite it being a br= idge member. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233683-7501-dt7rvoTpnI>