Re: bridged vlan interfaces

Grant Taylor wrote:
> Just to recap and understand where things stand after all the testing, 
> every network connection (wired and wireless) from the SM all the way 
> back to the Linux box, with the exception of the SRW2024 verses a switch 
> / hub for testing, is using and understand 802.1q VLAN tagging / 
> trunking correct?
>
> In other words, the ports on the SRW2024 that the BH was connected to 
> are using 802.1q VLAN tagging and not in port mode (strip tags and send 
> raw frames or accept raw frames and add tags) correct?
>
>   
Back when I was using the SRW2024, yes, that was correct.  Basically I 
had a series of ports (9, 10, 11, 12, 21, 22, 23, 24) set to 'Trunk' 
with 1U, 2T enabled (1 Untagged, 2 Tagged) onto which each backhaul was 
connected.  The port (port 1) going to the 'in' interface of the linux 
box was also set trunk 1U, 2T.

In that situation, if I add in.3 to the bridge, the network keeps going 
without problems.  The problem will only manifest if I add 3T on port 1 
(to the linux box) and any one or all of the ports to the BH and the 
rest of our radios.

Right now, the switch linking the 'in' interface to the radio network is 
a plain switch so in essence the same as having all vlans enabled.on a 
trunk.
> Once the bridge puts the new interface in to the STP Forwarding state 
> does the problem return or do things continue to function?
>
> To jog your memory, there is the Listening, Learning, Forwarding, and 
> Blocking states that a bridge port can be in.  The Listening and 
> Learning times combine in to the Forwarding delay (I think).  I've not 
> had to tweak those settings in a VERY long time.
>
>   
Right.  And I'd expect the problem only to manifest when the port is in 
forwarding state.
> Well, when you put a switch port in to "Port" mode, it will take any in 
> coming traffic that is untagged and tag it with the ports VLAN ID 
> (a.k.a. VID).  Depending on how the switch port is configured the port 
> may or may not pass traffic that is already tagged.  Any traffic that 
> would be leaving a port in "Port" mode will be taken out of the ports 
> VLAN and stripped of its tag and sent out as raw ethernet frames to the 
> downstream equipment.  Thus your ports in "Port" mode should connect non 
> tagged equipment in to tagged equipment.
>   
That's pretty much what I understand of things as well.
> One thing that comes to mind is wondering if you might have a cross of 
> what the ports VLAN for untagged traffic is.  I'm going to assume that 
> you have it correct.  I'm just mentioning it to be thorough.
>   
I wouldn't put myself past that sort of mistake either, so you can be 
sure that I checked that thoroughly already ;)  Without a managed switch 
in the way right now however, it's a non-issue.
> Also make sure that all your equipment understands and is speaking the 
> same VLAN trunking protocol with its neighbor that the neighbor is 
> expecting.  I.e. speak 802.1q to Linux and possibly ISL to older Cisco 
> equipment, or something proprietary with in your wireless gear.
>   
With the exception of the plain switches I use here and there as simple 
connecting devices (they don't know what a vlan is at all), yes, 
everything is 802.1Q as per the specification I posted before on the 
radios.  The managed switch are also 802.1Q only, and according to my 
kernel config, I'm using 802.1Q on the linux box.  I'd likely have a 
tougher time getting this setup to work otherwise ;)
> Going back over previous messages, you don't have the raw in interface 
> with out any VLANs included in your bridge do you?  I think you are 
> literally dealing with in.<VID> and out(.raw) in your bridge.  Correct?
>
>   
Correct.  'out' has no vlan interfaces on it.  and 'in' is not part of 
the bridge.  In the working condition, the two ports on the bridge are 
'in.2' and 'out'
~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00e081342870       no              out
                                                        in.2
> Use a low level packet sniffer, like TCPDump, that will try to analyze 
> even falsely tagged packets for their content to make sure that you 
> don't have recursive tagging going on, i.e. in and in.<VID> in the same 
> bridge while thinking that in will be just the untagged traffic.
>
> Grant. . . .
>   
I'll have to wait a bit to perform those tests.  The manufacturer of our 
radio just told us that in order to get support on the issue, we have to 
upgrade our entire selection to their latest firmware...  That's a major 
pain, especially since the upgrade path is not direct and I have to 
perform three consecutive firmware updates for each one of our 600-some 
installed radios.

It would have been nice to have updated radios shipped to us in the 
first place :P

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/