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] [thread-next>] [day] [month] [year] [list]

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

> 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,

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