Skip to main content

The End of Trilogy (Hopefully)

I was going through my usual reading today, to be exact, Chapter 3: Troubleshooting LAN Switching of CCNA ICND2 Official Cert Guide 3rd Edition and I came across a text explaining the details of switch forwarding path. And then I just realized that I totally miscomprehend the idea of VLAN tagging. The proof is my previous post explaining about the problem with Native VLAN. 

Quoting what I've said:
As I ping from PC1 which is in VLAN 20 to the switches which has management interface of interface VLAN 88, it has to go to R1 from the trunk link. The frame was supposed to be tagged with VLAN 88 but since we defined VLAN 88 on S2 as the Native VLAN, the frame is not tagged (no 802.1Q header).

My idea is when a host has to send a frame to a host in another VLAN, the switch tags the frame with VLAN ID of the receiving host before forwarding it to the trunk link -- this is where I got it wrong. 

What's right:

When a switch receives a frame on a port (assuming it's in STP Forwarding State), the switch checks the VLAN in which this port belongs. If this VLAN is not the Native VLAN then add an 802.1Q header with this VLAN ID before forwarding it to the trunk, otherwise forward the frame to the trunk without any 802.1Q header (untagged).

In this case therefore, the frame forwarded by S2 is tagged with VLAN 20 and not an untagged traffic.

I looked and looked for the right explanation and I got this:
Control traffic sent on the native VLAN should be untagged. If an 802.1Q trunk port receives a tagged frame on the native VLAN, it drops the frame.
~ CCNA3 LAN Switching and Wireless

So that explains it! So this is what actually happened: As I ping from PC1 (VLAN 20) to Interface VLAN 88 of S2, S2 receives the frame from PC1 sees that it came from VLAN 20, tags the frame with VLAN 20 before forwarding it to the trunk port. The router receives the frame on VLAN 20 subinterface, removes the data link headers and trailers, routes the packet,  add the new headers and trailers, tags the frame with VLAN 88 and forwards the frame to the VLAN 88 subinterface. S2 receives the frame, sees the tag (VLAN 88) but since traffic sent to Native VLAN should be untagged, it drops the frame.






Old R1 config:
R1(config)#interface fa0/1.88
R1(config-subif)#encapsulation dot1q 88
R1(config-subif)#ip address 192.168.7.126 255.255.255.192

The solution I gave on my previous post which is to add the 'native' keyword in the command is still correct, only my explanation for why the ping gets dropped is wrong. So what the 'native' keyword does is that the frame from R1 will not be tagged with VLAN 88, instead R1 will not add any 802.1Q header in the frame (untagged). S2 will not drop the frame because it is untagged and therefore the ping will work.

New R1 config:
R1(config)#interface fa0/1.88
R1(config-subif)#encapsulation dot1q 88 native
R1(config-subif)#ip address 192.168.7.126 255.255.255.192



Conclusion: Native VLAN is a very confusing topic. There are so many discussions in LearningNetwork with people trying to understand how it works. So far this blog helps me keep track of development with my study. If I find mistake in my work, I can go through it again, try to make it right and learn, which is the whole point of all of this. 


Packet Tracer Sim

Comments