Re: bridged vlan interfaces

On 11/15/07 15:56, Jonathan Thibault wrote:
> 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.

Novel.  I had not considered doing a Layer 3 protocol filter before. 
Although I have not had a need to do so.

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

Agreed.  I have done exactly this for segregation purposes with 
tremendous success.

> 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 ran in to a similar problem in my install, but the problem has nothing 
to do with Linux.  Do you have any HP ProCurve switches in your network? 
  I had found that some equipment (*cough* HP ProCurve switches *cough*) 
did not like seeing the same MAC on multiple VLANs.  In short Linux was 
smarter than some of the other core equipment.

To get around this I had to spoof the MAC address of the router from 
'out' (in your case) to be more like 'out.vid' on each vlan. 
Technically what I ended up doing was taking the router's MAC and 
altering the last byte to be the VLAN ID.  This way the switch would see 
dissimilar MAC addresses across all VLANs.  Essentially I had to SNAT 
the MAC of traffic leaving the router and DNAT the MAC of traffic going 
to the router.

I had two HP ProCurve 4000 switches connected to each other and then to 
a Linux box and then the router.  In this scenario, the only MAC address 
that the switches would possibly see on multiple VLANs is the router. 
There was no VLAN to VLAN traffic, which would have been a problem for 
the same reason.  Now if you are using Router-on-a-Stick, where you will 
come from the switch(s) one one or more VLANs to the Linux box and back 
to the switch on one or more different VLANs, you will have a LOT of MAC 
addresses that need to be altered.  Or the more proper solution would be 
to B*%#& Smack the switch (read:  upgrade the firmware(?)) so that you 
do not have to deal with such stupidity.

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

I am guessing that there are forces beyond your control at work against 
you here.  With out knowledge of said forces you have very little hope 
of working around them.

> Thanks in advance,

*nod*



Grant. . . .

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