802.1Q Native VLAN on Cisco IOS Switch

(Deep) #59

Thank you for the reply Rene.
I quickly checked on both NX 3k and 2960 but dont see encapsulation options available to start with. Is there any thing on the global config that could prevent this?

NX 3K [physical interface/ without VPC, standalone]
switch(config)# interface ethernet 1/2
switch(config-if)# switchport trunk ?
  allowed  Set allowed VLAN characteristics when interface is in trunking mode
  native   Set trunking native characteristics when interface is in trunking
           mode

2960:
Switch(config)#interface GigabitEthernet0/12
Switch(config-if)#switchport trunk ?
  allowed  Set allowed VLAN characteristics when interface is in trunking mode
  native   Set trunking native characteristics when interface is in trunking
           mode
  pruning  Set pruning VLAN characteristics when interface is in trunking mode
(Lazaros Agapides) #60

Hello Deep

When you don’t have the option of adding the encapsulation, this usually means that the switch only supports one type of encapsulation, that is, dot1q. So you do not require this command since it is already configured by default. To verify this, type the show interface ethernet 1/2 capabilities command and take a look at the trunk encapsulation type. It should state 802.1Q.

I hope this has been helpful!

Laz

(rosna s) #61

Hi Andrew, I found your answer interesting and I have seen these type of configuration at many places where a Laptop/ Desktop is connected to the VoIP. My question is - " How can we configure two VLANs on a single switch port? Do we assign two diffenet IP Addresses?

(Andrew P) #62

You would set the switchport in question to be a trunk usually, with the native vlan to be the vlan the computer would use. Some Cisco equipment has a special mode of doing this specifically for voice vlans.

A real world example might help: At my company, we have the port set to be a trunk and allow both the PC and Voice vlans on the trunk, setting the PC vlan to native. The Avaya phone gets a DHCP address on the native vlan, but it looks for a special DHCP scope option that tells the phone, “you should be on the Voice vlan” The phone recognizes this, and says, “okay, I will now request an IP address on the Voice vlan.” The phone is responsible for tagging its own traffic on the Voice vlan from that point forward.

(rosna s) #63

Thank you @andrew for the clarification.

1 Like
(Cecil B) #64

Hi Andrew,
I was just browsing through the native vlan topics and i saw your reply to Ahmad. I dont understand your replay starting “To get this to work, we have to configure each port as a Trunk and allow both the VOIP VLAN and the PC Data vlan on the switch port” Which port are you configuring as a trunk?
I have configured VOIP vlan and pc data vlan on a switch port and it is not configured as a trunk port for both devices to work with the cat5 from the wall going into the phone first and then the pc connected to the phone.
The port on the switch is configured as an access port:
#sw mo access
#sw ac vlan 110 - for pc data
If i add a phone later to the same port, all i do is add the voice vlan to the port:
#sw voice vlan 333 - for phone
The port on the switch is still configured as an access port. So which port are you configuring as a trunk port? Please clarify.

1 Like
(Kevin W) #65

Hello Cecil,
Anytime you want more than one VLAN to traverse an interface you need to use a trunk. By default all VLANs are allowed over a trunk port. An access port is used for one VLAN and one VLAN only. So in this case the interface you are running VOIP and DATA on needs to be a trunk. Also in a typical setup you will have trunk ports configured between switches so hosts that are apart of the same VLAN but on different switches can communicate with each other.
I hope this helps,
Scott

(Lazaros Agapides) #66

Hello Cecil

Before the advent of the voice VLAN on Cisco switches (this is somewhere around 2004) Cisco IP phones that were set up to function with the switchport for a PC had to be connected to a port on a switch that was configured as a trunk. This trunk had the data VLAN set up as the native VLAN and the voice VLAN was the allowed VLAN on the trunk. This resulted in frames destined for the PC to reach the IP phone without a tag i.e. on the native VLAN, and frames destined for the phone carrying voice to arrive as tagged frames. The phone knew that tagged frames should be taken and processed by the IP phone and that untagged frames should be sent on to the switchport connected to the PC. This was standard procedure on Cisco switches, and this is what @andrew is describing above.

