Does the native VLAN need to be allowed on the trunk port? - Page 2

darcy · ‎02-28-2011

I have a question on if the Native VLAN needs to be allowed on the trunk port? Below is an example:

switch A

vlan 310
name MAN
!
vlan 333
name NATIVE

interface Port-channel2
description * MAN EtherChannel *
switchport trunk encapsulation dot1q
switchport trunk native vlan 333
switchport trunk allowed vlan 310
switchport mode trunk

interface GigabitEthernet1/0/2
description UPLINK
switchport trunk encapsulation dot1q
switchport trunk native vlan 333
switchport trunk allowed vlan 310
switchport mode trunk
speed 100
duplex full
channel-group 2 mode active

interface GigabitEthernet2/0/2

description UPLINK

switchport trunk encapsulation dot1q

switchport trunk native vlan 333

switchport trunk allowed vlan 310

speed 100

duplex full

channel-group 2 mode active

weylin.piegorsch · ‎07-28-2017

I've seen a lot of responses to this, some recent some old. Many have good information, some have misleading or wrong information.

First - my summarized recommendation to the original question:

tag the native VLAN
do not use the native VLAN for any purposes except to be the native VLAN
ensure the native VLAN is listed in the "switchport trunk vlan allowed ..." list
ensure STP operates on the native VLAN
do not use VLAN 1 as your native VLAN
understand your business requirements: business reality can override these recommendations

More details....

