Vlad Yasevich
2014-Mar-03 21:40 UTC
[Bridge] bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
On 03/03/2014 04:27 PM, Linus L?ssing wrote:> Hi Jan, > > On Mon, Mar 03, 2014 at 02:47:15PM -0500, Jan Stancek wrote: >> I'm seeing an issue where bridge (sometimes) stops forwarding ICMP6 >> neighbor solicitation packets to KVM guest and as result KVM guest doesn't >> respond with neighbor advertisement. > > Hm, okay, that's not supposed to happen. > >> The reason I think this packet is related is because when I send same exact >> packet I'm often hitting same issue - bridge stops forwarding ICMP6 neigh. >> solicitation packets to KVM guest. > > Yes, the MLD query is kicking the multicast snooping into gear. If > there's never a query, then snooping is basically disabled > (compare: "bridge: disable snooping if there is no querier"). > >> >> My current way to reproduce this is: >> 0. host B IP / MAC is: 2620:52:0:1040:221:5aff:fe47:931c / 00:21:5a:47:93:1c >> guest IP / MAC is: 2620:52:0:1040:5056:ff:fe00:29 / 52:56:00:00:00:29 >> 1. host B is sending neigh solicit packets every 5 seconds with KVM guest IP >> using ns6 from ipv6toolkit: http://www.si6networks.com/tools/ipv6toolkit/ >> with parameters: >> --src-address=2620:52:0:1040:221:5aff:fe47:931c --dst-address=ff02::1:ff00:0029 >> -t 2620:52:0:1040:5056:ff:fe00:29 --link-src-address=00:21:5a:47:93:1c >> --source-lla-opt=00:21:5a:47:93:1c --link-dst-address=33:33:ff:00:00:29 >> tcpdump running on guest can see both solicit and advertisement packets >> 2. wait ~5 minutes >> 3. host B sends Multicast Listener Query packet described above >> 4. tcpdump running on guest is no longer seeing any neigh solicit packets > > Just to clarify, host B is behind eno1 and vnet0 is directly > connected to the interface of the guest, no additional bridge or > anything else on top of that, right? > > Would it be possible for you to upload the tcpdumps from host B > (or if you can't tcpdump on host B, then capturing on eno1) > and the guest somewhere and saying at which time/packet in the dumps > it stops working (probably ~10 seconds after the query). Filtering > for ICMPv6 should be sufficient. > > What I'm curious about is, whether the guest receives > the MLD query and responds with an MLD report. I suspect that > either the bridge doesn't get an MLD report and therefore is > shutting down the according port or there's a bug in parsing the > MLD report in the bridge code. >I did notice a minor issue in the bridge code. The following code: /* Prevent flooding this packet if there is no listener present */ if (!ipv6_addr_is_ll_all_nodes(&ip6h->daddr)) BR_INPUT_SKB_CB(skb)->mrouters_only = 1; if (ip6h->nexthdr != IPPROTO_HOPOPTS || ip6h->payload_len == 0) return 0; will mark most multicast traffic is mrouters_only. The two statement should be probably be reversed. However, that's shouldn't cause the reported problem. -vlad> > Thanks for the detailed report so far! > > Cheers, Linus >
Linus Lüssing
2014-Mar-03 23:03 UTC
[Bridge] bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
On Mon, Mar 03, 2014 at 04:40:40PM -0500, Vlad Yasevich wrote:> I did notice a minor issue in the bridge code. The following > code: > /* Prevent flooding this packet if there is no listener present */ > if (!ipv6_addr_is_ll_all_nodes(&ip6h->daddr)) > BR_INPUT_SKB_CB(skb)->mrouters_only = 1; > > if (ip6h->nexthdr != IPPROTO_HOPOPTS || > ip6h->payload_len == 0) > return 0; > > will mark most multicast traffic is mrouters_only. The two > statement should be probably be reversed. However, that's shouldn't > cause the reported problem.Reversing the order of these two if-clauses would reintroduce the issue this commit tried to address, I think: "bridge: prevent flooding IPv6 packets that do not have a listener" Besides, I don't quite see what minor issue you are refering to, would you mind being a little more verbose? Cheers, Linus PS: mrouters_only has a kind of confusing naming... for MLD/IGMP packets it means sending to multicast routers only, there the name fits. But for non-MLD/IGMP packets it means something else since "bridge: Only flood unregistered groups to routers" (and I went along with it with "bridge: prevent flooding IPv6 packets that do not have a listener"), there it means dropping the skb if there is no router or matching listener. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bridge/attachments/20140304/2d029741/attachment.sig>