The terms Voice VLAN or Auxiliary VLAN typically mean the same thing: They are a feature which allows an access port — which normally only accepts untagged traffic for a single VLAN — to also accept tagged traffic for a second VLAN.
But that is merely the “what”, and if you were simply looking for a definition, then the above is all you need.
However, in order to really understand the concept, we have to look at the “why”, and also a bit of the history which brought about the Auxiliary VLAN. Doing so will reveal the use cases for the Voice VLAN or Auxiliary VLAN, as well as a particular use case for the Native VLAN.
Before we get into the details, it is important to have a solid understanding of VLANs. Namely the purpose of VLANs, Access Ports, Trunk Ports, the Native VLAN, the configuration of VLANs, and the concept of a Converged Network. If these concepts are not familiar to you, start by reading the articles and videos which explain them.
Also, the terms themselves are generally interchangeable. Voice VLAN is more often used in the Cisco context because of the command used to configure it, while Auxiliary VLAN is typically the name of the feature itself.
Voice VLAN Functionality
Imagine office cubicles. Imagine each cubicle contains a desk and a computer which an employee uses to connect to your corporate network.
When this office floor was being built, network cables were ran through the walls and ceilings from each position on the cubicle floor to the network closet where the access switch for the corporate network exists.
These cable runs are sometimes called “LAN drops” – a place an employee can connect locally (from their cubicle) into the corporate network switch (behind lock and key in the network cabinet).
You end up with a topology that looks something like this (image not drawn to scale):
Traditionally, there was one LAN drop for each cubicle.
This was sufficient when employees only had one PC or Laptop to connect to the network. They would simply plug in locally at the cubicle, and the wall jack would lead back to the corporate network switch.
The switchport would be configured as an access port in the VLAN associated with that employee’s role. The PC sends untagged data traffic, and the switch associates that traffic with the Data VLAN. On a Cisco switch, the configuration would resemble something like the following:
Switch(config)# vlan 22 Switch(config-vlan)# name DATA Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 22
Switch# show running-config ! vlan 22 name DATA ! interface Ethernet0/0 switchport access vlan 22 switchport mode access
Switch# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Et0/1, Et0/2, Et0/3, Et1/0
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3
22 DATA active Et0/0
It is worth highlighting that (typically) PCs always send untagged traffic – this point will be important shortly.
As time went on, phones which could carry Voice traffic over the IP network (VOIP phones) started being developed. Which leaves us with a problem — if a VOIP phone is added to each desk, where could you plug it in to get access to the corporate network? There is only one available wall jack and it is already in use by the PC.
Voice and Data using two ports
One solution is to run a second LAN drop to each cubicle. This is the simplest solution from the networking perspective:
One port is dedicated to carrying Data traffic, the other is dedicated to carrying Voice traffic. They are distinguished on the Switch using a simple access port in two different VLANs (the Data VLAN and the Voice VLAN):
Switch(config)# vlan 22 Switch(config-vlan)# name DATA Switch(config)# vlan 33 Switch(config-vlan)# name VOICE Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 22 Switch(config)# interface ethernet0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 33
Switch# show running-config ! vlan 22 name DATA vlan 33 name VOICE ! interface Ethernet0/0 switchport access vlan 22 switchport mode access interface Ethernet0/1 switchport access vlan 33 switchport mode access
Switch# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Et0/2, Et0/3, Et1/0, Et1/1
Et1/2, Et1/3, Et2/0, Et2/1
Et2/2, Et2/3, Et3/0, Et3/1
Et3/2, Et3/3
22 DATA active Et0/0
33 VOICE active Et0/1
Most modern office buildings now include multiple ports at each cubicle in order to account for multiple devices that need to be connected to the corporate network. Unfortunately, this wasn’t always an option for office’s which were not recently built.
Voice and Data using one port
A lot of older office build outs, which already only have one LAN drop at each cubicle, simply cannot afford the additional cost or delays to pay another technician to crawl through all the ceilings and walls to run another LAN drop to each cubicle. Which means the cubicles are limited to a single LAN drop per employee.
VOIP phone manufacturers were able to foresee this problem, and created another solution built right into the VOIP phones themselves.
The majority of VOIP phones come with two Ethernet ports: One meant to face the wall jack (and subsequently, the corporate LAN), the other meant to face a PC:
Using these two ports, the PC can be connected to the phone, and the phone can subsequently be connected to the single wall jack. This allows both devices to share a single wall jack.
The key is how to configure the switch, as now the single port will be receiving both Voice and Data traffic. We’ve already determined that Voice and Data traffic must be confined to distinct VLANs, but now both types of traffic are arriving on a single port.
There are two solutions: One solution is to configure the port as a Trunk port. The other is to make use of the Auxiliary VLAN (or Voice VLAN) feature. Both solutions are discussed and compared below.
Voice and Data using a Trunk port and the Native VLAN
Traditionally, if you want to carry traffic for multiple VLANs on a single port, you would configure a Trunk port.
This would allow traffic for multiple VLANs to traverse the single link. But typically traffic on trunk ports require tagging to distinguish which bits belong to one VLAN and which bits belong to another VLAN.
VOIP phones have the capacity to send and understand 802.1q VLAN tags, and can therefore be configured to send a VLAN tag for all the Voice traffic.
PC’s, as we’ve already discussed, only send untagged traffic. As such, the switch must have a way to associate the received untagged traffic on the trunk port to a particular VLAN. This is the exact purpose of the Native VLAN.
Therefore, in order to properly configure a single port to accommodate both a Voice and Data VLAN, you must first configure the interface as a Trunk port, then configure the Data VLAN as the Native VLAN:
Switch(config)# vlan 22 Switch(config-vlan)# name DATA Switch(config)# vlan 33 Switch(config-vlan)# name VOICE Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk native vlan 22
Switch# show running-config ! vlan 22 name DATA vlan 33 name VOICE ! interface Ethernet0/0 switchport trunk native vlan 22 switchport mode trunk
Switch# show interfaces trunk Port Mode Encapsulation Status Native vlan Et0/0 on 802.1q trunking 22 Port Vlans allowed on trunk Et0/0 1-4094 Port Vlans allowed and active in management domain Et0/0 1,22,33 Port Vlans in spanning tree forwarding state and not pruned Et0/0 1,22,33
Voice traffic will arrive from the VOIP phone with a tag for VLAN 33. And Data traffic will arrive from the PC untagged (forwarded untouched by the VOIP phone) and be associated to VLAN 22 because of the Native VLAN configuration.
While on the surface, this solution does work, we have to go a step further. There are, in fact, two problems with using a Trunk port to carry both Voice and Data traffic.
Problem #1: Configured as above, all VLANs on the switch will traverse the trunk link
If there are only two VLANs configured on the switch (as above), then this isn’t really a problem.
If however, you had more than just two VLANs configured, such as:
Switch(config)# vlan 22 Switch(config-vlan)# name DATA_Sales Switch(config)# vlan 33 Switch(config-vlan)# name VOICE_Sales Switch(config)# vlan 44 Switch(config-vlan)# name DATA_Marketing Switch(config)# vlan 55 Switch(config-vlan)# name VOICE_Marketing Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk native vlan 22
Switch# show running-config ! vlan 22 name DATA_Sales vlan 33 name VOICE_Sales vlan 44 name DATA_Marketing vlan 55 name VOICE_Marketing ! interface Ethernet0/0 switchport trunk native vlan 22 switchport mode trunk
Switch# show interfaces trunk Port Mode Encapsulation Status Native vlan Et0/0 on 802.1q trunking 22 Port Vlans allowed on trunk Et0/0 1-4094 Port Vlans allowed and active in management domain Et0/0 1,22,33,44,55 Port Vlans in spanning tree forwarding state and not pruned Et0/0 1,22,33,44,55
The solution would be to add yet another configuration item to the interface to limit which VLANs are able to traverse the trunk port:
Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk native vlan 22 Switch(config-if)# switchport trunk allowed vlan 22,33
Switch# show running-config ! vlan 22 name DATA_Sales vlan 33 name VOICE_Sales vlan 44 name DATA_Marketing vlan 55 name VOICE_Marketing ! interface Ethernet0/0 switchport trunk native vlan 22 switchport trunk allowed vlan 22,33 switchport mode trunk
Switch# show interfaces trunk Port Mode Encapsulation Status Native vlan Et0/0 on 802.1q trunking 22 Port Vlans allowed on trunk Et0/0 22,33 Port Vlans allowed and active in management domain Et0/0 22,33 Port Vlans in spanning tree forwarding state and not pruned Et0/0 22,33
This will limit the VLANs which can traverse this trunk to only the necessary VLANs.
Problem #2: The interface will not benefit from traffic optimizations that apply to Access ports
Spanning tree has an optimization known as Portfast which speeds up how quickly an access port is enabled.
Spanning tree also has an optimization known as BPDU guard which also (by default) only applies to access ports.
Port Security (by default) only applies to access ports.
There are other optimizations that exist for access ports that are tailored to ports facing network clients — like PC’s and VOIP phones.
If the interface facing your VOIP phone and PC is configured as a trunk port, it will not be able to take advantage of the optimizations which exist for access ports.
Of course, for each of these optimizations there are manual overrides that can be applied, but it increases the complexity of the network configuration. Besides, there is a much simpler solution to using a Trunk port for Voice and Data VLANs on a single port, and that solution is what this article has been building towards.
The more optimal solution is to use the Auxiliary VLAN feature (also known as the Voice VLAN).
Voice and Data using an Access port and the Auxiliary VLANs
And so, we’ve finally come to the primary purpose of this article – to describe the specific problems that are solved by the Auxiliary VLANs feature. Namely, the problem serves as an answer to the following question (note: illustration is identical to the one above):
In situations where only one physical port is available on your switch, how do you accept and receive Voice and Data traffic on one switchport while still keeping them in independent VLANs?
The solution:
First, use the VOIP phone’s built in switch – connect the PC to the phone, and the “LAN” port of the phone to the wall jack (which subsequently leads to the switchport).
Second, use the Auxillary VLAN configuration to accept the tagged voice traffic from the VOIP phone, and untagged traffic from the PC:
Switch(config)# vlan 22 Switch(config-vlan)# name DATA Switch(config)# vlan 33 Switch(config-vlan)# name VOICE Switch(config)# interface ethernet0/0 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 22 Switch(config-if)# switchport voice vlan 33
Switch# show running-config ! vlan 22 name DATA vlan 33 name VOICE ! interface Ethernet0/0 switchport access vlan 22 switchport mode access switchport voice vlan 33
Switch# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Et0/1, Et0/2, Et0/3, Et1/0
Et1/1, Et1/2, Et1/3, Et2/0
Et2/1, Et2/2, Et2/3, Et3/0
Et3/1, Et3/2, Et3/3
22 DATA active Et0/0
33 VOICE active Et0/0
With this configuration, traffic arriving on the single available switchport will still be accepted in two different VLANs on your network. Allowing you to separate Voice and Data traffic, despite it arriving on the same physical switchport.
There is a second way of doing.you can create one vlan for data and voice traffice coming from voip will be carried by default voice vlan 0.
VLAN 0 is reserved / unusable for the specific purpose of adding an “empty” VLAN tag … i.e., an 802.1q header that does not instruct the receiving switch to associate the contained bits to a particular VLAN. The receiving switch would use their own, Native VLAN configuration to associate the bits to a particular VLAN — just as if the frame did not have an 802.1q header.
For the phone to use 802.1p you will need to specify that on the access port voice vlan (switchport voice vlan dot1p). Otherwise all vlan 0 traffic sent to the phone is dropped by default.
When using Cisco VoIP phone with a device attached, CDP is used to communicate the voice vlan to the phone and subsequently tag VoIP traffic leaving the phone with that vlan. On the access port if you do not specify a voice vlan and only specify an access vlan, then the phone and the device must be in the same vlan, subnet, and use the same frame type. This really isn’t recommended for a number of reasons.
Hi, Ed.
Most exceptional write-up. I researched “auxiliary vlan” on Google and you were the first result =)
Thank you for doing such a great job explaining and putting great efforts into diagrams and configuration.
Hu
Thanks for sharing
Wonderful explanation, especially on why it’s not good practice to use a trunk port facing the ip phone
Thank you, Peter. Glad you enjoyed it =)
Got to leave a comment, too. Best explanation I found yet.
Thank you, George. Glad you enjoyed the article =)
Practical Networking – every topic explained was flawless.. Keep coming more.
Thank you, Bhanu. Will do =)
Have been struggling with this especially with the question: Why a single port is used and how a single port can handle traffic for two different VLANs? Your article really cleared that for me and also the background knowledge really helped clear some confusions.
Great article, Thanks 🙂
Glad you enjoyed it, Shaheer =). You’re welcome.
Nice job!
great clarification
Great article. Thank you for sharing this. God bless