VLAN operation in Transparent bridging

Hi If a bridge is configured in "Transparent Bridging" mode then the bride protocol entities Viz. STP, GVRP, GMRP are disabled and the bridge forwards frames based on learned MAC information. Is the behaviour same for both untagged and tagged (VLAN) frames ? Or does it drops VLAN tagged frame ?

Thanks in advance Pritam

Reply to
pritamganguly
Loading thread data ...

If by "Transparent Bridging", you mean 802.1D operation (as opposed to 802.1Q), then the bridge becomes agnostic to VLAN tags. However, such bridges are still expected to run STP and, optionally, GMRP.

Anoop

Reply to
anoop

Hi By transparent bridging I meant only "bridge forwarding" behaviour without any bridge to bridge protocol executing.

formatting link
In this case the bridge should forward all frames received according to the learned MAC addresses. My question was will this bridge forward VLAN tagged frames too or drop them?

Another question will a VLAN unaware bridge forward VLAN tagged frames?

Regards Pritam

Reply to
pritamganguly

And the answer was "it will forward them". VLAN tagged frames look to non-VLAN-aware bridges like any other frame. VLAN tagging is done by using a special ethertype encoding. Ethertypes are NOT looked at by normal (non-VLAN-aware) bridges.

This is not another question. Yes, it will.

You seem to think that running "bridge protocols" like STP, somehow influences VLAN function. It doesn't. Those concept are independant, to the best of my knowledge.

best regards Patrick

Reply to
Patrick Schaaf

Except that a maximum length ethernet frame with a tag added is effectively oversize by 4 bytes.

So a VLAN unaware bridge may well drop the frame size oversize is an error.

Reply to
stephen

I remember reading, probably from Rich Seifert, that they looked at the bridges in the field when inventing .1q, and found that they had no problem with those longer frames.

Maybe I misremember. Looking forward to corrections.

best regards Patrick

Reply to
Patrick Schaaf

This might have been true of MOST bridges at the time, but it certainly cannot be said to be true for ALL bridges. However, there really wasn't a choice with respect to increasing frame size, otherwise a lot of hosts that generate frames with 1500 bytes of payload would get tossed at .1Q switches that needed to tag the frame.

There are other issues with regard to interoperability between 802.1D and 802.1Q bridges that are discussed in an annex of 802.1Q.

Anoop

Reply to
anoop

No device was ever discovered, either then or (to my knowledge) now, that did not display acceptable behavior when presented with a 1522 byte tagged frame vs. a 1518 byte (maximum untagged) frame.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

I don't know of any specific examples where this is not true which is really weird since switches/bridges built pre-802.1Q should have dropped anything over 1518 bytes.

Anoop

Reply to
anoop

Why should they drop such frames? It takes *extra effort* to examine the frame length, compare it against some reference length, make a decision to discard, and then perform the discard (e.g., adjusting buffer pointers, updating linked lists, etc.) Bridges/switches are generally designed to be "lean and mean," i.e., built for performance.

The reason why the length is not a problem is that 1518 bytes (or even

1526 bytes, a maximum-length untagged frame plus preamble) is not a "round number." If you are building a buffer-management scheme, you would not organize memory in 1518-byte chunks. Most folks used 2K-bytes (a nice round number, 0x0800--very easy to align in hardware); if you wanted somewhat better memory efficiency, you would use 1536-byte buffers (a fairly round number, 0x0600--not quite as simple as 0x0800). Thus, as long as the VLAN extensions did not push the maximum frame beyond 1536 bytes, no practical implementation would be unable to handle such frames. Even allowing for storage of the preamble (some implementations do this), you get a 1528 byte upper limit.

Even if a switch is using dynamic buffers, the granularity will not be less than 64 bytes, since the switch always needs at least that length for a minimum frame. In order to accommodate a 1518-byte frame, the switch will need at least 24 64-byte buffers, which is exactly the 1536 byte number discussed above.

As long as the frame doesn't overflow the switch buffer, it should work fine. Since buffers are invariably 1528 bytes or more, VLAN-tagging does not affect frame forwarding by legacy switches in any negative manner.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Reply to
Rich Seifert

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.