About native VLAN of a trunk port and access VLAN of an access port.

Unanswered Question
Aug 20th, 2010

In some texts I have found the concept of a link with "native VLAN association

when in access mode", which is different from native VLAN association when in trunk mode.

I do not understand if the "native VLAN association when in access mode" is the usual access VLAN when the port is an access port, and if the concept refers to when I change the mode from trunk to access, the "native" VLAN is the VLAN of the port

when it returns in access mode.

I know that a trunk port has a native VLAN and that before becoming a trunk it was an access port with default or not default access VLAN.

The access VLAN before becoming a trunk is a concept, the native VLAN after becoming a trunking is an other concept.

Is it possible that someone calls native VLAN access port the accessVLAN of the port when this port does not trunk

anymore?

Thanks.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Edison Ortiz Fri, 08/20/2010 - 07:14

The native Vlan on a trunk port is send with untagged frames so you can have another device attached to the port with or without trunk

configured and be able to connect to any devices participating on the native vlan.

For instance, if you configure a switchport with native vlan 20, then a workstation can connect to this port without any trunking configured on the NIC and belong to Vlan 20.

That's the reason you see the reference of the 'access mode'

Regards,

Edison

speculor_cisco Fri, 08/20/2010 - 07:48

Thanks for the answer.

But the concept of "native VLAN" belongs to a trunk port, isn't it?

This is the text I was speaking about:

"When troubleshooting VLANs, note that a link can have one native VLAN association

when in access mode and another native VLAN association when in trunk mode."

How do you interpret it?

Edison Ortiz Fri, 08/20/2010 - 07:55

But the concept of "native VLAN" belongs to a trunk port, isn't it?

Yes, but a trunk port can provide connectivity to another device configured as access mode. It doesn't necessarily need to be configured as trunk at both ends.

"When troubleshooting VLANs, note that a link can have one native VLAN association

when in access mode and another native VLAN association when in trunk mode."

That's incorrect. There can only be one Native Vlan per switchport regardless of its port status 'access or trunk'.

Regards,

speculor_cisco Fri, 08/20/2010 - 08:25

When a trunk port returns to an access port, the VLAN of the access port is not necessarily the

native VLAN of the old trunk, isn't it? If native VLAN means frame untagged, may be that a port

could have two different VLANs where the frame are forwarded untagged. For example:

Port Fa0/1     trunk     native VLAN VLAN 10     access VLAN VLAN 20

When the port is a trunk, the frames are untagged in VLAN 10.

When the port is an access port, obviously the frames are untagged in VLAN 20.

May be the text wanted to do this difference.

Edison Ortiz Fri, 08/20/2010 - 08:34

When a trunk port returns to an access port, the VLAN of the access port is not necessarily the

native VLAN of the old trunk, isn't it?

This would depend on the trunk mode. We often configure the trunk as 'switchport mode trunk' which means the switchport will always be in trunking mode regardless the connected device on the switchport.

If you use dynamic trunking (desirable or auto) then the trunking will only be enabled when the connected device is a trunk.

On this case, you will need to configure the 'switchport access vlan xx' command along with the 'switchport trunk encap native vlan xxx' command and yes both can be different. But in the case of the switchport access vlan xx command, we don't refer to it as the 'native' vlan so that's the reason I said the book was incorrect on its reference.

Regards,

Edison

speculor_cisco Fri, 08/20/2010 - 08:46

I agree.

I put the post because that text had confused me.

I had read an other text with a definition of "native vlan" not so clear, but now I can not find it.

May be it will be the argument of an other question.

Thanks for the discussion.

milan.kulik Sat, 08/21/2010 - 00:59

Hi guys,

all this terminology mismatch comes from ancient CatOs times when "trunk native VLAN" was defined as "a VLAN which is sent untagged on trunk and to which the port belongs if fails to become a trunk".

The command

set vlan ...

was used.

Currently in IOS those two features are separated:

switchport trunk native vlan ...  configures the first feature

switchport access vlan ... configures the second feature.

See http://www.cisco.com/en/US/customer/tech/tk389/tk689/technologies_configuration_example09186a008009441a.shtml#configs

and command reference guides for details.

BR,

Milan

Dasuntha_Dinesh Sat, 08/21/2010 - 01:34

Hi Edison,

I m not sure about below comment,

Yes, but a trunk port can provide connectivity to another device  configured as access mode. It doesn't necessarily need to be configured  as trunk at both ends.

Actually both side sides should be configured as trunk to communicate each other.

If one side is configured as trunk & the other side as access mode, devices cant communicate each other.

Regards,

Dasuntha

Peter Paluch Sat, 08/21/2010 - 05:20

Hi Dasuntha,

Regarding the Edison's comment: Edison is correct. A normal device, such as PC or a printer connected to a trunk can communicate within the native VLAN of the trunk. Note that a native VLAN is by definition a VLAN that does not use any 802.1Q tags on a particular trunk port, that is,

  • If a frame in the native VLAN is sent out a trunk port, it will not be tagged
  • If a frame without a tag is received on a trunk port, it will be assigned to the native VLAN

Note that the communication in the native VLAN is the same as normal Ethernet communication on an access port - no tags, just plain Ethernet frames.

It is true that a normal device connected to a trunk port will not understand tagged frames. Or better said, it will understand them as Ethernet frames containing an unknown protocol in their payload (because of the EtherType value of 0x8100) and thus it will drop them. It is the same situation as if an IPv6 packet arrived to a station that speaks only IPv4. It understands the frame but it does not understand the payload. However, this situation will not prevent the station from speaking IPv4, just like a station connected to a trunk port is not prevented from communicating in the native VLAN.

That being said, the native VLAN is an unfortunate feature. Perhaps there was originally a good idea behind it but the notion of a native VLAN is not really helpful. It is a bad design to connect a trunk port to a non-802.1Q-capable device. It would have been much better if the entire native VLAN idea simply did not exist.

For those more involved: there is actually no direct reference to a native VLAN in the current 802.1Q standard. This standard merely defines a PVID (primary VLAN ID) on a switched port that does not use tags, and a set of other VIDs that obviously need to use tagging. There is also no reference to a trunk port, therefore, the current terminology and architecture of the 802.1Q standard does not easily allow any ammendment of the type "there is no PVID allowed on a trunk port" because the trunk port is not defined.

Best regards,

Peter

Actions

Login or Register to take actions

This Discussion

Posted August 20, 2010 at 7:01 AM
Stats:
Replies:10 Avg. Rating:
Views:3119 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,730
4 7,083
5 6,742
Rank Username Points
160
77
70
69
50