VLAN operation in Transparent bridging

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

pritamganguly@gmail.com wrote:

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

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi
By transparent bridging I meant only "bridge forwarding" behaviour
without any bridge to bridge protocol executing.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/transbdg.htm

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

pritamganguly@gmail.com writes:

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

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.

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

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

 

[Stephen]

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Patrick Schaaf" <mailer-daemon@bof.de> wrote in message
news:42e5d8ae$0$10391$9b622d9e@news.freenet.de...
> pritamganguly@gmail.com writes:
>
> >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?
>
> 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.
>
> >Another question will a VLAN unaware bridge forward VLAN tagged frames?
>
> This is not another question. Yes, it will.

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

Stephen Hope - return address needs fewer xxs

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

"stephen" <stephen_hope.xx@ntlxworld.com> writes:

>> >Another question will a VLAN unaware bridge forward VLAN tagged frames?
>>
>> This is not another question. Yes, it will.

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

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.

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

Maybe I misremember. Looking forward to corrections.

best regards
Patrick

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Patrick Schaaf wrote:

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

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1122441461.064883.98610@g43g2000cwa.googlegroups.com>,
"anoop" <ghanwani@gmail.com> wrote:

> Patrick Schaaf wrote:
>
> > 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.
>
> This might have been true of MOST bridges at the time, but it certainly
> cannot be said to be true for ALL bridges.


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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

Rich Seifert wrote:

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

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

 

[Guest]

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1122561924.852078.241070@o13g2000cwo.googlegroups.com>,
"anoop" <ghanwani@gmail.com> wrote:

> Rich Seifert wrote:
>
> > 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.
>
> 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.
>

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