Re: bridged vlan interfaces

On 11/15/2007 7:46 PM, Jonathan Thibault wrote:
> 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 
> brain dead (Linksys SRW2024) switch is appealing to my ego ;)

No problem.  I've been on the job site getting ready to turn something 
up to show my boss and have it blow up in my face.  It is no fun, 
believe me.  I'd rather help someone else to try to help repay the karma 
points that I spent having others help me with other things (past / 
present / future).

At the risk of starting a flame war, I'll say your first problem (in 
*MY* *OPINION*) is the single name "Linksys".  I've had some very bad 
luck with Linksys gear and I'll leave it at that.

I understand completely.  However if you double, triple, and quadruple 
check things and they all should be working and further it works in your 
test lab and only fails in production with specific equipment, chances 
are good it is something related to your production environment and / or 
interaction there with.  But being humble, no problem with that at all. 
  I think it is better to be overly cautious and find out that you were 
correct later on than the other way around.

> 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

Ok.  I take it that the SWR208 is another switch located at another 
location? Not that it really matters a lot (I think).

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

I'd agree that your SM, AP, and BH units are likely not your problem. 
Just based on what you have described the symptoms to me, I don't think 
any of those units would be able to take out (or bring back) multiple 
subscribers at one time the way you have described.

If you can replace your SRW2024 temporarily for testing I think it might 
be wise to do so.

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

What if you put another network card in your Linux system and created a 
mgmt interface and connected it to vlan1 on your network.  So in essence 
you would have something like this

(SRW2024)o<-T->(in.2-br0-out)<-P->(gateway)
          o<-T->(in.1-br1-mgmt)<-P->(mgmt)

This would allow you to permanently remove the layer 2 aware managed 
switch from the core of the network.  Just a thought.


> Thanks again,

You are welcome.



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/