Since then, the voice VLAN has been introduced. This is a special case where the port is no longer configured as a trunk, but is configured as an access port. The extra command of voice vlan is added to indicate the VLAN that will be carrying voice packets. It essentially works the same way as the configuration described above. The advantage of the voice vlan option is the fact that CDP will be used to communicate between the phone and the switch in order to further configure QoS features (trusted mode and untrusted mode etc…)

I hope this has been helpful!

Laz

1 Like
(Kevin W) #67

Thanks for clarifying this I have zero experience with Cisco phones! I am much more use to using LLDP and tbh non-cisco network gear. I hope to be working with 100% Cisco gear very soon.

1 Like
(Vincent L) #68

Hi Rene,

I have a question. The part you said “The vlan dot1q tag native is a global command so it applies to all interfaces. If you want to exclude certain interfaces, you can use the no switchport trunk native vlan tag command on the interface level.”. Currently I have all of my switches using Native VLAN 1. I want to change all Native VLAN 2. If I am to do the global command, will it bring down my network/switch? This is how our network works. Router -> Switch 1 -> Switch 2 -> Switch 3 -> Switch 4. I logged in Switch 1. If I am to do global command to change all to Native VLAN 2, will it bring down Switch 3 and Switch 4? What about router? I don’t maintain the router, my ISP does. Suggestion? Thank you, Vincent

(Lazaros Agapides) #69

Hello Vincent.

By default, and by definition, the native VLAN is the VLAN on which all untagged traffic that arrives on a trunk port will be placed on. On Cisco switches, we have the option of obligating all native VLAN traffic to be tagged. This is achieved using the global command that Rene mentions in the lesson. So this command will cause all native VLAN traffic to use tags.

If you want to change which VLAN will be the native VLAN, there is no global command to do this. This is done on each interface that is configured as a trunk. You will have to go into each trunk interface on each switch and make the change.

Now it is best practice to configure trunk ports to use a native VLAN that is not used by user traffic. If your native VLAN is in use for user or management traffic, and you have configured it on the trunks, then changing the native VLAN may have an affect on the network. It all depends on how your trunks are configured. It would be a good idea to make the changes during a maintenance window and to make sure that you have local access to all switches such that if you lose connectivity, you can connect locally via a console cable.

This change should not affect the connection to the ISP router since that should connect to an access port of Switch 1 which does not deal with the native VLAN.

I hope this has been helpful!

Laz

(Vincent L) #70

Hello Lazaros,

Thanks for the explanation. I have a question if this will work or not. If I have these switches linked together via trunking (Native Vlan1) and we don’t have any using vlan 2. I plan to change all to native vlan2. I have switch 1 trunked to switch 2, then switch 2 port 15 trunked to switch 3. Then switch 2 port 16 trunked to switch 4. Then switch 4 trunked to switch 5. Should I do it this way and it won’t interrupt the network for those switches -> configure switch 5 trunk to Native Vlan 2, then Switch 4 to Native Vlan 2, then Switch 3 to Native Vlan 2 then Switch 2 to Native vlan 2 then switch 1 to Native vlan2. Will this work and won’t affect the network? Thanks, Vincent

(Rene Molenaar) #71

Hi Vincent,

You should be fine but still I wouldn’t recommend changing this on Monday morning 9 AM.

Once you change the native VLAN on one side, you will see a CDP message:

SW1#
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2 (2), with SW2 GigabitEthernet0/2 (1).

I had two devices in VLAN 100, one connected to SW1 and the other one connected to SW2 and my ping keeps running, even with the native VLAN mismatch on the trunk. Still, you might have some other protocols in the native VLAN that don’t like this.

Rene

(karan s) #72

M apologies if my question is irreverent I would like to know what kind of system generate untag packet/frame in the real network environment and how that untag frame look like ( does it is same as Ethernet frame with tag ) and why it, not getting discard/drop by while encapsulating with the IP packet in transport layer when we have the checksum mechanism?

(Lazaros Agapides) #73

Hello Karan

Frames that are sent from almost all network devices such as computers, are sent without tags. Frames sent out of access ports on switches are also sent without tags. Tags are only added when a frame exits a trunk port and are removed once again when it enters the trunk port on the other end. Tagged frames should only exist on the link between two switches connected via a trunk.

