----- Original Message ----- > From: "Linus Lüssing" <linus.luessing@xxxxxx> > To: "Jan Stancek" <jstancek@xxxxxxxxxx> > Cc: netdev@xxxxxxxxxxxxxxx, "Florian Westphal" <fwestpha@xxxxxxxxxx>, bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > Sent: Monday, 3 March, 2014 10:27:59 PM > Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest > > 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? Yes, host B should be behind eno1 (All hosts are remote to me). There should be only single bridge on host A. Host A has 3 more interfaces but those are all down. # cat /etc/sysconfig/network-scripts/ifcfg-eno1 DEVICE=eno1 ONBOOT=yes BRIDGE=br1 HWADDR=00:23:ae:ed:1a:00 # cat /etc/sysconfig/network-scripts/ifcfg-br1 DEVICE=br1 BOOTPROTO=dhcp ONBOOT=yes TYPE=Bridge DELAY=0 There is also bridge on host B. I assume that doesn't matter but I could set up host B without bridge if needed. > > 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. Here are tcpdumps from hostA, hostB and guest (on hostA): http://jan.stancek.eu/tmp/neigh_solicit_and_bridge_traces1/ I didn't apply any filter, because that multicast query wasn't showing up for some reason when I tried to filter by icmp6. What I did: 1. started tcpdump on all systems 2. send 3 neigh. solicit from hostB manually with couple seconds in between 3. send multicast listener query from hostB manually 4. send 5 neigh. solicit from hostB manually with couple seconds in between hostA.cap tcpdump -i eno1 -w hostA.cap frame 124, 125 -> OK frame 217, 218 -> OK frame 291, 292 -> OK frame 373 -> Multicast Listener Query frame 484 -> no reply? frame 572 -> no reply? frame 665 -> no reply? hostB.cap tcpdump -i br0 -w hostB.cap frame 106, 108 -> OK frame 214, 216 -> OK frame 300, 302 -> OK frame 396 -> Multicast Listener Query frame 523 -> no reply? frame 623 -> no reply? frame 730 -> no reply? guest.cap tcpdump -i eth0 -w guest.cap frame 89, 90 -> OK frame 181, 182 -> OK frame 254, 255 -> OK frame 334 -> Multicast Listener Query no more neigh. solicit packets > > 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'm no expert in this area, but shouldn't neigh. solicit packets be forwarded to all ports regardless of any/no MLD reports? Regards, Jan > > > Thanks for the detailed report so far! > > Cheers, Linus >
