Native VLAN Review

visitor68 · ‎12-13-2011

Hi, folks:

1.) If you don't mind, let's talk about something basic: native VLANs. Legend has it that there is a need for a native VLAN (aka a VLAN in which untagged traffic is placed) for backward compatibility with switches that don't support dot1q tagging. But I think that has not been the case in many years. So what do we really need a native VLAN for these days?

2.) Also, by default, control plane traffic, such as CDP, PAgP, LACP, and VTP, send untagged frames between switches for protocol convergence. And also, by default, VLAN 1 is the VLAN in which untagged traffic belongs/is placed (the native VLAN). It is considered a best practice to block VLAN 1 on inter switch dot1q trunks - why, I'm not exactly sure. Anyway, if VLAN 1 is indeed blocked, how can the untagged contol plane frames exit the switch and how can the protocol converge across a switch pair or across the L2 domain (like VTP)?

3.) Lastly, sometimes the native VLAN is changed on a dot1q trunk from VLAN 1 to, say, VLAN 999 (or whatever other number). Why is that? What is the real value in doing that?

Thanks in advance for the answers.

JS

Somasundaram Jayaraman · ‎12-13-2011

Hi,

++ Native vlan no can be changed but it cannot be blocked.

For testing purpose i created this setup:

=============================

sw1--fa0/19-----fa0/19--sw3

SW1 configs:

=========

switch1#sh run inter fa 0/19

Building configuration...

Current configuration : 175 bytes

!

interface FastEthernet0/19

switchport trunk encapsulation dot1q

switchport trunk native vlan 3

switchport trunk allowed vlan 1,99

switchport mode dynamic desirable

end

switch1#sh int fa 0/19 trunk

Port Mode Encapsulation Status Native vlan

Fa0/19 desirable 802.1q trunking 3

Port Vlans allowed on trunk

Fa0/19 1,99

Port Vlans allowed and active in management domain

Fa0/19 1

Port Vlans in spanning tree forwarding state and not pruned

Fa0/19 1

switch1#sh int fa 0/19 sw

Name: Fa0/19

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 3 (VLAN0003)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: 1,99

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

SW2 configs:

=========

switch3#sh run int fa 0/19

Building configuration...

Current configuration : 164 bytes

!

interface FastEthernet0/19

switchport trunk encapsulation dot1q

switchport trunk native vlan 3

switchport trunk allowed vlan 1,999

switchport mode trunk

end

switch3#sh run int fa 0/19 trunk

^

% Invalid input detected at '^' marker.

switch3#sh int fa 0/19 trunk

Port Mode Encapsulation Status Native vlan

Fa0/19 on 802.1q trunking 3

Port Vlans allowed on trunk

Fa0/19 1,999

Port Vlans allowed and active in management domain

Fa0/19 1,999

Port Vlans in spanning tree forwarding state and not pruned

Fa0/19 1,999

switch3#sh int fa 0/19 sw

Name: Fa0/19

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: 3 (VLAN0003)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: 1,999

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

++ for testing purpose i have created interface vlan 3 on both sides and the pings went through fine.

switch1#sh run inter vlan 3

Building configuration...

Current configuration : 58 bytes

!

interface Vlan3

ip address 10.1.1.2 255.255.255.0

end

switch1#

switch3#sh run inter vlan 3

Building configuration...

Current configuration : 58 bytes

!

interface Vlan3

ip address 10.1.1.1 255.255.255.0

end

switch3#ping 10.1.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms

switch3#

++ Eventhough you disallow this vlan, the native vlan wont be blocked since it carries all the control traffic. And without this native vlan stp, cdp, wont work.

Regarding your third question,

++ There is no real value as such in changing the vlan numbers unless you use vlan 1 to carry data traffic. In that case you will mention a different vlan no as native vlan.

++ If the native vlan is not the same on both ends then you will see a native vlan mismatch error and referred as "vlan leaking"

Hope this answers your question.

Cheers

Somu

Rate helpful posts

visitor68 · ‎12-13-2011

These are very interesting results.

So, now lets talk about 802.1w to PVST+ convergence. For spanning-tree convergence with 3rd party switches, Cisco's PVST+ sends BPDUs to the IEEE MAC address so that the IEEE switch can process them and converge. The Cisco switch sends those BPDUs from VLAN 1, the native VLAN by default. This creates a CST.