Having said that, the Native VLAN is set up on a trunk so that any frames that do arrive on that trunk port without a tag will be placed on the appropriate VLAN. Situations where this is used is when switches communicate with each other using control frames such as those use in the CDP, VTP and STP protocols.

Another situation in which the native VLAN can be used is depicted in this topology:
image
Now the network shown above contains a very bad network design and should never be replicated, but it is used to prove a point. PC1 is connected to a hub which is in turn connected to Switches A and B. The link between Switches A and B (via the hub) is a trunk connection. Any frames sent by PC1 will be sent without tags, so untagged frames will reach the trunk ports of Switches A and B, due to the hub. Those frames will be placed on the configured native VLAN on each of those trunk ports.

An untagged frame is not a frame with an error, it is just one that doesn’t include the tag. This would not show up as an error so it wouldn’t be caught by the checksum mechanism.

I hope this has been helpful!

Laz

(Johan S) #74

Exactly Andrew, i work on private p2p network for video delivery and first step when configuring a switch is to make sure VLAN 1 not assigned to any port and create interface vlan 1 with no ip address and shut. All our switches pass cdp etc.

1 Like
(aniket g) #75

Hello Andrew,

I have seen a working scenario wherein DATA VLAN is 135 & VOICE VLAN is 137, also switch port is not TRUNK, Native VLAN is 1. So how could DATA Vlan traffic will go untagged as DATA Vlan being 135… Also under switchport we are giving commnad as "Switchport mode access " for DATA vlan, then how can we put this interface in Trunk mode?

(Lazaros Agapides) #76

Hello Aniket

There are two ways to implement the following scenario:
image
One is to configure the Gi0/1 interface as a trunk. Let’s say the voice VLAN on our network is 137 and the data VLAN is 135. We would configure the Gi0/1 interface as a trunk, with a native VLAN of 135 and an allowed VLAN of 137. This means that frames on VLAN 135 destined for H1 would exit the Gi0/1 interface untagged. Any such frames reaching the IP phone would continue on to H1. Any frames on VLAN 137 destined for the phone would exit the Gi0/1 with a tag of 137. The phone receives this frame, removes the tag and takes the frame for itself to be processed.

A sample config would be:

interface gigabitetherent 0/0
  switchport mode trunk
  switchport trunk allowed VLAN 137
  switchport turnk native vlan 135

Now this is the “old” way of implementing voice in this manner. It is actually still used on Cisco switches when configuring third party vendor phones. The “new” way of implementing this is using the voice VLAN.

In this case, the interface is configured as an access interface with an assigned VLAN oif 135, which is the native VLAN. An additional command would be added indicating which is the voice VLAN, specifically, VLAN 137. A sample config is the following:

 interface gigabitetherent 0/0
      switchport mode access
      switchport access vlan 135
      switchport voice vlan 137

The configuration is a little more elegant and more intuitive, but the result is the same. Now there is the following important difference between these two configs: the latter involves CDP communicating with the IP phone and letting it know which is the voice VLAN and which is the data VLAN so it can react correctly to the appropriate tagged/untagged frames.

To find out more about the voice VLAN and how it is configured, take a look at this lesson:

I hope this has been helpful!

Laz

1 Like
Voice VLAN
(Carlo Emmanuel V) #77

Hi.

I have a question, what happen If I configure “vlan dot1q tag native” in one switch and doen’t in the another peer?

Is this cause a problem with control traffic? what would happen with trunk in both sides?

This is why not all switches that I configure supports this command.

(Michal P) #78

Side of a trunk with “vlan dot1q tag native” set, is going to drop all frames, that are not tagged with dot1q.

Example:
Switch A: is not tagging frames on its native vlan
Switch B: is tagging all frames, including frames from his native vlan, because there is set “vlan dot1q tag native”

Scenario 1:
Switch A is sending frame from his native vlan to Switch B. Frame is not tagged, because it belongs to Switch A native vlan. Switch B drops that frame, because he expects only tagged frames.
Scenario 2:
Switch B is sending tagged frame from its native vlan, with native vlan number tag. Switch A normally accepts this frame and process it.

Nevertheless control traffic like CDP will pass from Switch A to Switch B just fine. It is not really tagged, but Switch B will process it. For control traffic it does not matter that one side of a trunk is tagging native vlan and other is not.