Yesterday, we talked about how trunk ports carry traffic for multiple VLANs by using a tag to hold the VLAN ID. What if this tag is missing, i.e. an incoming packet is untagged? This packet is then assigned to the native VLAN. The purpose of the native VLAN is to simply send and accept untagged packets on trunk ports. The native VLAN packets going out a trunk port are not tagged and untagged packets received on the trunk port are associated with the native VLAN. By default, the native VLAN is VLAN 1. Example:
SW1# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
The switchport trunk native vlan command sets the native VLAN ID. Let's change the native VLAN on SW1 to VLAN 10.
interface GigabitEthernet1/1
switchport trunk native vlan 10
SW1# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 10
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
SW1# show interface gi1/1 switchport
Name: Gi1/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 10 (VLAN0010)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
The native VLAN on the other end of the trunk (SW2) is still the default VLAN 1. Cisco Discovery Protocol (CDP) catches the mismatch and sends a notification message. However, this is only to indicate the condition in the network, it is not an error and CPD does not shut down any operations due to it. CDP can be disabled with the no cdp enable interface configuration command, which would effectively stop the CDP messages.
*Dec 18 09:38:11.041: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/1 (10), with SW2 GigabitEthernet1/1 (1).
If the native VLANs are not the same on both ends of a trunk link, it can lead to what is called VLAN hopping, which we'll look at next. First, let's configure SW2 to use VLAN 20 as the native VLAN.
interface GigabitEthernet1/1
switchport trunk native vlan 20
SW2# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 20
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
*Dec 18 09:40:37.111: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/1 (20), with SW1 GigabitEthernet1/1 (10).
Next, let's assign an IP address from the same subnet to interface VLAN 10 on SW1 and interface VLAN 20 on SW2.
interface vlan 10
ip address 192.168.100.1 255.255.255.0
no shutdown
SW1#show ip interface brief | include Vlan
Interface IP-Address OK? Method Status Protocol
Vlan10 192.168.100.1 YES manual up up
interface vlan 20
ip address 192.168.100.2 255.255.255.0
shutdown
SW2#show ip interface brief | include Vlan
Interface IP-Address OK? Method Status Protocol
Vlan20 192.168.100.2 YES manual up up
Now, the big question is can SW1 ping SW2? Yes, it can.
SW1#ping 192.168.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms
However, I did not expect this to happen and in reality the answer is a little more complex. I was expecting STP to generate a Port VLAN Mismatch or *PVID_Inc error and put the ports in a non-forwarding inconsistency state. Because... Each PVST+ BPDU has a special TLV, which carries the VLAN ID in which the PVST+ BPUD was originated. This TLV is analyzed and compared to the VLAN in which the BPDU is received to detect native VLAN mismatches. See: Troubleshooting Spanning Tree PVID- and Type-Inconsistencies
Anyway, you can see that VLAN 10 packets from SW1 are able to "jump" to VLAN 20 on SW2 because the packets are sent untagged on the trunk port with mismatched native VLANs. Remember the definition of the native VLAN from earlier in this post: SW1 sends the VLAN 10 packets (its native VLAN) without a tag and when SW2 receives these untagged packets it associates them with VLAN 20 (its native VLAN).
In theory, it is possible to mix VLANs by mismatching the native VLANs but in practice STP should have prevented it. However, disabling STP would have allowed the ping again. The labs are run on VIRL, which is perhaps why the results were not as expected. There is also the switchport trunk native vlan tag command option, which would enable the tagging of the native VLAN traffic on a per-port basis. When tagging is enabled, all the packets on the native VLAN are tagged and all incoming untagged data packets are dropped, but untagged control packets are accepted.
Cisco documentation: switchport trunk native vlan
SW1# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
The switchport trunk native vlan command sets the native VLAN ID. Let's change the native VLAN on SW1 to VLAN 10.
interface GigabitEthernet1/1
switchport trunk native vlan 10
SW1# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 10
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
SW1# show interface gi1/1 switchport
Name: Gi1/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 10 (VLAN0010)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
The native VLAN on the other end of the trunk (SW2) is still the default VLAN 1. Cisco Discovery Protocol (CDP) catches the mismatch and sends a notification message. However, this is only to indicate the condition in the network, it is not an error and CPD does not shut down any operations due to it. CDP can be disabled with the no cdp enable interface configuration command, which would effectively stop the CDP messages.
*Dec 18 09:38:11.041: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/1 (10), with SW2 GigabitEthernet1/1 (1).
If the native VLANs are not the same on both ends of a trunk link, it can lead to what is called VLAN hopping, which we'll look at next. First, let's configure SW2 to use VLAN 20 as the native VLAN.
interface GigabitEthernet1/1
switchport trunk native vlan 20
SW2# show interface trunk
Port Mode Encapsulation Status Native vlan
Gi1/1 on 802.1q trunking 20
Port Vlans allowed on trunk
Gi1/1 1-4094
Port Vlans allowed and active in management domain
Gi1/1 1,10,20
Port Vlans in spanning tree forwarding state and not pruned
Gi1/1 1,10,20
*Dec 18 09:40:37.111: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/1 (20), with SW1 GigabitEthernet1/1 (10).
Next, let's assign an IP address from the same subnet to interface VLAN 10 on SW1 and interface VLAN 20 on SW2.
interface vlan 10
ip address 192.168.100.1 255.255.255.0
no shutdown
SW1#show ip interface brief | include Vlan
Interface IP-Address OK? Method Status Protocol
Vlan10 192.168.100.1 YES manual up up
interface vlan 20
ip address 192.168.100.2 255.255.255.0
shutdown
SW2#show ip interface brief | include Vlan
Interface IP-Address OK? Method Status Protocol
Vlan20 192.168.100.2 YES manual up up
Now, the big question is can SW1 ping SW2? Yes, it can.
SW1#ping 192.168.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms
However, I did not expect this to happen and in reality the answer is a little more complex. I was expecting STP to generate a Port VLAN Mismatch or *PVID_Inc error and put the ports in a non-forwarding inconsistency state. Because... Each PVST+ BPDU has a special TLV, which carries the VLAN ID in which the PVST+ BPUD was originated. This TLV is analyzed and compared to the VLAN in which the BPDU is received to detect native VLAN mismatches. See: Troubleshooting Spanning Tree PVID- and Type-Inconsistencies
Anyway, you can see that VLAN 10 packets from SW1 are able to "jump" to VLAN 20 on SW2 because the packets are sent untagged on the trunk port with mismatched native VLANs. Remember the definition of the native VLAN from earlier in this post: SW1 sends the VLAN 10 packets (its native VLAN) without a tag and when SW2 receives these untagged packets it associates them with VLAN 20 (its native VLAN).
In theory, it is possible to mix VLANs by mismatching the native VLANs but in practice STP should have prevented it. However, disabling STP would have allowed the ping again. The labs are run on VIRL, which is perhaps why the results were not as expected. There is also the switchport trunk native vlan tag command option, which would enable the tagging of the native VLAN traffic on a per-port basis. When tagging is enabled, all the packets on the native VLAN are tagged and all incoming untagged data packets are dropped, but untagged control packets are accepted.
Cisco documentation: switchport trunk native vlan
Comments
Post a Comment