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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 3 Jan 2006 14:00:35 -0500

Somewhat subtly implied in this discussion is the idea that VLAN
IDs are typically used between VLAN aware switches and not on a
LAN segment where non VLAN aware end stations are likely to be
connected.

I imagine problems can arise if an end station (such as a network
management station) is connected to a port of a VLAN aware switch
and that port is not configured (somehow) to recognize that the
end station is not VLAN aware.

Technically, stripping VLAN IDs is one way of changing them (and
this might normally be the function of a router).  However, it is
usually the case that stripping VLAN IDs at a port simply makes
the conversion between a port-based VLAN context and contextually
identical VLAN-ID-based context.  In other words, a VLAN aware
switch (or bridge) can switch between port A/VLAN 1, port b/VLAN 2
and port c as long as {port A/VLAN 1}, {port B/VLAN 2} and {port c}
are configured at that switch as a contextually identical VLAN.

As a result, a VLAN aware switch switches frames within the same
VLAN context - on a port by port basis - even if the VLAN ID is
added, removed or changed. 

However...

If an end station is attached (perhaps inadvertently) at a point 
where VLAN IDs are used, it should discard frames identified as 
"tagged" while still accepting those that are not - presumably 
including frames addressed to it.  Consequently, using multiple
VLAN IDs on a LAN segment containing end stations is sub-optimal,
not non-functional.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Holland, 
--> David (David)
--> Sent: Friday, December 30, 2005 6:48 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] How are packets/link without a VLAN 
--> tag handled ina bridged network today?
--> 
--> Radia,
--> 
--> As Anoop observed the specifics are documented in 802.1Q, the switch
--> implementation I referrred to is compliant (so I described 
--> the switch
--> behavior).
--> 
--> Again, as Anoop pointed out the switch may be configured to 
--> preserve or
--> strip tags before forwarding. Typically users configure the 
--> links to end
--> nodes as clear (no tag) to support older implementations 
--> that are not
--> VLAN aware. The only VLAN aware "end" nodes I know of are 
--> IP phones, and
--> these usually have embedded L2 switch chips (Zultys etc.)
--> 
--> 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 10:52 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] How are packets/link without a VLAN 
--> tag handled
--> ina bridged network today?
--> 
--> 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
--> 
--> 
--> 
--> Holland, David (David) wrote:
--> 
--> >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
--> >
--> >
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >  
--> >
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->