Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

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

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

15 REPLIES
New Member

Re: Does the native VLAN need to be allowed on the trunk port?

Yes. Anything you attach to a router or a switch must use the same native VLAN. If you login to the router or switch that is using a different native vlan you will receive a message continually stating native vlan mismatch.

New Member

Re: Does the native VLAN need to be allowed on the trunk port?

With the switch configured in my example what would I expect to see?  Would traffic on the native VLAN be passed along the trunk?

New Member

Re: Does the native VLAN need to be allowed on the trunk port?

Maybe I did not understand. Let me explain a bit further. Hopefully I can explain.

When you configure a trunk it allows all vlans native or not native to cross the truck. If you have a switch that has a trunk point on port 1, and a router connected to the port as a trunk on both ends all vlans will be allowed through that trunk. You do not need to specifically specify the native vlan access to the trunk. However.. if you have a native vlan of 1 on one side, and the native vlan of lets say 2 on the other end then you will receive a native vlan mismatch message. Then you will likely have no communication over the trunk between the switch, and router.

New Member

Hi @joe conk

Hi @joe conk

thanks for your answer, I had the same doubt but right now I´ve got it!

So, as a summary:

The Native VLAN should not be included in the allowed vlan list in the command:

#switchport trunk allow vlan X,Y,Z

Hence VLAN´s X,Y and Z are any VLAN, but not the Native VLAN.

New Member

Hi Joe,

Hi Joe,

Please read the question, the question was does the native vlan need to be allowed on the trunk port , in the allowed vlan cli? 

I do not understand how your answer addresses that question.

Purple

Re: Does the native VLAN need to be allowed on the trunk port?

No it does not need to be in the "switchport trunk allowed statement " ...

Re: Does the native VLAN need to be allowed on the trunk port?

Hello,

Let me try to understand (and not explaining )

Router1(Gig1/1.101)---Trunk----Switch-------Router2

When will i call vlan101 as a native ? In a scenario where I assume that Router2 is unaware of any vlan stuff.


Or you can assume I have attached PC which do not understand Vlan language.

May be below event happening from Router2 to Route1

