One of the more tedious parts of any phone system deployment is configuring the access layer switches to support said phones. The configuration in and of itself isn’t complicated, but every port that may receive a phone needs to be setup correctly. In Cisco parlance, this is accomplished with the switchport voice vlan <ID> command. I’ve typed that into the CLI a thousand times and never really knew what it did besides “make the phones work”. After a little research, I finally found some answers. I thought I’d share them with you.
In the old days, before the Catalyst 2950, configuring a switch port for use by a phone involved creating an explicit 802.1q trunk. This made sense from the perspective that it allowed traffic from multiple VLANs to pass on a single link. It also allowed the 802.1p priority bits for Quality of Service (QoS) tagging to be sent with the frames. The downside is that it was very difficult for phone mobility. You either needed to provision every phone-facing switchport in your organization to be an 802.1q trunk or you had to leave the phones were they were. While the latter is usually the case in most of my deployments, the mobility provided by the ability to plug a phone in anywhere in the network and not worry about extra configuration is key to some clients. Thankfully, Cisco fixed this starting in the 2950 with a little concept known as the Auxiliary VLAN.
The Auxiliary VLAN (AUX VLAN) is a specialized VLAN that sits beside a regular access VLAN configured on a switch (sometimes called a “normal” VLAN). The purpose of the AUX VLAN is to allow IP phones to transmit their payloads along with the untagged data coming from a PC that might be plugged into a switchport on the back of the phone. The AUX VLAN allows these two devices to transmit on the same port without the need to use an explicit trunk on the link. In addition, since the port is not configured explicitly as an 802.1q trunk, extraneous VLANs will not be flooded over the port. In essence, the port becomes a two VLAN trunk. All the phone traffic is tagged with the ID of the AUX VLAN and the PC traffic is untagged. Curiously, according to this document, the traffic in the AUX VLAN must also carry a Class of Service (CoS) of 5 along with the AUX VLAN ID. Otherwise, the traffic is dropped. So how does the phone get the ID of the AUX VLAN so it can start sending the traffic? Ah, that’s where CDP comes in.
Cisco Discovery Protocol (CDP) is very crucial in the operation of a Cisco IP phone. It not only provides the AUX (Voice) VLAN ID for the phone to being sending traffic on the AUX VLAN, it also allows the phone to automatically negotiate power settings. This allows the phone to use less than the maximum 15.4 watts of power under the 802.3af PoE standard. If you disable CDP on the port facing the phone/PC you will likely start pulling your hair out. Even though the phone might have already assigned itself in the Voice VLAN, removing CDP from the switchport in question causes it to forget where to find the voice VLAN. You’ll need to re-enable CDP and reboot the phone. You could also statically configure an 802.1q trunk to fix the issue, but where’s the fun in that?
One other curious note is that I’ve always been told that the connection between the phone and the switch when switchport voice vlan is configured is a “special 802.1q trunk”. Not that I’ve ever been able to see that configuration, as show interface trunk seems to think that the port isn’t trunking and show interface switchport says that it’s an access port. The key is in Cisco’s documentation. The correct term for a port with switchport voice vlan configured is a “multi-VLAN access port”. The distinction between the two is that only the two vlans (voice and access) configured on the switchport will be accepted on the link. If you were to do something silly like, oh I don’t know, plug another switch into the back of the phone and configure an access port on that switch to be in a different VLAN than the voice or PC access VLAN, traffic will not pass through the phone port to the switch. Once again, that’s because this isn’t a real trunk. The switch will only accept tagged frames from the Voice (AUX) VLAN.
I hope this was a little more insight into what the magical command switchport voice vlan does on a switch. I’m often asked by people new to voice why this must be configured each time. Before I blindly regurgitated lines like “special 802.1q trunk” and “do it or it won’t work.” Now I have a very interesting story to tell and threaten people with if they don’t do it.