[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 262292] Seemingly not possible for IPv6 to function over tap devices on if_bridge"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 02 Mar 2022 09:32:01 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262292 Bug ID: 262292 Summary: Seemingly not possible for IPv6 to function over tap devices on if_bridge Product: Base System Version: 13.0-STABLE Hardware: amd64 OS: Any Status: New Keywords: bhyve, ipv6 Severity: Affects Only Me Priority: --- Component: bhyve Assignee: virtualization@FreeBSD.org Reporter: paul.g.webster@googlemail.com Good day all, I run a set of VM's on an if_bridge: 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> IPv4 functionality is working as expected, and ipv6 on the host works perfectly. However no guest may ping6 its closest host inet6 address (tap1033->bridge103) and get a response. tcpdump reveals that bridge103 received the request, but does not appear to do anything about it: 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 The same is true for all other VM's that are connected via virtio/tap to an if_bridge, bearing in mind the ICMP request is seen perhaps the problem is with if_bridge. Unfortunatly I am now somewhat out of my depth with bhyve/if_bridge_tap, I have tried everything I can possible think of and am hoping someone here knows what is causing such an issue. Notable the inet6 that is directly assigned to each bridge is reachable from the outside, that would be these: em0: inet6 2a01:4f8:190:1183::1:1 prefixlen 64 lo0: inet6 ::1 prefixlen 128 bridge102: inet6 2a01:4f8:190:1183::102:1 prefixlen 64 bridge103: inet6 2a01:4f8:190:1183::103:1 prefixlen 64 bridge104: inet6 2a01:4f8:190:1183::104:1 prefixlen 64 As the VM in the above examples was 2a01:4f8:190:1183::103:2 assigned to bridge 103, there should be no way it failed to get a response that I can see -- You are receiving this mail because: You are the assignee for the bug.