I have managed switches on either side of a wireless bridge (it's an enterprise class bridge, made by Tsunami). I want to be able to define vlans and either side and trunk them through the bridge. My guess is the bridge will just forward on the packets and leave the q-tagging intact. Does that sound right? Or will it probably see the packets as invalid or something and drop them?
what will a dumb bridge do to vlan tagged packets?
- Thread starter Brazen
- Start date
Bridge most likely won't forward tagged frames as it cannot read the src/dst address in the frame. they will be dropped.
a hub won't care.
a hub won't care.
This came up on the Cisco forums too. The 802.1q tag is immediately ofter the DA/SA, displacing the frame type/length field.
I haven't tried it in the lab, but I believe we collectively decided that if it works at all (not much confidence), it would work for smaller frames, and fail on larger frames (~1500 - 1518) because the TAG adds another four bytes to the frame length.
Any device with a static buffer would blow the frame out as a giant, any device with an elastic buffer would fail every frame, because it needs to see the length field, and it's been bumped to the back of the bus, so to speak.
A cut-through switch *might* work, because once it sees the SA, it dumps the frame to wire. Cisco Frag-Free probably wouldn't work, because it's still store & forward, it only LOOKS at the first 64, but does S&F on the whole thing in some form or fashion.
Any kind of fancy filtering would kill the frame too, regardless of what the filter was, because of the field displacement starting behind the Source Address/SA.
Use a tag-aware bridge and avoid the headaches (goes for switches too, switches are just a fancy bridge).
FWIW
Scott
I haven't tried it in the lab, but I believe we collectively decided that if it works at all (not much confidence), it would work for smaller frames, and fail on larger frames (~1500 - 1518) because the TAG adds another four bytes to the frame length.
Any device with a static buffer would blow the frame out as a giant, any device with an elastic buffer would fail every frame, because it needs to see the length field, and it's been bumped to the back of the bus, so to speak.
A cut-through switch *might* work, because once it sees the SA, it dumps the frame to wire. Cisco Frag-Free probably wouldn't work, because it's still store & forward, it only LOOKS at the first 64, but does S&F on the whole thing in some form or fashion.
Any kind of fancy filtering would kill the frame too, regardless of what the filter was, because of the field displacement starting behind the Source Address/SA.
Use a tag-aware bridge and avoid the headaches (goes for switches too, switches are just a fancy bridge).
FWIW
Scott
I did this....we went from a Dell switch (that supports dot1q) to a non VLAN capable wireless bridge->wireless to another bridge->Dell switch. it worked...sometimes, and not others, and caused issues. Not a good idea.
From what scottmac is saying the tagging occurs above the layer2 src/dst address, before the . From that perspective I can see the switch(bridge) forwarding/learning depending on design.
eitherway, it's a DO NOT DO.
bummer, so I guess I need to find out if this bridge is "tag-aware" then, and if not I'm going to be outa luck. Getting a new bridge isn't really an option as this is a 5-mile link and these bridges don't come cheap 
If you describe the scenario a little maybe we can help.
If this is a WAN link then why the need to bridge? Just route it all.
If this is a WAN link then why the need to bridge? Just route it all.
It's not a big deal. Worse case, bracket the bridges with small routers capable of supporting sub-interfaces and set up GRE tunnels from one side to the other (each tunnel would carry traffic from one VLAN).
An alternative would be VPNs (just a different tunnel)
You're gonna need real routers though, not SOHO stuff.
Good Luck
Scott
An alternative would be VPNs (just a different tunnel)
You're gonna need real routers though, not SOHO stuff.
Good Luck
Scott
spidey07, src/dst won't be a problem. Frame size will be.
Switch chipsets are based on a store-and-forward architecture, and most dumb switches have exactly enough space for a 1514 byte frame in each frame buffer slot, so a MTU-sized IP packet encapsulated with .1Q will just get dropped rather than stored. Store-and-forward bridges work similarly, but often by application nature have a bit smarter chipsets. Cut-through bridges might be okay, but some will cut off packets they think are "out of spec."
Brazen, many media-converting bridges aren't really bridges at all (are either just fancy media converters, or are somewhere in between), and so the devices you have might or might not work. What you really need to do is to run the experiment and see. It's very easy to see if it works, just set up a tagged link and do an FTP - once the TCP window opens up the transfer will totally choke if the tagged frames carrying the MTU-sized IP packets don't make it.
Switch chipsets are based on a store-and-forward architecture, and most dumb switches have exactly enough space for a 1514 byte frame in each frame buffer slot, so a MTU-sized IP packet encapsulated with .1Q will just get dropped rather than stored. Store-and-forward bridges work similarly, but often by application nature have a bit smarter chipsets. Cut-through bridges might be okay, but some will cut off packets they think are "out of spec."
Brazen, many media-converting bridges aren't really bridges at all (are either just fancy media converters, or are somewhere in between), and so the devices you have might or might not work. What you really need to do is to run the experiment and see. It's very easy to see if it works, just set up a tagged link and do an FTP - once the TCP window opens up the transfer will totally choke if the tagged frames carrying the MTU-sized IP packets don't make it.
I'll step in as a person who actually did this and say no...
It worked fine with our setup for a few days, and then performance degraded somewhat, and finally we totally lost all traffic somewhere between the bridges and switches. Rebooting it would fix it for a day, but slowly the bridges and switches confused each other and stopped talking eventually. This was a production network, so we didn't have time to mess around and try different things, we just changed the layout and eliminated the trunks. It was NOT a works/doesn't work type of deal, it was a "kinda works sometimes, not others" type deal, but ymmv. This was older Dell switches (24 10/100, 2 Gig) and Tranzeo 5.8Ghz bridges.
I'll bet you buffer-overflowed yourself into a memory leak ... all the {frame size} >{buffer size} overflowed and you lost the difference in buffer until it crapped.
Total speculation, but I wanted to get in early .....
Total speculation, but I wanted to get in early .....
Originally posted by: ScottMac
I'll bet you buffer-overflowed yourself into a memory leak ... all the {frame size} >{buffer size} overflowed and you lost the difference in buffer until it crapped.
Total speculation, but I wanted to get in early .....
Yeah, if it was a time/generally degrade until a reset I'd agree. You overflowed into somewhere.
Well we have two buildings connected by a 5 mile wireless ethernet link. We use multiple vlans at our main building and I would like to extend those vlans to be accessible from the other building through the wireless link. So basically, I have vlan 101 and vlan 102 defined in switches in both buildings but the wireless is plugged into untagged ports on vlan 102. I would like to set those ports to tagged trunk ports so both vlans will be accessible across the link.
It's a bit long winded to explain exactly why, but basically it's due to a state mandate of keeping law enforcement computers on a separate network from the rest of our computers.
Yep, understoood. Still not a big deal ("Anything's possible with enough Ca$h!!")
Again, if you put a router ... nuts, even an old PC, at each end and create a tunnel (like a MS L2TP / PPTP / IPSEC, whatever) for each VLAN between them.
You would need to have something, somewhere (like subinterfaces on a router, 802.1q-aware NICs on the PC) that will allow you to map a specific VLAN into a specific tunnel.
Then the traffic can traverse the common link and be sorted out at the other end and sent along its merry way.
If you use routers, then either a straight-up GRE tunnel (if your bridges are already encrypted) or an IPSEC VPN (if they're not, and you care about security).
Of course, there are a half-jillion variables that could muck up my overly simplistic suggestion, given the amount of information you've provided, that's what you get.
This isn't rocket surgery ....
Good Luck
Scott
Again, if you put a router ... nuts, even an old PC, at each end and create a tunnel (like a MS L2TP / PPTP / IPSEC, whatever) for each VLAN between them.
You would need to have something, somewhere (like subinterfaces on a router, 802.1q-aware NICs on the PC) that will allow you to map a specific VLAN into a specific tunnel.
Then the traffic can traverse the common link and be sorted out at the other end and sent along its merry way.
If you use routers, then either a straight-up GRE tunnel (if your bridges are already encrypted) or an IPSEC VPN (if they're not, and you care about security).
Of course, there are a half-jillion variables that could muck up my overly simplistic suggestion, given the amount of information you've provided, that's what you get.
This isn't rocket surgery ....
Good Luck
Scott
That would fix it, but another radio link would be mad expensive.
And to ScottMac: I understand what you are saying. In fact, that is pretty much what we have right now. I was just hoping for something a little more elegant.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter