Strange bridged VLAN behavior

Hello list,

I've already brought this up in ebtables-user and gotten a lot of 
valuable input (you can have a peek at the archives for the saga) and 
finally managed to narrow things down to either some obscure ARP/mac bug 
in the bridge code itself, or something in the tg3 driver of the network 
cards involved.

Basically, I have a bunch of customers in vlan2 on an 'in' interface, 
which is bridged with an 'out' interface to the gateway.  So basically:

customers      bridge           isp
vlan2 <--> (in.2-br0-out) <--> gateway

This works quite well so long as I do not add another vlan interface to 
the bridge.  I can have a test vlan (in.3) on up on the linux box 
itself, but adding it to the bridge brings forth strange behavior.  It 
*mostly* works as it should, customers in both vlan2 and vlan3 can see 
the gateway, data goes through, etc.  However the bridge seems to stop 
relaying arp replies from the gateway to some of our customers when in.3 
is part of the bridge.

I can see the arp requests and reply on every interface involved 
(tcpdump on in.2, br0 or out shows them) but if I check on the trunk 
wire itself (using a hub and another linux box) I only see the arp 
requests go through for those specific customers, they never seem to 
leave the 'in' network card.  Overall, it looks like the bridge 
'forgets' the mac address of those specific customers when in.3 gets 
added and never re-learns it.  brctl showmacs br0 confirms this.  On one 
test, it showed over 300 macs prior to adding in.3 and quickly dropped 
to 200 macs as soon as it entered forwarding state.  This could be a 
strange coincidence, but I thought it was noteworthy.

I know this is still fairly sketchy, but I would like some help in 
figuring out just where those vanishing arp replies go. This bug only 
shows up in our production environment so I would rather have the advice 
of devs in order to test things intelligently and with as little 
downtime as possible.

Jonathan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/