From: Yann Dupont <Yann.Dupont@univ-nantes.fr>
To: Yann Dupont <Yann.Dupont@univ-nantes.fr>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Subject: Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
Date: Mon, 14 Mar 2011 11:40:28 +0100 [thread overview]
Message-ID: <4D7DF09C.9000400@univ-nantes.fr> (raw)
In-Reply-To: <4D495C39.6020002@univ-nantes.fr>
Le 02/02/2011 14:29, Yann Dupont a écrit :
>> Le vendredi 07 janvier 2011 à 11:40 +0100, Yann Dupont a écrit :
>>> Le 04/01/2011 14:40, Yann Dupont a écrit :
>>> ...
>>>> We just added BCM57711 10G cards (bnx2x driver) on our blade servers
>>>> (connected to 10G Power Connect M8024).
>>>> Since then, we are experiencing random lost of packets.
>>>>
>>>> Symptom : packets are lost on some vlans for a few seconds, then
>>>> things go back to normal (and stops again a few minutes later)
>>>>
>>> As I didn't had answer so far , I digged a little more and captured
>>> more
>>> packets.
>>> I just noticed that an event trigger that problem : IPv6 neighbor
>>> discovery packet .
>>>
>>> This is , of course, a multicast packet.
>>>
>>> Just saw that 2.6.36.3 should include this fix :
>>>
> Just a little update, the problem doesn't seem to be what we thought
> at first.
>
> It may not be related to the bnx2x driver after all.
> We noticed that we had the same symptoms on target machine using bnx2
> drivers (we missed that at first since the outages are way briefer).
>
> We're now rather suspecting our own firewall (also a linux in a kvm
> machine) since without it we don't get any more problem and the packet
> drops occurs on _THIS_ network, when packets are routed by _THIS_
> firewall.
>
> Anyway, all of that is very puzzling, we have made a lot of network
> dumps and we have really no clue of what's happening there.
> We don't understand why, if the problem is really on our firewall
> machine, setting CONFIG_BRIDGE_IGMP_SNOOPING to 'n' on the target
> machine efficiently fix the problem, Especially since it doesn't seem
> related at all with our setup and we don't see anything in our network
> dumps that could explain this.
>
> It's probably not a single problem, but a sum of different problems.
> We continue to search.
> Sorry for the noise.
>
> Regards,
>
One of my collegue noticied that :
https://lists.linux-foundation.org/pipermail/bridge/2010-October/007362.html
Exact same problem.
In fact, the problem **really** seems to be on the network switch.
Our servers are DELL M605 on a DELL M1000e chassis, with powerconnect
M6220 (G) and M8024 (10G)
IGMP snooping is also activated on those switches. If we turn igmp
snooping off on M8024 for exemple, we don't have problems anymore, that
is, we can activate IGMP snooping ON the linux bridge without loosing
packets.
M6220 & M8024 seems concerned. Time to make a bug report (again and
again...if you ask me, I can tell you they are crap.)
Sorry for the noise,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
prev parent reply other threads:[~2011-03-14 10:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-04 13:40 possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and > Yann Dupont
2011-01-07 10:40 ` Yann Dupont
2011-01-07 11:28 ` Eric Dumazet
2011-02-02 13:29 ` Yann Dupont
2011-03-14 10:40 ` Yann Dupont [this message]
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=4D7DF09C.9000400@univ-nantes.fr \
--to=yann.dupont@univ-nantes.fr \
--cc=eric.dumazet@gmail.com \
--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