From patchwork Mon Mar 3 19:47:15 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jan Stancek X-Patchwork-Id: 326048 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id BA3A62C00C2 for ; Tue, 4 Mar 2014 06:47:23 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754868AbaCCTrR (ORCPT ); Mon, 3 Mar 2014 14:47:17 -0500 Received: from mx3-phx2.redhat.com ([209.132.183.24]:45057 "EHLO mx3-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754040AbaCCTrQ convert rfc822-to-8bit (ORCPT ); Mon, 3 Mar 2014 14:47:16 -0500 Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s23JlFRr026033; Mon, 3 Mar 2014 14:47:15 -0500 Date: Mon, 3 Mar 2014 14:47:15 -0500 (EST) From: Jan Stancek To: linus.luessing@web.de, netdev@vger.kernel.org, Florian Westphal Message-ID: <2107636851.12713862.1393876035292.JavaMail.zimbra@redhat.com> In-Reply-To: <1566805413.12693479.1393872931017.JavaMail.zimbra@redhat.com> Subject: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest MIME-Version: 1.0 X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF27 (Win)/8.0.6_GA_5922) Thread-Topic: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest Thread-Index: hVsg7SmngXDvMffPuYwSIAzZyav3cQ== Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi, I have a host A running 3.14.0-rc5 with one KVM guest, where network is set up to use bridge: # brctl show bridge name bridge id STP enabled interfaces br1 8000.0023aeed1a00 no eno1 vnet0 virbr0 8000.000000000000 yes 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. I was trying to narrow down conditions when this happens and eventually came to following packet sent by other host B on same network: Ethernet II, Src: Hewlett-_47:93:1c (00:21:5a:47:93:1c), Dst: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) Destination: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) Address: IPv6mcast_00:00:00:01 (33:33:00:00:00:01) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: Hewlett-_47:93:1c (00:21:5a:47:93:1c) Address: Hewlett-_47:93:1c (00:21:5a:47:93:1c) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: 100:0:600:0:78fb:100:: (100:0:600:0:78fb:100::), Dst: ff02::1 (ff02::1) 0110 .... = Version: 6 [0110 .... = This field makes the filter "ip.version == 6" possible: 6] .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000 .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000) .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set .... .... ...0 .... .... .... .... .... = ECN-CE: Not set .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 32 Next header: IPv6 hop-by-hop option (0) Hop limit: 1 Source: 100:0:600:0:78fb:100:: (100:0:600:0:78fb:100::) Destination: ff02::1 (ff02::1) Hop-by-Hop Option Next header: ICMPv6 (58) Length: 0 (8 bytes) IPv6 Option (Router Alert) Type: Router Alert (5) Length: 2 Router Alert: MLD (0) IPv6 Option (Pad1) Type: Pad1 (0) Pad1 IPv6 Option (Pad1) Type: Pad1 (0) Pad1 Internet Control Message Protocol v6 Type: Multicast Listener Query (130) Code: 0 Checksum: 0xf9c5 [correct] Maximum Response Delay [ms]: 1000 Reserved: 0000 Multicast Address: :: (::) 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. 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 I also found out that issue goes away if I do any of following: 1. disable CONFIG_BRIDGE_IGMP_SNOOPING=y 2. echo 0 > /sys/devices/virtual/net/br1/bridge/multicast_snooping 3. make following change: Change above makes me suspect following patch: commit 3c3769e63301fd92fcaf51870c371583dd0282ce Author: Linus Lüssing Date: Wed Sep 4 02:13:39 2013 +0200 bridge: apply multicast snooping to IPv6 link-local, too Please let me know if I can assist in any way to help resolve this. Regards, Jan --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c index ef66365..8ccc0bf 100644 --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -1562,8 +1562,8 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br, return 0; /* 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 (!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)