Re: bridged vlan interfaces

Grant Taylor wrote:
> So if you add the vlan to the interface on the Linux box either in or 
> out of the bridge things are fine?  The problem only occurs when you 
> program VLAN 3 access to the physical port on the switch as in you 
> configure the port to be from 1U, 2T to be 1U, 2T, and 3T?  This really 
> makes me think that the problem is on the switch.
>
> To clarify things, we have eight possible combinations.  Will you please 
> tell me which ones fail?
>
> s = switch port with out vlan 3
> S = switch port with vlan 3
> i = interface on linux box with out vlan 3
> I = interface on linux box with vlan 3
> b = bridge on linux box with out in.3
> B = bridge on linux box with in.3
>
> sib = works
> siB = (invalid)
> sIb = ???
> sIB = ???
> Sib = ???
> SiB = (invalid)
> SIb = ???
> SIB = ???
>
> siB and SiB are invalid because you can not have in.3 in a bridge if 
> in.3 does not exist on the Linux box.
>   

sib = works
siB = (invalid)
sIb = works
sIB = works
Sib = works
SiB = (invalid)
SIb = works
SIB = nowork :(

The current active configuration is pretty much like SIb (using a plain switch) and it works.  Of course in.2 is on the bridge as my entire set of customers is in that vlan.

I toyed with tcpdump a bit and got slightly surprising results:

'tcpdump -n -i in.2' -> I see my customer's traffic.
'tcpdump -n -i in' -> I see my customer's traffic.

'tcpdump -n -i in.2 vlan 2' -> Nothing at all.  Obviously since in.2 is untagged traffic.
'tcpdump -n -i in vlan 2' -> Nothing at all.

Now that last case has me a bit perplexed...  Normally, the *tagged* traffic would enter/leave the physical interface itself.  It's a bit strange to me that both in and in.2 would show tcpdump only untagged frames.  Would this have something to do with the fact that the tigon3 driver/hardware has vlan support built-in?

I also managed to dig out an ethernet hub (a lot harder task than I thought) but haven't had the chance to take it to the datashed (5'x5' datacenter? ;) and sniff the backbone trunk itself for those elusive vlan tags.



> If your vendor is any thing like Cisco, you have to order the correct 
> part number that you have to know to find to get the updated and / or 
> current firmware.  Knowing which part number(s) to order is your 
> responsibility though, at least according to them.  *SIGH*
>
>   
Cisco equipment would likely provide better diagnostics tools in the 
radios.  This is Motorola, networking is one of their very many 
sidelines but it's hard to beat the actual radio performance for the 
price.  I guess building so many cell phones pays off ;)

Jonathan

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4