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

From: anoop.ghanwani at hp.com (Ghanwani, Anoop)
Date: Thu, 29 Dec 2005 20:03:10 -0800

Radia,

IEEE 802.1Q does not allow a port to not be 
in any VLAN.  In other words, every port must 
be in at least one VLAN, and every port has a 
PVID which says what you should do with untagged 
frames from that port.  Therefore, an 802.1Q
device will not allow you to do what you say
in (1) and (2) for lc1 and lc2.  

By default all ports are in VLAN 1 and all ports 
have a PVID equal to VLAN 1, and they are 
configured to send traffic untagged on that VLAN.  
The user creates VLANs and can start reassigning 
ports to them.

Once a frame is inside the switch, the switch
always knows which VLAN the packet belongs to
(based on the above) and will only forward 
the frame to ports that are members of that
VLAN (regardless of whether it is unicast,
multicast, broadcast, or "unknown DA").  
Of course, if the DA is known, it gets 
forwarded only to one port.

Once we work with these assumptions, (1) and 
(2) are non-issues.

As for (3), yes, a port can be a member of 
multiple VLANs.  In that case, untagged traffic
arriving at the port gets assigned the PVID.
When you send traffic out, there is a parameter
to control whether or not a given VLAN should
be tagged/untagged before sending the frame
out.

Hope this helps.

Anoop 

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Thursday, December 29, 2005 5: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
>