netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: linus.luessing@web.de, netdev@vger.kernel.org,
	Florian Westphal <fwestpha@redhat.com>
Subject: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
Date: Mon, 3 Mar 2014 14:47:15 -0500 (EST)	[thread overview]
Message-ID: <2107636851.12713862.1393876035292.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <1566805413.12693479.1393872931017.JavaMail.zimbra@redhat.com>

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:
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)

Change above makes me suspect following patch:
  commit 3c3769e63301fd92fcaf51870c371583dd0282ce
  Author: Linus Lüssing <linus.luessing@web.de>
  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

       reply	other threads:[~2014-03-03 19:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1566805413.12693479.1393872931017.JavaMail.zimbra@redhat.com>
2014-03-03 19:47 ` Jan Stancek [this message]
2014-03-03 21:27   ` bridge is not forwaring ICMP6 neighbor solicitation to KVM guest Linus Lüssing
2014-03-03 21:40     ` Vlad Yasevich
2014-03-03 23:03       ` Linus Lüssing
2014-03-03 22:45     ` Jan Stancek
2014-03-04  0:00       ` Linus Lüssing
2014-03-04  8:02         ` Jan Stancek
2014-03-04 10:52           ` Linus Lüssing
2014-03-04 11:06             ` Jan Stancek
2014-03-04 21:37               ` Linus Lüssing
2014-03-05 12:10                 ` Jan Stancek
2014-03-05 14:27                   ` Linus Lüssing
2014-03-05 14:57                     ` Jan Stancek
2014-03-12  4:37                       ` Linus Lüssing
2014-03-12  7:45                         ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2107636851.12713862.1393876035292.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=fwestpha@redhat.com \
    --cc=linus.luessing@web.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).