Last Updated on October 4, 2023 by Tomas

Introduction

Network convergence has reached such a high level of deployment that virtually all new network installations or upgrades of enterprise networks involve an IP-based network that serves voice and data. As a result, even the smallest businesses in my little corner of the world often look at solutions involving converged networks.

It means that as network engineers, not only must we be more efficient while avoiding the headache and heartache of poor network performance (ugh!), we also need to ensure that the network is provisioned to perform seamlessly for all types of traffic.

It is particularly true when deploying an Access layer switch to serve voice and data endpoints. In this article, we’ll be exploring the vital elements involved in preparing a Cisco switch for use with VoIP.

Now just a quick clarification here. Although we are primarily focusing on voice, we’ll quickly see that the principles and configurations described are valid for transmitting all types of real-time and time-sensitive services, such as voice communication, videoconferencing, and collaboration. In addition, many telephony endpoints can deliver integrated video telephony, so whatever works for simple voice is also valid for video.

Note: Although many Cisco switches support VoIP applications and QoS, all commands in this article were applied to a Cisco 3750 multilayer switch running a 15.X series IOS version.

What are we configuring?

Access switches are those switches that interconnect the end devices to the network, whether they are IP phones, PCs, cameras, videoconference endpoints, printers, TVs, or any other network device. Access switches are called upon to cater to many different traffic types, each with its specific requirements.

In this article, we’ll be looking at the configuration of a Cisco access switch that will satisfactorily be configured to do the following:

1. Deliver both voice and data to a workspace/desk via a single switch port
2. Ensure that voice packets are given the appropriate QoS priorities

In doing so, we’ll see some of the inner workings of a Cisco switch specifically for VoIP deployments. Of course, in most cases, Cisco IP phones would be deployed. Even so, these configurations are, for the most part, generic, regardless of what physical IP phones are being used.

Using a single switchport

One way to evaluate the cost of an enterprise network is to count the number of Access layer switchports you will need. This typically indicates the ultimate size of the network. The vast majority of workspaces or desks usually have a phone and a computer. Since an IP phone is just another network device that uses Ethernet, that comes to two switchports per workspace.

It is of great benefit to be able to deliver connectivity to both the phone and the PC via a single switchport, thus essentially halving the size of the network and in turn, the cost. This is why most modern IP phones today have a built-in switch that allows you to connect a PC to the phone and the phone to the switchport. But how does that work?

Taking advantage of the native VLAN

In older implementations, this was achieved by creating a trunk port on the switch and configuring a particular native VLAN. A typical configuration would be something like this.

First, we create two new VLANs, one for data and the other for voice:

Switch(config)#vlan 100
Switch(config-vlan)#name DATA
Switch(config-vlan)#exit
SW1(config)#vlan 101
SW1(config-vlan)#name VOICE
SW1(config-vlan)#exit
SW1(config)

Next, we configure the Gi0/1 port, to which we’ll connect our phone, as a trunk port that includes the voice VLAN and uses the data VLAN as the native VLAN.

Switch(config)#interface GigabitEthernet 0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 101
Switch(config-if)#switchport trunk native vlan 100
Switch(config-if)#exit
Switch(config)

So, what does this do? It tags frames on VLAN 101 and sends untagged frames for VLAN 100. This configuration alone is enough to make a Cisco IP phone work once it is plugged in. It will also allow any PC connected to the phone’s data port to connect to the network. The result is that:

• Any traffic from the PC will traverse the phone and reach the switch port as untagged. The switch will take that traffic and place it on VLAN 100, the native VLAN, and send it out accordingly.
• Any traffic from the phone will be tagged and will reach the switch port tagged. The tag tells the switch on which VLAN to place it, the configured allowed VLAN 101, and the switch will forward it accordingly.

Now, this configuration is obsolete, so why are we showing it here? Well, it helps us understand what is happening under the hood. The more modern implementation still uses these exact mechanisms, but it is streamlined to include many more benefits for VoIP phones.

Using the voice VLAN feature

In today’s Cisco switches, the proper way to configure a switch port for use with an IP phone and a PC is to use the following interface configuration:

Switch(config)#interface GigabitEthernet 0/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 100
Switch(config-if)#switchport voice vlan 101
Switch(config-if)#exit
Switch(config)

So, what is this, an access port or a trunk port? Well, it’s a voice port. It’s a special case access port that tags frames on the voice VLAN. The result is essentially the same as the previous trunk configuration. Voice packets on VLAN 101 are tagged, while data packets on VLAN 100 are untagged. What advantages does this provide, however?

