bridged vlan interfaces

Hello list,

I've been struggling with a strange problem since I started this project 
on kernel 2.6.19.  I recently upgraded to 2.6.23.1 and still see the 
exact same behavior so I assume I'm doing something wrong.

The linux box acts as a firewalling bridge and has two tigon3 
interfaces, labeled 'in' and 'out' for simplicity.  The 'in' interface 
is a trunk port with vlans in.2, in.3 and in.6.  The currently, I have 
'in.2' and 'out' bridged together so:

(customers) <---> in.2 <-br0-> out <---> (gateway/router).

This works quite well, I do all my filtering in iptable's FORWARD rule. 
The only ebtable rules I have are -P DROP on 'INPUT' 'OUTPUT' and 
'FORWARD' and then -j ACCEPT  on IPv4 and ARP.

My current problem is that I would like to put some of my customers in 
vlan3.  Not so much to isolate them (they could still talk through the 
bridge), but mainly to let the firewall be aware of which backhaul they 
are connecting from and be smarter about its shaping rules that way.  
Basically, the only way I can tell where a customer is is to set a vlan 
on their connection endpoint.  Their MAC and IP addresses are subject to 
change frequently and being imposed a 'flat' network, I have no real way 
of separating them in subnets.

The problem is that as soon as I add in.3 to the bridge, some (3 that I 
am aware of so far) customers experience problems reaching the gateway.  
tcpdump suggests that arp replies from the gateway never reach the 
customers.  They keep making ARP requests for the gateway.  I don't 
think they can reach the bridge IP itself either, but I'll have to do 
further testing to confirm that.

Note that I haven't acutally *moved* any customers to vlan3 yet.  The 
problem happens as soon as I add in.3 to the bridge and vanishes as soon 
as I remove it from the bridge.

When a customer calls to tell me they have no internet, they regain 
access as soon as I remove in.3 from the bridge, but they will not 
immediately loose it if I re-add in.3 immediately after.  So I'm 
guessing that as soon as the gateway's MAC is in their ARP table, they 
have no problem reaching it.  Or it could be that the bridge stops 
learning new MACs when in.3 is added.

I probably have a lot more testing to do, but I'd love some guidance as 
to where I should start.  I only see the problem on the *live* system 
and therefore can't really take it down for extended periods of time and 
take it appart.

Thanks in advance,

Jonathan

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