Fact: The human ear will only accept 140 – 150 milliseconds of delay before it notices a problem with voice delivery. That’s how long we have to get the voice traffic from source to destination before the voice quality is compromised.
When it comes to the link between the switch and the IP Phone, we’ve got four choices:
- Configure the link as an access link
- Configure the link as a trunk link and use 802.1p
- Configure the link as a trunk link and do not tag voice traffic
- Configure the link as a trunk link and specify a Voice VLAN
- When Voice VLAN is configured on a port, Portfast is automatically enabled — but if you remove the Voice VLAN, Portfast is NOT automatically disabled.
- Cisco recommends that QoS be enabled on the switch and the switch port connected to the IP phone be set to trust incoming CoS values. The commands to perform these tasks are mls qos and the interface-level command mls qos trust cos, respectively.
- You can configure voice VLANs on ports running port security or 802.1x authentication. It is recommended that port security be set to allow more than one secure MAC address.
- CDP must be running on the port leading to the IP phone. CDP should be globally enabled on all switch ports, but take a few seconds to make sure with show cdp neighbor.
- Voice VLAN is supported only on L2 access ports.
Particularly when implementing video conferencing, make sure your total overall traffic doesn’t exceed 75% of the overall available bandwidth. That includes video, voice, and data! Cisco also recommends that voice and video combined not exceed 33% of a link’s bandwidth. This allows for network control traffic to flow through the network and helps to prevent jitter as well.
Voice And Switch QoS
three main enemies when it comes to successful voice transmission:
- packet loss
Best-effort delivery is the QoS you have when you have no explicit QoS configuration – the packets are simply forwarded in the order in which they came into the router. Best-effort works fine for UDP, but not for voice traffic.
- The Integrated Services Model, or IntServ, is far superior to best-effort. IntServ uses the Resource Reservation Protocol (RSVP) to do its job, and that reservation involves creating a high-priority path in advance of the voice traffic’s arrival. The device that wants to transmit the traffic does not do so until a reserved path exists from source to destination. The creation of this path is sometimes referred to as Guaranteed Rate Service (GRS), or simply Guaranteed Service.
- The obvious issue with IntServ is that it’s not a scalable solution – as your network handles more and more voice traffic, you’re going to have more and more reserved bandwidth, which can in turn “choke out” other traffic.
- That issue is addressed with the Differentiated Services Model, or DiffServ. Where IntServ reserves an entire path in advance for the entire voice packet flow to use, DiffServ does not reserve bandwidth for the flow; instead, DiffServ makes its QoS decisions on a per-router basis as the flow traverses the network. (If DiffServ sounds like the best choice, that’s because it is.)
The DiffServ Model At Layer Two
As mentioned earlier, DiffServ takes a different view of end-to-end transmission than that taken by IntServ. The DiffServ model allows each network device along the way to make a separate decision on how best to forward the packet toward its intended destination, rather than having all forwarding decisions made in advance. This process is Per-Hop Behavior (PHB).
The core tasks of Diffserv QoS are marking and classification. Marking is the process of tagging data with a value, and classification is taking the appropriate approach to queueing and transmitting that data according to that value.
It’s best practice to mark traffic as close to the source as possible to ensure the traffic receives the proper QoS as it travels across the network. This generally means you’ll be marking traffic at the Access layer of the Cisco switching model, since that’s where our end users can be found.
At Layer 2, tagging occurs only when frames are forwarded from one switch to another. We can’t tag frames that are being forwarded by a single switch from one port to another.
The VLAN ID is tagged on the frame before it goes across the trunk along with another value – a Code of Service (CoS) value – can also be placed on that frame. Where the VLAN ID indicates the VLAN whose hosts should receive the frame, the CoS is used by the switch to make decisions on what QoS, if any, the frame should receive.
ISL and Dot1Q QoS Differences
- The ISL tag includes a 4-bit User field; the last three bits of that field indicate the CoS value. Three binary bits give us a range of decimal values of 0 – 7.
- The dot1q tag has a User field as well, but this field is built a little differently. Dot1q’s User field has three 802.1p priority bits that make up the CoS value, and again that gives us a decimal range of 0 – 7.
- With dot1q, the native vlan is untagged, however the receiving switch can be configured with a CoS to apply to any incoming untagged frames. Naturally, that switch knows that untagged frames are destined for the native VLAN.
The DiffServ Model At Layer Three
One of the IP header fields is Type Of Service (ToS), and that ToS value is the basis for DiffServ’s approach to marking traffic at Layer Three.
The IP ToS byte consists of…
- an IP Precedence value, generally referred to as IP Prec (3 bits)
- a Type Of Service value (4 bits)
- a zero (1 bit)
DiffServ uses this 8-bit field as well, but refers to this as the Differentiated Services (DS) field. The DS byte consists of:
- a Differentiated Service Code Point value (DSCP,6 bits,RFC 2474)
- an Explicit Congestion Notification value (ECN, 2 bits, RFC 2481)
The 6-bit DSCP value is itself divided into two parts:
- a Class Selector value, 3 bits
- a Drop Precedence value, 3 bits
These two 3-bit values also have a possible range of 0 – 7 overall (000 – 111 in binary).
Here’s a quick description of the Class Selector values and their meanings:
- Class 7 (111) – Network Control, and the name is the recipe – this value is reserved for network control traffic (STP, routing protocol traffic, etc.)
- Class 6 (110) – Internetwork Control, same purpose as Network Control.
- Class 5 (101) – Expedited Forwarding (EF, RFC 2598) – Reserved for voice traffic and other time-critical data. Traffic in this class is practically guaranteed not to be dropped.
- Classes 1 – 4 (001 – 100) – Assured Forwarding (AF, RFC 2597) –
These classes allow us to define QoS for traffic that is not as time critical as that in Class 5, but that should not be left to best-effort forwarding, which is: Class 0 (000) – Best-effort forwarding. (This is the default)
We’ve got four different classes in Assured Forwarding, and RFC 2597 defines three Drop Precedence values for each of those classes:
- High – 3
- Medium – 2
- Low – 1
The given combination of any class and DP value is expressed as follows:
AF (Class Number)(Drop Precedence)
That is, AF Class 2 with a DP of “high” would be expressed as “AF23”.
The switch has to make a decision on whether to trust an incoming QoS value.
2 possibilites following this:
- If the incoming value is trusted, that value is used for QoS.
- If the incoming value is not trusted, the receiving switch can assign a preconfigured value.
Frames from your own LAN should be trusted and frames not part of your network should not be trusted. Hence creating a ‘trust boundary’.
Now to the required commands! Before we perform any QoS on this switch, we have to enable it – QoS is disabled globally by default.
QoS: ensure flow-control on all interfaces are OFF for proper operation. We can trust values on two different levels. First, we can trust the value unconditionally, whether that be CoS, IP Prec, or DSCP. Here, we’ll unconditionally trust the incoming CoS value.
SW2(config-if)#mls qos trust ? cos Classify by packet COS device trusted device class dscp Classify by packet DSCP ip-precedence Classify by packet IP precedence <cr> SW2(config-if)#mls qos trust cos
We can also make this trust conditional, and trust the value only if the device on the other end of this line is a Cisco IP phone. IOS Help shows us that the only option for this command is a Cisco IP phone.
SW2(config-if)#mls qos trust device ? cisco-phone Cisco IP Phone SW2(config-if)#mls qos trust device cisco-phone
If you configure that command and show mls qos interface indicates the port is not trusted, most likely there is no IP Phone connected to that port.
SW2#show mls qos interface fast 0/5 FastEthernet0/5 trust state: not trusted trust mode: trust cos COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: cisco-phone
Extending the Trust Boundary to the PC
The best practice is to not trust the QoS values sent by the PC. Some applications have been known to set QoS values giving that application’s data a higher priority than other data. The default behavior is to not trust the CoS value from the PC, and to set that value to zero.
To overwrite the CoS value sent by the PC and set it to a value we choose, use the switchport priority extend cos command.
SW2(config-if)#switchport priority extend cos ? <0-7> Priority for devices on appliance SW2(config-if)#switchport priority extend cos 2
If we had chosen to trust those same frames and allow their CoS to remain unchanged after transmission from the PC, we would use the switchport priority extend trust command:
SW2(config-if)#switchport priority extend ? cos Override 802.1p priority of devices on appliance trust Trust 802.1p priorities of devices on appliance SW2(config-if)#switchport priority extend trust *Big thanks to Chris Bryant again for all of the above. Brilliant overview of foundational QoS.