netdev - Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 14 Mar 2011 11:40:28 +0100
From:	Yann Dupont <Yann.Dupont@...v-nantes.fr>
To:	Yann Dupont <Yann.Dupont@...v-nantes.fr>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: possible issue between bridge igmp/multicast  handling & bnx2x
 on kernel 2.6.34 and >

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@...v-nantes.fr

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html