So, if the dot1q trunk on the Cisco switch facing the IEEE switch had the command

switchport trunk allowed vlan 2,3...etc (excluding VLAN 1), it would not make a difference and the IEEE switch will still receive those BPDUs and converge on the CST?

Somasundaram Jayaraman · ‎12-14-2011

Hi,

Yes, the switch will still receive those BPDUs. Native vlan will still be in use eventhough we remove it from the allowed list.

Cheers

Somu

visitor68 · ‎12-14-2011

Somu, yes, but STP will still NOT converge on the new native VLAN. See my response to Naidu below.

Latchum Naidu · ‎12-13-2011

Hi JS,

The native vlan is a confusing topic actually. The first thing that we must remember is that the native vlan is not a global thing. We don't define a native vlan on a switch as a whole, it is defined only on a trunk port. Generally speaking frames traversing the trunk port are tagged. So if I have Host A on vlan 4 on switch A, communicating with Host B on vlan 4 of Switch B, how does that work? The answer is there is a VLAN ID inserted into the frame as it leaves Switch A's trunk port. Switch B sees this VLAN ID and knows which vlan the frame is associated with. That part is a bit more understandable.

So where does the native VLAN concept come into play? What if Switch B receives a frame on its trunk port that doesn't have any VLAN ID assigned at all? What VLAN does that frame belong to? The answer is it belongs to whatever vlan is considered the "Native" VLAN for that trunk port. By default this is one. So out of the box, a switch that receives a untagged frame on a trunk port would assume that the frame belongs to its VLAN 1.

So how did we get an untagged frame on a trunk port? We know that switches do not receive tagged frames on access ports. However access ports are in exactly one vlan. After a frame is received on an access port, the "switchport access vlan x" command would tell the switch what vlan to associate those frames with. If those frames have a destination address that take them across a trunk port, they are tagged, unless they are part of the native vlan configuration for that particular trunk. Again, by default, that is vlan 1. So out of the box, a switch would not tag traffic leaving a trunk port that is associated to vlan 1.

Why would we want to change it? By default all ports are in vlan 1 while in access mode. Additionally, all administration is done in vlan 1 (by default). There are some attacks that can utilize the native vlan to hop around vlans (VLAN hopping attacks). The best practice is not necessarily to change it to VLAN 99, but to change it to a VLAN that is completely unused in your organization. This is an older way of keeping untagged traffic off the trunk. Today, Cisco's switches can actually be configure to tag the native vlan with the "vlan dot1q tag native" global command. This eliminates the need to change the trunk's native vlan.

One more note. Cisco used to have a proprietary protocol called ISL or Inter Switch Link that was used for trunking as opposed to the 802.1q standard. This protocol tagged all frames as they went accross trunk ports. So the new command for dot1q that I mentioned above, sort of emulates this behavior. However it is not necessarily part of the 802.1q standard as far as I know.

One more note. The management VLAN and the native vlan are two completely seperate topics. However, the default management vlan and the default native vlan both happen to be vlan 1 by default.

Hope the above helped and clear you.

Please rate the helpfull posts.
Regards,
Naidu.

visitor68 · ‎12-14-2011

Naidu, very interesting. Thank you.

My concern in asking all these questions involves the issue I raise in the question I just posed to Somu. I have a client who has a 3rd party switch at the access layer and its connected to a Nexus switch at the agg layer. Both switches must have STP converge on the CST. The client has taken VLAN 1 on the Cisco side and disallowed it from the trunk to the 3rd party switch. Morevoer, he has also changed the native vlan from VLAN 1 to a dead vlan that isnt used (999).

So, if Somu's findings are correct, the new native VLAN (999) cannot be blocked from the trunk. But I still think STP will NOT converge! The reason is that STP BPDUs from the Cisco switch will be sent untagged on VLAN 1 and they will be sent to the IEEE MAC address that the 3rd party switch understands. The 3rd party switch needs to see those BPDUs to converge. Its true that the Cisco switch will also send STP BLDUs on VLAN 1 that are tagged and STP BPDUs from the new native VLAN (999) and they will be untagedd, BUT IN BOTH THE LATTER CASES, the MAC address used is the proprietary Cisco SSTP MAC, NOT the IEEE MAC!

visitor68 · ‎12-15-2011

In case anyone is interested, I verified this in my lab yesterday....