Quality of Service for Campus Architectures
Quality of Service (QoS) is an integral part of any campus environment. QoS allows for the prioritization of specific traffic flows as they traverse over the campus network. For example, it may be desirable to allow voice and video traffic to have priority over bulk FTP traffic during a time of network congestion. One of the most common reasons that QoS is not deployed is due to its complexity. This section will discuss some different ways to automate the deployment of QoS for LAN devices.
AutoQoS on Campus LAN Devices
As campus networks continue to grow, more emphasis is being put on the LAN. Today, it is becoming even more important to capitalize on the available LAN bandwidth as much as possible. Often, campus networks are designed with a specific set of goals in mind. For example, the following list are some of the more common business drivers and use cases that put demand on the campus LAN infrastructure:
Gigabit Ethernet to the desktop
Campus video communications
Voice and IP phones
Alternatively, there are some other use cases that are beginning to be more prevalent in enterprise networks. These different, but not uncommon use cases are increasing the demand for connectivity in the LAN:
All of the above use cases are putting increased demand on the network and, by default, demand on the network engineering team.
Enabling AutoQoS on a Cisco Catalyst Switch
To enable AutoQoS, the following configuration steps must be followed:
Step 1. Enable AutoQoS globally
Step 2. Enable AutoQoS settings under interface
AutoQoS is enabled globally in the following example on the Catalyst switch by issuing the auto qos global compact command from the global configuration prompt. Once the feature is enabled globally, it can be verified with the show auto qos command.
Switch# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# auto qos global compact Switch(config)# end Switch# show auto qos AutoQoS not enabled on any interface Switch#
As you can see from the output of the show auto qos command in the following code snippet, there are no interfaces currently configured with any AutoQoS parameters. Once AutoQoS is enabled globally, you must then specify the interface configuration settings. For example, see the following output that illustrates how to enable the AutoQoS settings under a Gigabit Ethernet interface of a Catalyst switch. The configuration shown is for a Cisco IP phone.
Switch# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)# interface GigabitEthernet0/1 Switch(config-if)# auto qos voip cisco-phone Switch(config-if)# end Switch#
Now that AutoQoS is enabled globally and there is an interface with AutoQoS settings applied to it, the show auto qos command is re-issued to verify the configuration as shown in the following snippet. Based on the output of the show auto qos command, we see that there is a difference in the information displayed as opposed to output shown previously. When AutoQoS is enabled under the GigabitEthernet0/1 interface, it now includes the interface configuration in the show command.
Switch# show auto qos GigabitEthernet0/1 auto qos voip cisco-phone Switch#
In order to display the actual QoS settings that get applied to the GigabitEthernet0/1 interface when a Cisco IP phone is connected, the show auto qos interface GigabitEthernet0/1 configuration command must be issued. The following snippet shows that based on the output of this command, there is an ingress policy named AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY that is applied to the GigabitEthernet0/1 interface. The output also shows that the outbound egress priority queue is enabled and that the interface has been set to automatically trust the DSCP markings from the Cisco IP phone.
Switch# show auto qos interface GigabitEthernet0/1 configuration GigabitEthernet0/1 auto qos voip cisco-phone Ingress Policy: AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY Egress Priority Queue: enabled The port is mapped to qset : 1 Trust device: cisco-phone
Next, to further validate the settings within the AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY that is applied to the GigabitEthernet0/1 interface, we issue the show policy-map AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY command as shown in the following output.
Switch# show policy-map AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY Policy Map AUTOQOS-PPM-SRND4-CISCOPHONE-POLICY Class AUTOQOS_PPM_VOIP_DATA_CLASS set dscp ef police 128000 8000 exceed-action policed-dscp-transmit Class AUTOQOS_PPM_VOIP_SIGNAL_CLASS set dscp cs3 police 32000 8000 exceed-action policed-dscp-transmit Class AUTOQOS_PPM_DEFAULT_CLASS set dscp default police 10000000 8000 exceed-action policed-dscp-transmit Switch#
Based on the previous output, we can see that the following parameters have been set in the QoS policy-map applied to the GigabitEthernet0/1 interface on the Catalyst switch:
Voice data packets are being marked with the DSCP value of EF (46)
Policing of the VOIP_DATA_CLASS is set to 128Kbps
Call signaling packets are being marked with the DSCP value of CS3
Policing of the VOIP_SIGNAL_CLASS is set to 32Kbps
All other packets are being marked with DSCP value of DEFAULT (0)
Policing of the DEFAULT_CLASS is set to 10Mbps
The following snippet illustrates the output of the show auto qos voip cisco-phone configuration command, which is an alternate way of displaying the AutoQoS configuration that will be applied to an interface when a Cisco IP phone is connected. This command will also display the DSCP/CoS markings, queuing strategy, and associated thresholds settings that will be applied.
Switch# show auto qos cisco-phone configuration Traffic(DSCP / COS) IngressQ-Threshold EgressQ-Threshold --------------------------------------------------------------------- VoIP(46/5) N/A - N/A 01 - 01 Signaling(24/3) N/A - N/A 03 - 01 Best-Effort(00/0) N/A - N/A 02 - 01
All of the QoS settings mentioned above were deployed by issuing only two commands: the auto qos global compact global command and the auto qos voip cisco-phone interface command. We can begin to see how powerful tools like AutoQoS can be in a campus environment, eEspecially with hundreds to thousands of connected host devices. The following section of this chapter will cover deploying AutoQoS in the campus WAN environment.
AutoQoS on Campus WAN Devices
The best practice in general from a QoS perspective is to mark the traffic closest to the source and carry those markings across your LAN and WAN end-to-end. The biggest reason for this is so that end users and applications have a consistent experience. Marking and prioritizing traffic on the LAN is just one step in a bigger QoS design. Using AutoQoS for the WAN, you can simplify the steps needed to achieve that end-to-end user and application experience. Figure 7-2 illustrates the high level end-to-end QoS design model from an IP phone in one location to an IP phone in another location.
Figure 7-2 End-to-end QoS example
As you can see based on Figure 7-2, the QoS markings are kept intact from source to destination across the campus LAN and WAN networks. In this specific case, voice data traffic from Phone-1 to Phone-2 is marked with DSCP EF (46), and those markings are honored on a hop-by-hop basis across the entire network. This is called per-hop behavior (PHB).
Enabling AutoQoS on a Cisco ISR Router
The following example lists the steps that are necessary to enable AutoQoS for the WAN on a Cisco ISR router.
Router# configure terminal Router(config)# interface FastEthernet0/1 Router(config-if)# auto qos voip Router(config-if)# end Router#
One of the convenient things about AutoQoS for the WAN is that by enabling it on one of the interfaces of the router, it automatically enables the feature globally. Furthermore, it applies all the QoS policy-maps and other settings automatically. The following snippet illustrates an example output of the show auto qos command from a Cisco ISR router, illustrating what features AutoQoS will automatically activate when the feature is enabled.
Router# show auto qos ! policy-map AutoQoS-Policy-UnTrust class AutoQoS-VoIP-RTP-UnTrust priority percent 70 set dscp ef class AutoQoS-VoIP-Control-UnTrust bandwidth percent 5 set dscp af31 class AutoQoS-VoIP-Remark set dscp default class class-default fair-queue ! class-map match-any AutoQoS-VoIP-Remark match ip dscp ef match ip dscp cs3 match ip dscp af31 ! class-map match-any AutoQoS-VoIP-Control-UnTrust match access-group name AutoQoS-VoIP-Control ! class-map match-any AutoQoS-VoIP-RTP-UnTrust match protocol rtp audio match access-group name AutoQoS-VoIP-RTCP ! ip access-list extended AutoQoS-VoIP-RTCP permit udp any any range 16384 32767 (6 matches) ! ip access-list extended AutoQoS-VoIP-Control permit tcp any any eq 1720 permit tcp any any range 11000 11999 permit udp any any eq 2427 permit tcp any any eq 2428 permit tcp any any range 2000 2002 permit udp any any eq 1719 permit udp any any eq 5060 ! rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Drops" owner AutoQoS rmon alarm 33333 cbQosCMDropBitRate.34.14175073 30 absolute rising-threshold 1 33333 falling-threshold 0 owner AutoQoS FastEthernet0/1 - ! interface FastEthernet0/1 service-policy output AutoQoS-Policy-UnTrust
AutoQoS, in conjunction with some of the other automation mechanisms discussed earlier in the Automatic Port Profiling section of this chapter, can start to build a very robust and powerful tool set. This tool set can help network engineers ease the operational complexity of managing a constantly changing campus network environment. Chapter 8 “Network Automation Tools for Campus Environments” will highlight another tool set known as the application policy infrastructure controller enterprise module (APIC-EM). APIC-EM offers a wide variety of features that include tools to assist in configuring and automating quality of service in campus environments. We will also discuss some future APIC-EM applications.