Re: bridged vlan interfaces

	First and foremost, a great many thanks for the quick and very 
insightful reply.  My humble self kept assuming that the problem lied in 
my own ineptitude with the bridge.  The prospect of blaming a braindead 
(Linksys SRW2024) switch is appealing to my ego ;)

Physically, I have something like this

(40xSM)<-T->(AP)<-T->(BH)<-T->o
(20xSM)<-T->(AP)<-T->(BH)<-T->o
(30xSM)<-T->(AP)<-T->(BH)<-T->o(SRW2024)o<-T->(in-br0-out)<-P->(gateway)
            ...                o         o<-P->(mgmt)
        (SRW208)o<-T->(BH)<-T->o
Where:
o=Switch port
()=Physical hardware
SM=Subscriber Module
AP=Access Point
BH=BackHaul
<-T->=Multi-VLAN trunk
<-P->=Plain ethernet

The SM, AP and BH units, I am assured, are very dumb bridge like 
devices, they don't try to interpret any of what's going through them. 
I somehow doubt that they're to blame for the problem.  As you can see, 
with the exception of a small management system, everything connected to 
the SRW2024 is trunk ports.  I could probably just bypass it with a dumb 
switch, link all my backhauls to the 'in' port of the linux box and 
split my vlans there instead.

Basically, I'd want to give a different vlan to each branch.  Right now 
all trunk ports only carry vlan2 tagged stuff which is the customer 
network, and vlan1/untagged which is used to manage the equipment.

The trunk port to 'in' only has vlan2 tagged on it, and I have a small 
station to manage (mgmt) the vlan1/untagged stuff on an access port of 
the SRW2024.

I can't easily remove the SRW208, but I don't think it would affect the 
rest of the network, right?

Thanks again,

Jonathan

Grant Taylor wrote:
> 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/
> _______________________________________________
> Ebtables-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-user


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