Untagged packets on native vlan

[darwinsanchez6774]

Hello, it's my first time posting here and I will very much appreciate your kind response guys. I was just wondering how does a switch handle untagged traffic? If an untagged tragfic from a vlan passed through a trunk going to another switch, will the receiving switch forward the untagged traffic to all the ports no matter what vlan they belong to since the traffic has no vlan mark on it? Why or why not? Thanks in advanced. :-)

-dar

[Joseph W. Doherty]

Yep, and if I implied I was recommending such a configuration, such was not my intent.

However, to the OP, understand native or tagged VLAN traffic does not get mixed up on the same switch.

Again, keep in mind the access ports can belong to different VLANs and their traffic is also untagged as it goes in and out of a port.  Although it's untagged, it doesn't get mixed up on the same switch.

But, if you interconnect switches using access ports, which you can, like the above, you can have Switch 1 with an access port in VLAN 10 connect to Switch 2 with an access port in VLAN 20.  Again, something you would not normally do, and its also something, I recall, CDP will complain about.

Also to the OP, I don't know if you're familiar with switches that support "voice" VLANs on access ports.  On these ports, you have the "normal" untagged VLAN traffic, but you also have one additional VLAN whose traffic is sent/received with tagged frames.  Basically this is a "special" trunk port, only using two VLANs, one "native".

[mike.martone]

How does MSTP handle untagged packets? If I setup one of the MSTI instances (MSTI0) to handle VLAN ID = 1 will it also include both packets tagged with a VLAN ID =1 as well as packets that do not have a VLAN tag?   Thanks - mike

[Joseph W. Doherty]

Off the top-of-my-head, I don't know.  Without research, don't know if MSTP frames are considered part of a VLAN or part of the physical topology (like non-PVSTP BPDUs) containing what VLANs they apply.  (I.e. sort of like CDP frames don't use VLAN tags, but they "know", for example, they were transmitted on VLAN # access port.)

[mike.martone]

Hi 

I wanted to clarify my question.  I was not asking about MSTP frames.  Let me explain better. Unlike Cisco's PVST which has a STP instantiation for each VLAN, MSTP provides a few STP instantiations called MSTI's.  You can configure each MSTI(1:7) for one or more VLANS.   

If I configure MSTI1 for VLAN ID 1 will that also include packets tagged with VLAN ID =1 and  any "untagged traffic" which is normally considered part of VLAN 1?

Basically, I want to know if the MSTI1 instantiation will detect loops on packets tagged with VLAN ID =1 and or any "untagged packets" and only block VLAN ID 1 and "untagged packets"?

Regards

Mike

[Joseph W. Doherty]

Ah, I think I understand your question.

Cannot say for 100% certainty, without research how MST does what it does, but it should block redundant paths for all VLANs in the same MSTI without needing VLAN tags, at all.

Consider PVSTP works across "untagged" access ports, "common" STP doesn't consider VLANs at all, MST should be able to likewise not need actual VLAN tagged frames (which as they only contain one VLAN ID doesn't really help a MSTI much, I would think).

[mike.martone]

Thanks for your answer.

PVST has a STP instantiation per VLAN, if you use 100 different VLANs you will run 100 instantiations of STP. 

MSTP gives you a certain number of STP instantiations per switch, each STP instantiation is called an MSTI.  Switches have eight or more MSTI's, thus MSTI0:7.  You split up the VLANs you are using into those separate MSTI's depending on your network architecture and what you are trying to accomplish. 

Each MSTI group works independently of the others, if one MSTI detects a loop it will only block the VLANs that are part of its group and it will not affect the VLANs that are members of other MSTI's from moving over the same connection. 

For simplicity, let's say I am using three VLANs with the following IDs (1, 11, 12) and I broke them up into their own MSTIs as follows:

• MSTI1 = VLAN 1
• MSTI2 = VLAN 11
• MSTI3 = VLAN 12

If MSTI1 detects a loop on VLAN 1 traffic it only block VLAN 1 packets. MSTI2 and MSTI3 did not detect a loop so packets tagged with VLAN ID 11 and 12 continue to flow. 

I believe that untagged traffic is treated as VLAN ID 1 traffic as long as the Native VLAN ID is kept as a 1.  As a result, MSTI1 from my example above should handle Packets VLAN ID 1 tagged and untagged traffic. 

[Joseph W. Doherty]

I think you misunderstand the point I raised.

STP/MST works with ports with untagged frames, i.e. access ports.  Take a switch, with two access ports in VLAN X and two in VLAN Y and connect those four ports to an adjoining switch configured likewise.  STP or MST should block one of the VLAN X and VLAN Y access ports.

