A frame with a tag such as native vlan.

[krzysztofmaciejewskiit]

If a frame with a tag corresponding to the native VLAN enters the trunk port, will the switch take down that frame and send it on over the trunk link as untagged, or will it send it with a tag corresponding to the native VLAN?

How I understand it:
(Let's assume that the addressing is correct).
PC-A will send a frame to Switch1, which will give it VLAN tag 20. The frame will go through the trunk port to Switch2. Switch2 will check the VLAN tag and find that the frame has a tag corresponding to the native VLAN, so IN MY OPINION the tag will be removed because the native VLAN only transmits untagged traffic. So, then Switch2 will send the untagged frame to Switch3, which in turn will forward the frame to PC-B.

What will it look like in this case?
Since the access ports are the same as the native VLAN. I wonder if at least one actual tagging of a frame will happen at all in this situation. I realize that the switch somehow “tags” the frame as it passes through the access port, but the actual tagging only takes place when the switch knows it needs to pass the frame through the trunk port.

How I understand it:
In my opinion, a frame when it hits an access port on Switch1 will not be tagged before being sent to Switch2, because Switch1 will realize that the frame is to be forwarded to a trunk port that has a native VLAN the same as the potential VLAN tag.

[Joseph W. Doherty]

Your understanding is correct insofar as whether frame will be tagged or not on the various links (assuming tagging is NOT also being done for CoS purposes too).

However, if you're assuming frames are VLAN tagged "inside" the switch, that, I suspect, is likely not the case.  More likely, I think, switch just keeps track of what VLAN a frame belongs to by some internal data structure.

[Ramblin Tech]

When an untagged or priority tagged frame from PC-A ingresses e0 on Switch1, it is associated internally with VLAN 20, by virtue of e0 being an VLAN 20 access port. The switch then consults its MAC address table to determine which egress interface the frame should be switched to for transmission, based on destination MAC address. If the egress interface is a .1Q trunk, the frame is transmitted with VLAN 20 tag unless the trunk has VLAN 20 configured as its native VLAN *and* the trunk does not have the equivalent of "vlan dot1q native" configured; in that case, the frame is transmitted untagged.

What if the dest MAC is not in the MAC addr table? Then the switch must flood the frame out all egress interfaces that are configured to carry VLAN 20 traffic. Note that some VLAN 20 egress interfaces might be access ports, while others are trunks. Furthermore, some of the trunks might be configured with native VLAN 20, while others have a different native VLAN, or no native VLAN at all. The implication of this is that, in a flooding situation, some egress interfaces are transmitting with a VLAN 20 tag, while others are transmitting untagged.

In the general switchport case, you can conceptually think of the top-most tag (if tagged at all) being popped at ingress and the frame having metadata assigned to it to denote what VLAN it belongs. At egress, the frame has an appropriate tag pushed onto it (based on the metadata) if the egress interface is a trunk and the trunk's configuration requires a tag for that particular VLAN. SVIs do not understand VLAN tags, so L2/switchport frames that are to be routed must be presented to the SVI without a VLAN tag (hence the conceptual popping). This concept of top-most frames being popped at ingress also allows for switches that support VLAN translation; that is, some switches allow the egress tag to be different than the ingress tag.

As an aside, I find the whole switchport configuration model to be archaic and confusing, and am much more partial to the EVC/EFP configuration model for performing VLAN tag acrobatics. Sadly, not all products support EVC/EFP.

[krzysztofmaciejewskiit]

I would like to add a question so as to clarify your answer.

I am mainly concerned with the situation in the photo below. Where the frame between switch 1 and 2 (native VLAN 33) will go with tag 20. However, I would like to make sure that between switch 2 and 3 (native VLAN 20), the tag will be removed, because the frame goes with VLAN tag 20 and is to be sent over the trunk link with native VLAN 20 set.

Another thing I didn't understand was “*and* the trunk does not have the equivalent of 'vlan dot1q native' configured”. What equivalent do you mean? As far as I know, only one native VLAN can be set up on a link.

Thanks for the comprehensive answer!

[MHM Cisco World]

You focus on SW tag untag the native vlan recieve send through different interface 

But what you need to focus on is 

are SW correctly know that this traffic is for untag vlan or not

Also protocol like vty stp will not work properly if you change native vlan in each SW.

That not healthy network design at all

MHM

[krzysztofmaciejewskiit]

I realize that this is not designed well. This is a hypothetical scenario I created for the purpose of better understanding tagging.

[MHM Cisco World]

I run lab for you and Add ID column to wiresharke this column for VLAN ID use in traffic 
as you can see R4 receive tag vlan 20 from R3 since native is 33 and forward it as untag to R5 since the native vlan 20

Again try avoiding this in real network 

MHM

[Joseph W. Doherty]

"Also protocol like vty stp will not work properly if you change native vlan in each SW."

Are you sure?  Any Cisco documentation on this being a problem?  First hand experience having a problem doing this?

Reason I ask, if ports on link are properly configured, for trunk, shouldn't be a problem, I believe.

[Ramblin Tech · Accepted solution]

When it comes to internal forwarding implementation specifics, all behaviors are platform dependent. That said, the general, platform-independent answer is that tags are popped at ingress and pushed (if required) at egress. In between the ingress and egress interfaces, packets/frames are internally tagged with ephemeral metadata / packet-descriptors that help the forwarding engine make decisions on how to forward and how to handle QoS.

Applying the platform-independent model to your example: PC-A sends an untagged frame into Switch1/e0, which internally assigns metadata to it associating it with VLAN 20. Switch1 consults its MAC addr table which says the dest addr is out e1. Since e1 is a trunk with native VLAN 33, Switch1 pushes a VLAN 20 tag and transmits it.

Switch2 receives the VLAN 20 tagged frame on e1, pops the VLAN tag, and writes VLAN 20 into the frame's metadata. Switch2 then consults its MAC addr table which says the dest addr is out e2. Since e2 is a trunk with native VLAN 20, there is no need push a VLAN 20 tag onto the frame before transmitting out e2 to Switch3 (unless e2 is configured with "vlan dot1q native").

Switch3 receives the untagged frame on trunk e2 and associates VLAN 20 metadata to it by virtue of e2 being configured with native VLAN 20. Switch3 then consults its MAC addr table which says the dest addr is out e0. Since e0 is an access port, no VLAN tag will be pushed (unless configured for VLAN 0 priority tagging).

What is "vlan dot1q native"? It is an IOS switchport command that says every frame should be tagged, including those associated with the native VLAN. This might be done for interoperability, since the native VLAN concept is a convention and not actually an IEEE thing, or it might be done as a mitigation against some perceived VLAN-hopping vulnerability that might use untagged frames as an attack vector. I say "equivalent" because platforms that do not use the same command structure as IOS switchports may have the equivalent capability, but with a different syntax.

[krzysztofmaciejewskiit]

Thanks for this comment, it is really helpful.

Forgive my clinging, however, I would like to make another inquiry about something.
“Switch2 receives the VLAN 20 tagged frame on e1, pops the VLAN tag, and writes VLAN 20 into the frame's metadata. Switch2 then consults its MAC addr table which says the dest addr is out e2.”

Isn't the destination MAC address checked first and then the VLAN tag is analyzed? That is, first after checking where to forward our frame with VLAN tag 20, we find out that we need to send it over the trunk link with native VLAN 20, so only then do we “remove” the VLAN tag and send this frame untagged over the trunk with native VLAN 20.

You can correct me if I'm wrong, your thoughts are interesting and give me a lot of food for thought as I never thought of this as metadata/descriptions.

[Joseph W. Doherty]

"Isn't the destination MAC address checked first and then the VLAN tag is analyzed?"

No, because (LAA) MACs may not be unique across VLANs.  So, you want to identify the VLAN first.

If ingress is on an access port, the port identifies the VLAN.

[Ramblin Tech]

As @Joseph W. Doherty says, the (VLAN, MAC dest addr) tuple provides uniqueness, as it is perfectly legal to reuse the same MAC address over and over in different broadcast domains or VLANs. Both VLAN ID and MAC DA must be used to lookup the egress interface.  Additionally, recall that the MAC DA might not be found in the MAC address table, resulting in flooding out multiple interfaces, some needing tags while others do not.

Popping off the VLAN tag at ingress does not mean that the VLAN ID of the frame is lost forever, because the VLAN context is retained in the packet descriptor info associated with the frame. At egress, the VLAN ID is available in the descriptor and a tag can be pushed for trunks or left off for access ports (and trunks with same native VLAN).

[krzysztofmaciejewskiit]

Thanks for the clarification. I always looked at the MAC address as something globally and locally unique.

Thanks for helping to clear up my doubts and providing me with other knowledge in the process.

[Joseph W. Doherty]

BTW, take note of a switch's MAC table column labels:

Switch#sh mac address-table 
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----

Notice the Vlan AND Mac Address AND Ports columns.

Also notice the Vlan table:

Switch#sh vlan 

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Fa0/1, Fa0/2, Fa0/3, Fa0/4
                                                Fa0/5, Fa0/6, Fa0/7, Fa0/8
                                                Fa0/9, Fa0/10, Fa0/11, Fa0/12
                                                Fa0/13, Fa0/14, Fa0/15, Fa0/16
                                                Fa0/17, Fa0/18, Fa0/19, Fa0/20
                                                Fa0/21, Fa0/22, Fa0/23, Fa0/24
                                                Gig0/1, Gig0/2
1002 fddi-default                     active    
1003 token-ring-default               active    
1004 fddinet-default                  active    
1005 trnet-default                    active    

Keeps tracks of VLANs on a port.

These two tables provide all the information we need.  I.e. as a frame enters the switch, we can see its source MAC and VLAN it's in.  Then, based on frame's destination MAC, switch can determine where to send (what ports, if any) frame, and how it should be sent for a particular egress port.

[krzysztofmaciejewskiit]

This now seems even more logical.