Linus Lüssing
2014-Mar-05 14:27 UTC
[Bridge] bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
On Wed, Mar 05, 2014 at 07:10:07AM -0500, Jan Stancek wrote:> > > ----- Original Message ----- > > From: "Linus L?ssing" <linus.luessing at web.de> > > To: "Jan Stancek" <jstancek at redhat.com> > > Cc: netdev at vger.kernel.org, "Florian Westphal" <fwestpha at redhat.com>, bridge at lists.linux-foundation.org > > Sent: Tuesday, 4 March, 2014 10:37:57 PM > > Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest > > > I'm not sure if it's Linux (I'm trying to locate that system by MAC), but I > > > see > > > packets like these on my network every ~125 seconds: > > > > > > No. Time Source Destination Protocol > > > Length Info > > > 22675 1334.751135 :: ff02::1 ICMPv6 86 > > > Multicast Listener Query > > > > It's probably the bridge on this ancient kernel, you might want to > > backport the following patch: > > Hi, > > The example above was from box, which turned out not be running Linux.Okay, yeah, there's somehow the misconception flying around, that a snooping switch could use "::" as a source address. Even the informational RFC4541 writes about "proxy IGMP queries" disregarding the source address requirements for MLDv1/2, feeding this misconception. I just skimmed RFC4605 ("IGMP/MLD Proxying") briefly, but couldn't find any note for "0.0.0.0" or "::" there. But I think we could see with your practical example, that "::" MLD query source addresses should be considered broken.> > > > > If these patches on host B xor the sanity check I just submitted applied > > on your host A / VM host fix your issue, then they might be worth > > considering for the stable queue. > > Is it necessary to apply same patch also on any (older) kernel running in VM?The source address patches are only required on boxes where the internal MLD querier code of the bridge is used. Afaik tell the source address patch is present on all kernels since v2.6.38 and all kernels listed on the kernel.org frontpage, except 2.6.34.15 and 2.6.32.61. For the sanity check patch, it should probably be added to any kernel having a bridge (though in your particular scenario and what we are currently debugging at, having it on host A should be sufficient).> I hand-crafted one new packet from malformed one used in previous tests. > I modified source address from :: to host B link-scope address and changed > dst address from ff02::1 to ff02::1:ffaa:aaaaOkay, again according to your capture the guest is receiving the MLD query on its interface but does not react with an MLD report. Two things I'd like to know: Is using the link-scope address as a source and "ff02::1" as the destination address for the MLD query work for you? Is using the link-scope address as a source and "ff02::1:ff00:29" as the destination address for the MLD query "work" for you (do we see an MLD report from the guest and keep on seeing neighbor solicitations from host B then?). For the latter, I don't see anything in particular filtering these for a general MLD query wrong destination address in the IPv6 code from igmp6_event_query() on. But I suspect that the query doesn't even get that far on the kernel of the guest, as it is not listening on ff02::1:ffaa:aaaa. Therefore the test with "ff02::1:ff00:29", an address the guest is listening on, would be interesting. If that works, then I'm going to make a patch ignore General MLD Queries without ff02::1 as their destination address, too. Hm, looking at more checks in igmp6_event_query(), I'm currently wondering whether we should only enable the snooping behaviour in the bridge when receiving a General MLD Query, so one with "::" in the multicast field of the MLD message, instead of activating it upon a Multicast-Address-Specific Query, too. That'd seem more sane to me, I'm going to make a patch for that tomorrow. Cheers, Linus
Jan Stancek
2014-Mar-05 14:57 UTC
Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
----- Original Message -----> From: "Linus Lüssing" <linus.luessing@web.de> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: netdev@vger.kernel.org, "Florian Westphal" <fwestpha@redhat.com>, bridge@lists.linux-foundation.org > Sent: Wednesday, 5 March, 2014 3:27:07 PM > Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest<snip>> > > I hand-crafted one new packet from malformed one used in previous tests. > > I modified source address from :: to host B link-scope address and changed > > dst address from ff02::1 to ff02::1:ffaa:aaaa > > Okay, again according to your capture the guest is receiving the > MLD query on its interface but does not react with an MLD report. > > Two things I'd like to know: > > Is using the link-scope address as a source and "ff02::1" as the > destination address for the MLD query work for you?Yes, I could not trigger it with such query: http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1.cap frame 795 -> query frame 1040 -> MLD report from guest ~20 seconds later frame 1507, 1508 -> neigh solicit/advert frame 1580, 1581 -> neigh solicit/advert> > Is using the link-scope address as a source and "ff02::1:ff00:29" > as the destination address for the MLD query "work" for you (do > we see an MLD report from the guest and keep on seeing neighbor > solicitations from host B then?).Yes, this also worked (though I received 2 reports): http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1_ff0029.cap frame 446 -> query frame 448 -> MLD report from guest frame 465 -> MLD report from guest frame 689, 690 -> neigh solicit/advert frame 760, 761 -> neigh solicit/advert ... Both host and guest were running 3.14.0-rc5 with your sanity check patch. Regards, Jan> > For the latter, I don't see anything in particular filtering these > for a general MLD query wrong destination address in the IPv6 > code from igmp6_event_query() on. But I suspect that the query > doesn't even get that far on the kernel of the guest, as it is not > listening on ff02::1:ffaa:aaaa. Therefore the test with > "ff02::1:ff00:29", an address the guest is listening on, would be > interesting. > > If that works, then I'm going to make a patch ignore General MLD > Queries without ff02::1 as their destination address, too. > > > Hm, looking at more checks in igmp6_event_query(), I'm currently > wondering whether we should only enable the snooping behaviour in > the bridge when receiving a General MLD Query, so one with "::" in > the multicast field of the MLD message, instead of activating it > upon a Multicast-Address-Specific Query, too. That'd seem more > sane to me, I'm going to make a patch for that tomorrow. > > Cheers, Linus >
Jan Stancek
2014-Mar-05 14:57 UTC
[Bridge] bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
----- Original Message -----> From: "Linus L?ssing" <linus.luessing at web.de> > To: "Jan Stancek" <jstancek at redhat.com> > Cc: netdev at vger.kernel.org, "Florian Westphal" <fwestpha at redhat.com>, bridge at lists.linux-foundation.org > Sent: Wednesday, 5 March, 2014 3:27:07 PM > Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest<snip>> > > I hand-crafted one new packet from malformed one used in previous tests. > > I modified source address from :: to host B link-scope address and changed > > dst address from ff02::1 to ff02::1:ffaa:aaaa > > Okay, again according to your capture the guest is receiving the > MLD query on its interface but does not react with an MLD report. > > Two things I'd like to know: > > Is using the link-scope address as a source and "ff02::1" as the > destination address for the MLD query work for you?Yes, I could not trigger it with such query: http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1.cap frame 795 -> query frame 1040 -> MLD report from guest ~20 seconds later frame 1507, 1508 -> neigh solicit/advert frame 1580, 1581 -> neigh solicit/advert> > Is using the link-scope address as a source and "ff02::1:ff00:29" > as the destination address for the MLD query "work" for you (do > we see an MLD report from the guest and keep on seeing neighbor > solicitations from host B then?).Yes, this also worked (though I received 2 reports): http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces2/guest_mld_query_ff02_1_ff0029.cap frame 446 -> query frame 448 -> MLD report from guest frame 465 -> MLD report from guest frame 689, 690 -> neigh solicit/advert frame 760, 761 -> neigh solicit/advert ... Both host and guest were running 3.14.0-rc5 with your sanity check patch. Regards, Jan> > For the latter, I don't see anything in particular filtering these > for a general MLD query wrong destination address in the IPv6 > code from igmp6_event_query() on. But I suspect that the query > doesn't even get that far on the kernel of the guest, as it is not > listening on ff02::1:ffaa:aaaa. Therefore the test with > "ff02::1:ff00:29", an address the guest is listening on, would be > interesting. > > If that works, then I'm going to make a patch ignore General MLD > Queries without ff02::1 as their destination address, too. > > > Hm, looking at more checks in igmp6_event_query(), I'm currently > wondering whether we should only enable the snooping behaviour in > the bridge when receiving a General MLD Query, so one with "::" in > the multicast field of the MLD message, instead of activating it > upon a Multicast-Address-Specific Query, too. That'd seem more > sane to me, I'm going to make a patch for that tomorrow. > > Cheers, Linus >