>Router2 will sent untag frame (because it doesn't know about this)
> Switch sees this frame as untag and assume to be part of vlan101 (native)
> Now question comes: how switch send frame to router, obviously without tag so I don't think

   we need to define this in allowed vlan statement.

This is what I understood, anybody can confirm my understanding please?

Regards
Mahesh

Cisco Employee

Re: Does the native VLAN need to be allowed on the trunk port?

Yes, Lets consider a PC instead of a router2 connecting to the switch.

If you have made this port on the switch as "access port" and if the port is in "access vlan 101", then all the packets that are coming from the PC are considered to be in vlan101, and the switch after receiving the packet on that port it tags it and says its from vlan101.

Now if this frame that is tagged to be in vlan101 needs to go to the Router1, the switch has to send it over the trunk link, switch has to do 2 things now, ONE - is the vlan101 allowed on the trunk? TWO - is vlan101 defined as native vlan on the trunk?

ONE - only if the vlan101 is allowed on the trunk, the switch forwards the frames for vlan101.

TWO - "native vlan" is for the trunk and not for the switch on a whole... if you have 2 or more trunks on the switch, you can configure different native vlans on each trunk. So you are telling the switch what frames on the trunk link should go untagged.

Hope this gives you some clarity...

Regards,

ranraju

Re: Does the native VLAN need to be allowed on the trunk port?

Hi ranraju,

Thanks for the explanation, but now confusion arise after reading below

If you have made this port on the switch as "access port" and if the port is in "access vlan 101", then all the packets that are coming from the PC are considered to be in vlan101, and the switch after receiving the packet on that port it tags it and says its from vlan101.

specially line: switch after receiving the packet on that port it tags it and says its from vlan101.

If switch tags frame with vlan101 then why do we need native vlan command on trunk port to tell switch trunk port that we are not going to

receive any tagged frame.

If switch is tagging frame on behalf of PC then we do not need any native command.

Thanks to clarify above point

Regards

Mahesh

Cisco Employee

Re: Does the native VLAN need to be allowed on the trunk port?

If switch tags frame with vlan101 then why do we need native vlan command on trunk port to tell switch trunk port that we are not going to

receive any tagged frame.

we need native vlan on the trunk port to send frames untagged for that vlan only, so before the switch sends a frame on the trunkport(which has native vlan 101), what switch does is before it puts this frame on the trunk it removes the vlan information(untags the frame) and sends it on the trunk link.

native vlan command on the trunk port does not tell the switch trunk port that - "we are not going to receive any untagged frame" - but it tells the switch trunk port that - "if i receive any untagged frame the trunk port then i am going to put it in vlan101(native vlan)"

Hope it makes sense now..

(please rate useful posts)

Regards,

ranraju

Re: Does the native VLAN need to be allowed on the trunk port?

Hello,

Below statement clear my doubt

 "if i receive any untagged frame the trunk port then i am going to put it in vlan101(native vlan)"

Thanks for this

Regards

mahesh

Cisco Employee

Re: Does the native VLAN need to be allowed on the trunk port?

With this configuration:

"switchport trunk native vlan 333

switchport trunk allowed vlan 310"

you have defined the native vlan on the trunk correctly, and with this configuration, it would send the frames untagged on the trunk link for the native vlan 333, BUT since you are allowing just "vlan 310" only traffic from vlan 310 frames are allowed on the trunk. If you want to allow vlan333 aswell on the link then you should have "switchport trunk allowed vlan 310,333" configuration on the trunk link.

Hope this answers your question.

Regards,

ranraju

this is 2016, there is no

this is 2016, there is no need for native VLANs, imho.

Please remember to rate useful posts, by clicking on the stars below.

Hello Darcy and all,

Hello Darcy and all,

BLUF: No, it is not required to have Native VLAN listed under switchport trunk allowed vlan.

I too had this question, which a Google search has led me here. With my investigation to my issue relating to this, I found out an important observation. The native vlan is just another vlan like your vlan 310 name "MAN".  The big difference is that the native vlan is all untagged traffic, meaning anything not belonging in any of your other declared VLANs.

So, the question is specific to your intentions, your organization's policy and direction, all that stuff.  The native VLAN is untrusted, unidentified traffic where as you know what belongs in your declared VLANs.  In your list of VLANs for command "switchport trunk allowed vlan ###,###,###", if you include your native vlan then you are allowing all traffic across.  In my organization, our security policies and guidelines do not want to allow untrusted and unidentified traffic across trunks, so the native vlan will not be listed in the allowed list.

Hope this helps to add a little bit of information for you and anyone else.

New Member

I've seen a lot of responses

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

  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 are always running on the native VLAN.  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.
  2. STP, CDP, VTP, and PAgP will ALWAYS communicate on VLAN 1.  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 IOS will not allow you to issue the command "no vlan 1", or to set VLAN 1 to any shutdown or suspended state.
  3. STP will communicate on VLAN 1, and also on the native vlan (if the VLAN is active in the VLAN database) regardless if the VLAN is on the trunk allowed list.
  4. I highly recommend tagging the native VLAN, unless there is a reason not to do so.  If you don't tag 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 tag the native VLAN, this issue goes away.
  5. There is nothing wrong with not including the native VLAN in a trunk allowed port.  the only reason 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 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, and have all of that be different from client VLANs.  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 that if at all possible, alter the requirement).  Otherwise, I recommend you don't include the native VLAN in the trunk allowed list.  You'll save yourself the pain of STP issues.
  6. tagging the native VLAN; changing the native VLAN away from VLAN 1; having differnet native, management, and client VLANs; and not having the native VLAN in the list of trunk allowed VLANs, are recommended best practices by Cisco.
  7. remember to configure both ends of a trunk the same way, with regard to native VLAN assignment, and native VLAN tagging.
  8. If native VLANs are not tagged, an incoming untagged frame will be accepted onto the native VLAN.  Also, regardless if the native VLAN is tagged or not, and regardless if the port is mode trunk or mode access, an incoming frame on VLAN 0 is assumed to be on the native 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.
  9. 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.
    1. If both sides are NOT tagged, then you will still have data passing, but you run the risk of introducing STP loops.  CDP will report a native VLAN mismatch about once a minute in the logs.
    2. If one side is tagging the native VLAN, then the other side can send successfully, but it will drop incoming tagged frames that are not on the "trunk allowed" list.
    3. If both sides are tagging the native VLAN, there will be no communication on the native VLAN.
    4. Reminder that even if the native VLAN is on the "trunk allowed" list, it's still passing a fair bit of traffic like UDLD/LACP/etc.

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 floodding 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 in the 1980s.)

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.  For certain, all Cisco Catalyst and Nexus switches understand tagging.  But, the capability is still there.

Weylin

PS - in case you're wondering, I run a large university campus, with about a dozen Catalyst 6509Es (we're gearing up to replace them with 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.

PPS - this is a typical router port config on my network

  1. 2000 is a management VLAN
  2. 2400 is a VoIP VLAN
  3. the others are client VLANs
  4. the downstream switch is a Catalyst 3850-24P-L
  5. the "queue" commands I'm excluding are a large series of WRED commands (unrelated to this post)
Cat6509#show run | inc vlan dot1q
vlan dot1q tag native
Cat6509#
Cat6509#
Cat6509#
Cat6509# show run vlan 2800
Building configuration...

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

Cat6509#
Cat6509#
Cat6509#
Cat6509#show run int Gig3/22 | exclude queue
Building configuration...

Current configuration : 983 bytes
!
interface GigabitEthernet3/22
description CompSci Faculty Workstation Switch (10.1.17.22) Gig1/1/1
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 2800
switchport trunk allowed vlan 20,150,152,153,2000,2400
switchport mode trunk
switchport nonegotiate
udld port aggressive
mls qos vlan-based
end

Cat6509#
6515
Views
25
Helpful
15
Replies