Subject: [rbridge] How are packets/link without a VLAN tag handled in a bridged network today?

From: dsholland at avaya.com (Holland, David (David))
Date: Thu, 29 Dec 2005 22:18:02 -0500

Radia,

My experience from working on switch/router "brand z", is that the
behavior for "a" (below) is correct.

In the "b" case the packet is NOT flooded to the other vlans UNLESS
those ports are also participating in the (default) untagged vlan by
configuration. 

For item "c": Yes the link can support all VLANS or only selected VLANS.
The configuration options allow for the bridge to automatically bind the
link to all VLANs for which tag values are observed (or only those
received on the link or only those manually administered). This provides
for trunking links.

David

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, December 29, 2005 8:21 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] How are packets/link without a VLAN tag handled in a
bridged network today?

I guessed at the behavior once, to someone who was following 802.1
better than I have been, and he verified that I was correct at the time,
but I've forgotten what my conjecture was. Does anyone know how the
following cases are handled?

Suppose a bridged network has some links configured as VLAN A, and
others configured as VLAN B, and some links that are not configured as
either VLAN A or VLAN B. Let's say that links La1 and La2 are configured
as VLAN A, links Lb1 and Lb2 are configured as Lb, and links Lc1 and Lc2
are not configured to reside in either VLAN A or VLAN B.

Let's further assume that it is the bridges that put on the VLAN tags.

What happens in the following cases?

a) A layer 2 multicast packet originates at La1. Certainly the first
bridge adds a VLAN A tag to the packet, and delivers the packet to La2.
However, does it also deliver it to Lc1 and Lc2? (I'd be very surprised
if the answer to this was yes...I assume the packet will ONLY get
delivered to links that are specifically marked as supporting VLAN A).

b) A layer 2 multicast packet originates at Lc1. I assume the behavior
in this case is that the first bridge does NOT add a VLAN tag to the
packet. I can imagine either in this case that the packet is ONLY
delivered to Lc2 (i.e., other links that are not configured as belonging
to any VLAN), but I suspect the packet is delivered to ALL links, i.e.,
in this case, La1, La2, Lb1, Lb2, and Lc2, and without a VLAN tag.
This would mean that endnodes in VLAN A and endnodes in VLAN B will see
this packet, so perhaps it's the other behavior (that it's only
delivered to links that are not configured as being in any VLAN).

c) If it is the bridge, rather than endnodes that put on the VLAN tag,
is it legal for a link to support multiple VLANs? It would make sense
for the answer to this to be no, in which case I suspect the answer to
b) above would be more likely to be "don't deliver to any links that
have been configured to be in any VLAN", since I suspect "unmarked VLAN"
is treated as a special case VLAN.

Radia

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 29 Dec 2005 19:52:09 -0800

Thanks!

So, there is a specific special "untagged" VLAN, which is "marked" by 
the absence of a VLAN tag. As opposed
to a meaning that this packet should go to everyone, which I could also 
imagine.

Another question then...if bridges add the VLAN tag (and therefore 
endnodes are unaware of
VLAN tags), then how is it possible to support a link with multiple 
VLANs? Wouldn't endnodes
get confused because they will see packets from other VLANs? I'd assume 
that unless endnodes
are VLAN-aware, and put in their own tags, that it would be illegal for 
a link to support
multiple VLANs. Is this true?

And...are you saying that this is not written down anywhere, but just 
observed based on how
some particular vendor implemented it?

Thanks again!

Radia