Never use VLAN 1.
There is ALWAYS a native VLAN being used. It is extremely difficult to have nothing forwarding on the native VLAN. This is because Layer-1 and Layer-2 protocols like LLDP, LACP, DTP, STP, UDLD, and so forth run on the native VLAN (details vary by operating system). Can you disable them one-by-one? Sure... but, it's not worth the effort - some of them (UDLD, LACP, LLDP, STP...) are REALLY useful.
Cisco proprietary protocols like CDP, VTP, and PAgP will ALWAYS communicate on VLAN 1; sometimes industry standard protocols like STP also run on VLAN 1, although again details vary by operating system. Even if you change the native VLAN, even if you do not allow either the native VLAN or VLAN 1 on the trunk, these protocols will always run on VLAN 1. This is why some Cisco operating systems will not allow you to issue the command "no vlan 1", or to set VLAN 1 to any shutdown or suspended state.
1. For heaven's sake, do not use VLAN 1 for native, management, voice, or any other purpose. Ever.
STP will often communicate on VLAN 1, and also on the native vlan (if the native VLAN is active in the VLAN database) regardless if the VLAN is on the trunk allowed list. Details vary by... you get the point, but note that STP specifically has some peculiarities you might encounter; as with any recommendation, test in a controlled environment to understand the specific behavior in your architecture. Especially STP, it's often a forgotten-about protocol that will bite you in the ankle.
I highly recommend either: tagging the native VLAN; or using a VLAN that isn't used for anything else - unless there is a reason not to do so. Ideally, do both. If you don't tag the native VLAN, or if you put production data on the native VLAN, malicious actors can hop across VLANs, and gain access to resources you thought were protected by things like ACLs, firewalls, etc. The mechanism has to do with doubly-tagged frames, you can look it up if you want. If you either tag the native VLAN or use a dedicated native VLAN, this issue goes away. And for heaven's sake, don't use VLAN 1 for anything, ever.
Do not use VLAN 1 for any purposes, ever.
Depending on where you read, Cisco sometimes recommended tagging the native VLAN and not list it in the "trunk allowed" list. However, I recently had a TAC case about link-flap due to STP issues. Problem was fixed by adding the native VLAN to the list.
Tag it. The only reason (classically, anyway) to have an untagged native VLAN on the trunk allowed list is to allow a switch in the midst to parse traffic, if that switch is incapable of handling .1q-tagged frames. In fact, it's a widespread design recommendation to have a native VLAN different from a management VLAN, and have both native and management VLANs be different from all VoIP VLANs, have all of that be different from client VLANs, and to never use VLAN 1. If you're in a niche scenario where you need to have an untagged VLAN on a trunk, then by all means do so - though I'll argue if at all possible, alter the requirement.
1. Sometimes you MUST have an untagged VLAN on a trunk port, and this VLAN must be a production VLAN. See below for an example I need to deal with, as an example of "business requirements trump this post."
Tagging the native VLAN; changing the native VLAN away from VLAN 1; having different native, management, and client VLANs; and not having the native VLAN in the list of trunk allowed VLANs, are recommended best practices by Cisco.
Remember to configure both ends of a trunk the same way, with regard to native VLAN assignment, and native VLAN tagging.
Do not use VLAN 1 for any purpose. Ever. I'll say it as long as I need to.
Regardless if the port is configured to tag the native VLAN, an incoming untagged frame or a tagged frame on VLAN 0 will be accepted onto the native VLAN. Also, even if the port is mode access, an incoming frame on VLAN 0 is assumed to be on the access VLAN. This is how end-hosts set COS (consider softphones, Skype, etc), since the 802.1p COS bits are contained within the 802.1q header. (As an aside: this is also specifically the reason for VLAN 0, and why you can't set VLAN 0 on the trunk allowed list.)
If you have a native VLAN mismatch, the trunk will still come up, and the non-native VLANs will still behave the same way. However, performance of the native VLAN depends on if the trunk is tagging the native VLAN.

If both sides are NOT tagged, but are configured for the same native VLAN, then you're ok (but still subject to Q-in-Q attacks, see above).
If both sides are NOT tagged, but are configured for different native VLANs, you're still subject to Q-in-Q attacks, but you also run the risk of introducing switching loops, and traffic will hop between VLANs. CDP will report a native VLAN mismatch about once a minute in the logs.
If only one side is tagging the native VLAN, then the side configured as untagged native will drop incoming tagged frames that are not on the "trunk allowed" list. The side that is configured to tag the native VLAN will happily accept any incoming untagged frames or VLAN 0 tagged frames onto the native vlan.
If both sides are tagging the native VLAN, then there will only be client communication on the native VLAN if both sides allow the native VLAN ID in the "trunk allowed" list.
Reminder that even if the native VLAN is not on the "trunk allowed" list, it's still passing a fair bit of traffic like UDLD/LACP/etc.

Have I mentioned yet to not ever use VLAN 1?
If your business reality demands deviating from any of the above, heed your business demand. Even if that means using VLAN 1. But if you do, test test test, and understand the impact this will cause.

To properly understand native VLANs, you have to consider the industry at the time IEEE defined the 802.1q standard (1998).

Largely, most switches... ahem "most non-Cisco switches" were just dumb switches. they took a frame, if it was a "known unicast" it would forward to the appropriate port but all BUM (Broadcast / Unknown Unicast / Multicast) traffic would flood the incoming frame out all interfaces except the one it came in on. The concept of VLANs was not known, so all that flooding would happen to ALL ports. 802.1q allowed this to be curtailed, but only for those switches that understood how to read it.

Cisco had "ISL", which was one of the early implementations of VLANs, but ISL was proprietary. (Fast aside: the professor that wrote the formal academic paper conceptualizing VLANs, actually differentiated the LANs using "colors" rather than numbers. This was 1982-1988. Here's the original research paper.)

So, 802.1q has a different EtherType. In order to allow compatibility between switches that understood 802.1q and switches that did not understand 802.1q, IEEE devised the concept of a "native" VLAN - the one VLAN that would be sent with a standard DIX-II EtherType (aka what we now colloquially call "untagged"). This would allow hosts connected to such switches, to still communicate on the network

These days, those kinds of switches are rare in corporate LANs (though D-Link, Linksys, NetGear, and similar really really cheap consumer-grade switches are still something this primitive). For certain, all routers (ASR1k, ASR9k, ISR, etc) and most (all?) ASAs and FirePowers can be configured to be VLAN-aware, and all Cisco Catalyst, MetroEthernet, IndustrialEthernet, and Nexus switches understand native VLAN tagging really well. But, the untagged native VLAN capability is still there.

Weylin

PS - example when a native VLAN must be untagged:

The Cisco LWAP 1810W and 1815W are APs that are wall-mounted, and provide wired RJ45 ports in addition to wireless 802.11n. VLANs to apply to the RJ45 ports come on the AP's uplink port as tagged VLAN(s), and the management of the AP itself (including the CAPWAP-encapsulated WiFi traffic) is an untagged VLAN. In this case, the port on the switch that the AP connects to, that port would have a VLAN to manage the AP, which may/may not be the same as the VLAN to manage the switch (for my network, switch and LWAP management are on separate VLANs/subnets), and client VLANs and FlexConnect VLANs would be 3rd (and 4th, and...) VLANs. The trunk between the switch and the router would has a native VLAN, but since access-layer switches tend to only have a global setting for native VLAN tagging, and since I must have an untagged native VLAN to the AP, I therefor must also have an untagged native VLAN to the router. In order to show protection against doubly-tagged frames, use a native VLAN on the switch/router link that purpose-implemented explicitly for native VLAN.

PPS - in case you're wondering, I run a large university campus, with about a dozen-and-a-half Catalyst 6807s. Most of them support a handful of buildings. A few of them handle a lot of small buildings; the largest has 95 buildings on it (all of them small buildings). With that, I have 95 native VLANs defined, one for each building, all of them tagged and none of them in the "trunk allowed" list.

PPPS - this is a typical router port config on my network (the downstream switch is a Catalyst 3850-24P-L)

Cat6807#show run | inc vlan dot1q
vlan dot1q tag native
Cat6807#
Cat6807#
Cat6807#
Cat6807# show run vlan 2800
Building configuration...

Current configuration : 48 bytes
!
vlan 2800
 name CompSci_Native-no_IP
end

Cat6807#
Cat6807#
Cat6807#
Cat6807# show run int vlan 2800
Building configuration...

Current configuration : 247 bytes
!
interface Vlan2800
 description Native VLAN to Computer Science faculty offices. VLAN INTERFACE SHUTDOWN BY DESIGN
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 shutdown
end

Cat6807#
Cat6807#
Cat6807#
Cat6807# show run int t7/2
Building configuration...

Current configuration : 612 bytes
!
interface TenGigabitEthernet7/2
 description CompSci Faculty Workstation Switch Gig1/1/1
 switchport
 switchport trunk native vlan 2800
 switchport mode trunk
 switchport trunk allowed vlan 20,150,152,153,2000,2200,2400,2800
 switchport nonegotiate
 platform qos trust cos
 udld port aggressive
 service-policy type lan-queuing input c6800-48p-sfp-qos-ingress-policy
 service-policy type lan-queuing output c6800-48p-sfp-qos-egress-policy
end

Cat6807#

Edit 11/28/17:

The above info is corrected. Erroneous information I just updated:

- VLAN 1 can sometimes be disabled; sometimes not; depends on the specific operating system.

- Corrected VLAN 0 info

- Corrected the effects of native VLAN configuration mismatch

- minor typographical errors

Edit 2/7/18:

Added link to original academic paper on VLANs.

Edit 7/26/2019:

Updated:

- sometimes a non-tagged VLAN is required on a trunk; included a specific example

- can use either a non-production native VLAN, or a tagged native VLAN (or both) to show protection against Q-in-Q attack

Edit 7/18/2020:

Added summarized recommendation; added commentary about VLAN 1; corrected recommendation about adding native VLAN to "trunk allowed" list based on recent revelation from TAC case; updated demonstration config to replace Cat6509 with Cat6807.