Re: bridged vlan interfaces

On 11/20/07 13:07, Jonathan Thibault wrote:
> Not exactly.  The problem comes when those vlans see the network 
> trunk, which I have to configure in the SRW2024 to see happening.  Or 
> merely replace the SRW2024 by a plain switch and connecting the 'in' 
> interface right into the trunk.  The problem does happen when the 
> SRW2024 is not involved at all.

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?

> Like I said, I'm not 100% sure of that but almost, based on the fact 
> that if I remove the troublesome vlan interface from the bridge, and 
> then add it back on, the traffic keeps flowing, even allowing for the 
> time it takes for the bridge to actually accept the new interface. 
> (forgot the name of that parameter)

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.

> Working logically here and assuming that this is the issue, it would 
> mean that some of my customers cannot handle 'tagged' ARP replies. 
> What is it then that lets the same type of traffic be untagged 
> properly when only one vlan is on the bridge, but not when more than 
> one vlan is on the bridge.  At some point we also had three vlans (2, 
> 4 and 5) on the customer network with customers in each vlan.  But 
> only vlan2 went through the bridge, the other two went to more simple 
> NAT type gateways so I don't think this is an issue with just having 
> multiple vlans on a trunk.  Not to mention vlan1 being the management 
> vlan on the trunk too.  Anything untagged on that trunk gets tossed 
> to vlan1.

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.

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.

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.

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?

> Hmmmmmmm....  Maybe I could monitor vlan1 for the missing ARP 
> replies...

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

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