• Cisco IP phones can communicate with the switch automatically using CDP. The switch informs the phone of the voice VLAN configuration using CDP, so that the phone will tag its voice frames with the appropriate VLAN ID. No configuration is necessary on the phone itself.
• Even some non-Cisco IP phones use CDP for such configuration parameters. A Cisco switch can also be configured to supply such configuration parameters using LLDP—an open architecture alternative to CDP supported by other IP phone vendors.
• The switch will automatically set up some of the most common and typically used QoS parameters for the IP phone. Remember that the VLAN tag also contains QoS information that ensures the voice frames are given priority, even if the data from the PC saturates the link.

Applying QoS

As mentioned before, a Cisco switch interface configured with a voice VLAN will automatically set up some of the most common QoS parameters to ensure that voice to and from the connected IP phone will enjoy the necessary priorities. Now QoS on a network operates at two different levels of the OSI model: the Data Link layer and the Network layer.

At the Data Link layer, we use the Class of Service or CoS values found within the 802.1Q tag. At the Network layer, we use the Differentiated Services Code Point or DSCP value found within the IP header.

Note: Some network engineers believe that simply having a network with plenty of bandwidth is enough to ensure good voice quality on a converged network. However, this is not the case. No matter how much bandwidth you have available, there is always the possibility of network congestion. QoS mechanisms should be implemented at all locations on a converged network.

QoS at the Data Link layer

QoS parameters at the Data Link layer operate within the 802.1Q tag or the VLAN ID tag. This is why the voice VLAN is tagged while the data VLAN remains untagged, so that the voice frames can have QoS mechanisms applied to them on the link itself. These QoS mechanisms operate not only on the physical link between the phone and the switch but also upstream on the network, wherever there are trunk links.

Remember the 802.1Q tag exists only on frames that traverse trunks. Applying QoS ensures that trunks, which can often become bottlenecks in network traffic, prioritize voice packets to guarantee quality.

Trust boundary for Layers 2 and 3

Phones will mark the frames they send with the appropriate preconfigured priorities within the 802.1Q tag. Nevertheless, the question is, when the switch receives these values, what does it do with them?

We can choose to trust them, which essentially means that we believe that they have been implemented correctly and respond to them by applying relevant QoS parameters. Or, we can choose to modify them if we like. Typically, the areas of the network that trust these markings are all within (what is known as) a “trust boundary.”

The trust boundary is deployed by indicating the ports you will be receiving frames for which you trust the markings. To employ this, do the following on the switch:

Switch(config)#mls qos

This enables QoS on the switch.

Note that switches will, by default, remove the DSCP markings of all received packets. Remember that DSCP markings are Layer 3 QoS markings found in the IP header. If you don’t want this, you must use the following command to disable it:

Switch(config)#no mls qos rewrite ip dscp

Trust CoS

Next, let’s take a look at the current QoS status of Fe0/1. This will show if it trusts the markings of the packet or frame.

Switch#show mls qos interface fastEthernet 0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none

You can see that nothing is trusted at the moment. This means that any QoS markings on the 802.1Q tag are ignored and actually overwritten before they are sent upstream in the network. On the interface where the IP phone is plugged in, you can change this behavior by applying the following commands:

Switch(config)#interface fastethernet 0/1
Switch(config-if)#mls qos trust cos

This particular command will trust the Class of Service, or CoS, which refers to the QoS markings within the 802.1Q tag. The switch at this point will use its default CoS to DSCP mapping to modify the DSCP value of the IP packet and will actually overwrite the CoS values. If you want the CoS values to remain and to be sent upstream on subsequent trunks, then you must include this command:

Switch(config-if)#mls qos trust cos pass-through

Trust DSCP

Finally, you can also verify that the switch will receive and trust the DSCP values sent by phone by issuing the following command:

Switch(config-if)#mls qos trust dscp

From the following verification information, you can see that now the DSCP values are trusted on this port:

Switch#show mls qos interface fastEthernet 0/1
FastEthernet0/1
trust state: trust dscp
trust mode: trust dscp
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none

By issuing these commands on the various ports interconnecting the switches in your network, you can create a trust boundary, that is, an imaginary area within your network where all received CoS and/or DSCP values are trusted, remain unchanged, and are acted upon by QoS mechanisms to ensure QoS throughout your network.

This is quite useful especially when your network interconnects with third-party networks of partner enterprises or WANs. You can’t always trust the markings sent to your network from such networks, so it’s a good idea to re-mark such packets according to the QoS policy of your enterprise.

One final thing before we go. If you’re using Cisco phones, you can specify that you trust any Cisco IP phone on that port by using the following command:

Switch(config-if)#mls qos trust device cisco-phone

Conclusion

Converged networks are a wonderous thing. However, it’s important to provision them correctly, ensuring the proper prioritization and management of time-sensitive traffic being sent over the network. This is necessary in order to keep your users happy and also to make sure that your days are filled with less stress and with more peace of mind!