When you add a trunk port, frames are now tagged, so that, rather than have four ports for these two VLANs, we can combine those two VLANs on each trunk port.  As far as I know, STP or MST shouldn't care whether VLAN X or VLAN Y is the native VLAN or a tagged VLAN. on a trunk, including whether the two ports are configured the same.  I.e. the following should all be valid (on two switches connecting ports 1<>1 and 2<>2):

interface FastEthernet0/1
switchport mode trunk
!
interface FastEthernet0/2
switchport trunk native vlan 2
switchport mode trunk

I set up the above, in PT, using rapid-PVST and got:

Switch is in rapid-pvst mode
Root bridge for: default VLAN0002
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default  is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
EtherChannel misconfig guard is disabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     0         0        0          2          2
VLAN0002                     0         0        0          2          2

---------------------- -------- --------- -------- ---------- ----------
2 vlans                      0         0        0          4          4

Switch#sh spanning-tree su
Switch is in rapid-pvst mode
Root bridge for:
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default  is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
EtherChannel misconfig guard is disabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     1         0        0          1          2
VLAN0002                     1         0        0          1          2

---------------------- -------- --------- -------- ---------- ----------
2 vlans                      2         0        0          2          4

Either STP or MST should be VLAN based, i.e. doesn't matter whether frames are tagged or not, just that L2 additional paths are blocked in applicable VLANs.

[Dan Lukes]

OK. It's time to describe frame processing algorithm in more details. It should help you to understand the processing.

In general, frame is entering the switch (input), then is subject to switching decision process, then it's leaving the switch (output).

---

Input

There are two modes if input port. Access and trunk.

Input on access mode port

When you configure a port in access mode, you can specify which VLAN will carry the traffic for that interface. Untagged frames received are assigned to such VLAN.

If an access port receives a frame with an 802.1Q tag in the header other than the access VLAN value, that port drops the frame without learning its MAC source address.

Exception: frames tagged for voice VLAN are accepted (if there's tagged voice vlan configured on port)

There must be access vlan configured on every port. If there's no access vlan configured, VLAN1 is assumed.

Related commands:

switchport mode access
switchport access vlan vlan-id
switchport voice vlan ...

Input on trunk mode port

When you configure a port in trunk mode, tagged frames belonging to allowed vlans are accepted. Untagged frames are accepted and assigned to native vlan as configured on such port. Other frames are discarded.

There MUST be native vlan on every port. If there's no native VLAN configured, then VLAN 1 is assumed.

Related commands:

switchport mode trunk
switchport trunk allowed vlan ...
switchport trunk native vlan ...

Frame switching

Note that there are no "untagged frames" possible at this phase. All frames are classified to belong to particular VLAN by input processing.

Frame is submitted for transmission according database of learned MAC.  If the target MAC is not known yet, it's queued to all ports carrying traffic for VLAN in question. 

Exception: frame is never retransmitted back to the port where it has been received from.

Note: Private-VLANs use slightly different frame switching algorithm.

Output

Output on access mode port

Frames are transmitted untagged.

Exception: voice VLAN frame may be transmitted tagged even on access port (if configured).

Output on trunk mode port

Frame belonging to native VLAN (as configured on particular port) is transmitted untagged, other frames are transmitted tagged.

---

Hope it will help you to understand the switching process.

[Joseph W. Doherty]

Some additional information to what Dan noted . . .

"There are two modes if input port. Access and trunk."

Perhaps three modes if switch supports "routed" (i.e. no switchport).

"If an access port receives a frame with an 802.1Q tag in the header other than the access VLAN value, that port drops the frame without learning its MAC source address."

Another possible exception, if VLAN ID is zero, i.e. VLAN tag not being used for VLAN membership, just being used for CoS.

"Exception: frames tagged for voice VLAN are accepted (if there's tagged voice vlan configured on port)"

BTW, before there was a "voice VLAN", we could define port as a trunk (which is what an "access" port with a voice VLAN is, more or less [i.e. it's a "lobotomized" trunk for two VLANs]).

"When you configure a port in trunk mode, tagged frames belonging to allowed vlans are accepted. Untagged frames are accepted and assigned to native vlan as configured on such port."

BTW, I believe trunk port will accept its native VLAN frames, tagged (with, of course, native VLAN ID) or untagged.

"Note that there are no "untagged frames" possible at this phase."

I think what the OP was asking, was, internally, does the switch require frames to be actually tagged (i.e. a .Q or ISL header).  If that's what OP is really asking about, your follow-on statement also implies an actual frame tag is not necessary, i.e.:

"All frames are classified to belong to particular VLAN by input processing."