12-13-2011 10:48 PM - edited 03-07-2019 03:53 AM
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
12-13-2011 11:29 PM
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
12-13-2011 11:54 PM
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?
12-14-2011 12:04 AM
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
12-14-2011 12:13 AM
Somu, yes, but STP will still NOT converge on the new native VLAN. See my response to Naidu below.
12-13-2011 11:47 PM
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.
12-14-2011 12:12 AM
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!
12-15-2011 02:53 AM
In case anyone is interested, I verified this in my lab yesterday....
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide