cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
68710
Views
137
Helpful
15
Replies

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

darcy
Level 1
Level 1

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 15

Joe Conklin
Level 1
Level 1

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.

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

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.

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.

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.

glen.grant
VIP Alumni
VIP Alumni

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

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

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

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

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

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

ranraju
Cisco Employee
Cisco Employee

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

Dennis Mink
VIP Alumni
VIP Alumni

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,

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco