From: "H. Peter Anvin" <hpa@zytor.com>
To: "Linus Lüssing" <linus.luessing@web.de>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.hengli.com.au>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] Multicast snooping fixes and suggestions
Date: Wed, 23 Feb 2011 19:16:17 -0800 [thread overview]
Message-ID: <4D65CD81.4070203@zytor.com> (raw)
In-Reply-To: <1297811961-19249-1-git-send-email-linus.luessing@web.de>
On 02/15/2011 03:19 PM, Linus Lüssing wrote:
> Hello everyone,
>
> While testing the (very awesome!) bridge igmp/mld snooping support I came across
> two issues which are breaking IPv6 multicast snooping and IPv6
> non-link-local multicast on bridges with multicast snooping support enabled
> in general. The first two patches shall fix these issues.
>
> The third one addresses a potential bug on little endian machines which I noticed
> during this little code reviewing. This patch is untested though, feedback welcome.
>
> The fourth and fifth patch are a suggestion to also permit using the bridge multicast
> snooping feature for link local multimedia multicast traffic. Therefore
> using the transient multicast flag instead of the non-link-local scope criteria
> seems to be a suitable solution at least for IPv6, in my opinion. Let me know what
> you think about it.
>
Hello,
I have just noticed that when using a Linux bridge, IPv6 often fails to
configure until some considerable time has passed, presumably some kind
of retry timer. The dmesg shows:
[178292.449300] br0: port 1(eth0) entering learning state
[178292.449304] br0: port 1(eth0) entering learning state
[178302.536098] br0: no IPv6 routers present
[178307.416139] br0: port 1(eth0) entering forwarding state
... even though there is a configured and active IPv6 router on the network.
I have also seen some serious delays with DHCPv4 which presumably is due
to lost packets during bridge learning.
Are these packets likely to address that situation (or am I just plain
doing something stupid)?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Linus Lüssing" <linus.luessing@web.de>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.hengli.com.au>
Subject: Re: Multicast snooping fixes and suggestions
Date: Wed, 23 Feb 2011 19:16:17 -0800 [thread overview]
Message-ID: <4D65CD81.4070203@zytor.com> (raw)
In-Reply-To: <1297811961-19249-1-git-send-email-linus.luessing@web.de>
On 02/15/2011 03:19 PM, Linus Lüssing wrote:
> Hello everyone,
>
> While testing the (very awesome!) bridge igmp/mld snooping support I came across
> two issues which are breaking IPv6 multicast snooping and IPv6
> non-link-local multicast on bridges with multicast snooping support enabled
> in general. The first two patches shall fix these issues.
>
> The third one addresses a potential bug on little endian machines which I noticed
> during this little code reviewing. This patch is untested though, feedback welcome.
>
> The fourth and fifth patch are a suggestion to also permit using the bridge multicast
> snooping feature for link local multimedia multicast traffic. Therefore
> using the transient multicast flag instead of the non-link-local scope criteria
> seems to be a suitable solution at least for IPv6, in my opinion. Let me know what
> you think about it.
>
Hello,
I have just noticed that when using a Linux bridge, IPv6 often fails to
configure until some considerable time has passed, presumably some kind
of retry timer. The dmesg shows:
[178292.449300] br0: port 1(eth0) entering learning state
[178292.449304] br0: port 1(eth0) entering learning state
[178302.536098] br0: no IPv6 routers present
[178307.416139] br0: port 1(eth0) entering forwarding state
... even though there is a configured and active IPv6 router on the network.
I have also seen some serious delays with DHCPv4 which presumably is due
to lost packets during bridge learning.
Are these packets likely to address that situation (or am I just plain
doing something stupid)?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2011-02-24 3:16 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-15 23:19 [Bridge] Multicast snooping fixes and suggestions Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` [Bridge] [PATCH 1/5] bridge: Fix IPv6 multicast snooping by storing correct protocol type Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` [Bridge] [PATCH 2/5] bridge: Fix IPv6 multicast snooping by correcting offset in MLDv2 report Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` [Bridge] [PATCH 3/5] bridge: Add missing ntohs()s for MLDv2 report parsing Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` [Bridge] [PATCH 4/5] ipv6: Add IPv6 multicast address flag defines Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` [Bridge] [PATCH 5/5] bridge: Allow mcast snooping for transient link local addresses too Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:19 ` Linus Lüssing
2011-02-15 23:41 ` [Bridge] Multicast snooping fixes and suggestions Stephen Hemminger
2011-02-15 23:41 ` Stephen Hemminger
2011-02-17 18:17 ` [Bridge] " Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-17 18:17 ` [Bridge] [PATCH 1/2] bridge: Fix MLD queries' ethernet source address Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-22 18:08 ` [Bridge] " David Miller
2011-02-22 18:08 ` David Miller
2011-02-22 18:08 ` David Miller
2011-02-17 18:17 ` [Bridge] [PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener queries Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-17 18:17 ` Linus Lüssing
2011-02-22 18:08 ` [Bridge] " David Miller
2011-02-22 18:08 ` David Miller
2011-02-22 18:08 ` David Miller
2011-02-22 18:08 ` [Bridge] Multicast snooping fixes and suggestions David Miller
2011-02-22 18:08 ` David Miller
2011-02-22 18:08 ` David Miller
2011-02-24 3:16 ` H. Peter Anvin [this message]
2011-02-24 3:16 ` H. Peter Anvin
2011-02-24 4:04 ` [Bridge] " Herbert Xu
2011-02-24 4:04 ` Herbert Xu
2011-02-24 4:04 ` Herbert Xu
2011-02-24 4:46 ` [Bridge] " H. Peter Anvin
2011-02-24 4:46 ` H. Peter Anvin
2011-02-24 5:42 ` [Bridge] " Herbert Xu
2011-02-24 5:42 ` Herbert Xu
2011-02-24 5:42 ` Herbert Xu
2011-02-24 5:57 ` [Bridge] " H. Peter Anvin
2011-02-24 5:57 ` H. Peter Anvin
2011-02-24 6:37 ` [Bridge] " Stephen Hemminger
2011-02-24 6:37 ` Stephen Hemminger
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=4D65CD81.4070203@zytor.com \
--to=hpa@zytor.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.hengli.com.au \
--cc=linus.luessing@web.de \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.