Implementing and Verifying AutoQoS

Before you implement AutoQoS and enable it on router interfaces, it is useful to know the router AutoQoS deployment restrictions. Some design considerations are also worth learning with regard to deploying AutoQoS on routers. Finally, you must know the prerequisites for configuring AutoQoS on Cisco routers.

You can enable Cisco AutoQoS Enterprise on certain types of interfaces and permanent virtual circuits (PVCs) only. These are the interface and PVC types on which you can enable AutoQoS enterprise for a Cisco router:

■ Serial interfaces with PPP or high-level data link control (HDLC) encapsulation.

■ Frame Relay point-to-point subinterfaces. (Multipoint is not supported.)

■ ATM point-to-point subinterfaces (PVCs) on both slow (<=768 kbps) and fast serial (>768 kbps) interfaces.

■ Frame Relay-to-ATM interworking links.

On low-speed serial links, you must enable AutoQoS Enterprise on both ends, and the configured bandwidths must be consistent. For PPP encapsulations, Multilink PPP (MLP) is enabled automatically, and the IP address of the serial interface is removed and put on the virtual template (MLP bundle). Frame Relay data-link connection identifier (DLCI) and ATM PVCs have some similar restrictions with respect to enabling AutoQoS. Table 7-2 shows those restrictions side by side.

Table 7-2 AutoQoS Restrictions on Frame Relay DLCIs and ATM PVCs


Frame Relay DLCI Restrictions

ATM PVC Restrictions

You cannot configure AutoQoS on a Frame Relay DLCI if a map class is attached to the DLCI.

You cannot configure AutoQoS on a low-speed Frame Relay DLCI if a virtual template is already configured for the DLCI.

You cannot configure AutoQoS on a low-speed PVC if a virtual template is already configured for the ATM PVC.

For low-speed Frame Relay DLCI configured with Frame Relay-to-ATM interworking, MLP over Frame Relay is configured automatically; the subinterface must have an IP address.

For low-speed ATM PVCs, MLP over ATM is configured automatically; the subinterface must have an IP address.

When MLP over Frame Relay is configured, the IP address is removed and placed on the MLP bundle.

When MLP over ATM is configured, the IP address is removed and put on the MLP bundle.

Based on the interface type, interface bandwidth, and encapsulation, AutoQoS might enable different features on the router interfaces. The bandwidth that is configured on a router interface at the time AutoQoS is enabled on that interface plays a significant role toward the configuration that AutoQoS generates for that interface. AutoQoS will not respond and alter the generated configuration if the interface bandwidth is changed afterward. Following are examples of the features that AutoQoS can enable on router interfaces:

■ LLQ—Low-latency queuing reserves a priority queue for VoIP (RTP) traffic, providing a guaranteed but policed bandwidth. Other queues (class-based weighted fair queueing, or CBWFQ) serve traffic such as mission-critical, transactional, and signaling traffic and give them bandwidth guarantees.

■ cRTP—Compressed RTP reduces the IP/UDP/RTP header from 40 bytes to 2/4 bytes (without/with CRC). This feature is enabled on low-speed serial interfaces. The reduced header overhead significantly improves link efficiency.

■ LFI—The link fragmentation and interleaving feature fragments large data packets on slow interfaces. Therefore, on shared outbound queues (such as the hardware queues) of slow interfaces, VoIP packets are not stuck behind large packets, experiencing jitter and long delays.

On Frame Relay interfaces, fragmentation is configured based on the assumption that the G.729 codec is used and that a voice packet should not experience more than 10-ms delay due to being stuck behind another packet on the hardware queue. If G.729 is the assumed codec, an IP packet that is encapsulating two 10-ms digitized voice samples ends up being 60 bytes long ((8000 bps x 20/1000 sec / 8)+ 40 bytes). Because a VoIP packet should not be fragmented, the minimum fragment size is set to 60 bytes. The maximum fragment size, on the other hand, is calculated based on the 10-ms maximum delay and the configured bandwidth. For example, if the bandwidth is configured as 64 kbps, the maximum fragment size is calculated as 80 bytes (64,000 bps x 10/ 1000 sec / 8 bits/byte). If a codec such as G.711 is used instead of G.729, or if the bandwidth of an interface changes, you might have to modify the fragmentation size or disable and enable AutoQoS so that the changes affect the generated configuration.

Some prerequisites must be satisfied before AutoQoS is enabled on a router. Those prerequisites are as follows:

■ You must enable Cisco Express Forwarding (CEF) on the interface where AutoQoS is intended to be enabled, because AutoQoS relies on NBAR for discovery, and NBAR needs CEF.

■ You cannot apply a QoS policy (service policy) to the interface prior to enabling AutoQoS on that interface.

■ On all interfaces and subinterfaces, you must properly configure the bandwidth. On slow interfaces or subinterfaces, you must configure an IP address. AutoQoS enables MLP on slow interfaces and moves the IP address to the MLP virtual template.

■ For AutoQoS SNMP traps to work, you must enable SNMP on the router and specify the server address for SNMP traps destination. This address must be reachable from the router. The SNMP community string "AutoQoS" must have write permission.

Two-Step Deployment of AutoQoS Enterprise on Routers

Deploying AutoQoS for the Enterprise on Cisco routers is a two-step (or two-phase) process.

Step 1 is the auto-discovery step.

Step 2 is generation and deployment of MQC-based QoS policies based on the discovery step.

AutoQoS discovery uses NBAR protocol discovery. The type and volume of traffic on the network is discovered and analyzed in real-time to be able to generate realistic policies in Step 2. Generally speaking, the longer the auto-discovery runs, the more accurate the results will be. The default period is 3 days, but the administrator can certainly decide if 3 days is sufficient, or if it is too long or too short. Depending on the variety of applications and how often they run (once a day, week, or month), the length of time for running auto-discovery must be determined. The auto-discovery step is/was missing in AutoQoS VoIP; it goes straight to policy generation.

In Step 2, AutoQoS for Enterprise uses the results from the auto-discovery step to generate templates and install them on router interface(s). Templates are the basis for generation of MQC class maps and policy maps. After the policy maps are generated, AutoQoS applies them to the intended interfaces (using service-policy).

In Step 1, auto-discovery is enabled from the interface configuration mode by entering the auto discovery qos command:

tmp9-10_thumb

The optional keyword trust allows packets to be classified and receive appropriate QoS treatments based on preset QoS (DSCP) markings. Without the optional trust keyword, packets are classified based on the NBAR classification scheme, not based on the preset packet markings. The interface in which you enable auto-discovery must have CEF enabled and have its bandwidth configured (serial interface). Also, if it is a slow interface (<=768 kbps), it must have an IP address. The auto discovery qos command is not supported on a subinterface, and it is not supported on an interface that has a policy attached to it already. The configured bandwidth of the interface should not be changed after the command has been applied. Typing no auto discovery qos will stop auto-discovery (data collection), and it will remove any reports that have been generated. If you want to view the auto-discovery results, even before they are completed, you can do so by typing this command:

tmp9-11_thumb

The second step of implementing AutoQoS for Enterprise is enabling AutoQoS on the interface upon completion of the discovery step. The auto qos command causes generation of QoS templates that are used to create MQC class maps and policy maps and application of the policies to the interface. This command is also entered from the interface configuration mode:

tmp9-12_thumb

You use the keyword voip if you are enabling AutoQoS VoIP rather than AutoQoS Enterprise. On an earlier Cisco IOS release, this might be your only option. AutoQos for Enterprise was introduced in IOS release 12.3(7)T. Remember that AutoQoS VoIP does not require the discovery step. The trust keyword, again, is about respecting the preset marking of the entering packets rather than ignoring their marking and classifying them using NBAR. The keyword fr-atm enables AutoQoS VoIP for Frame Relay-to-ATM interworking.

Deploying AutoQoS VoIP on lOS-Based Catalyst Switches

Cisco Catalyst (LAN) switches support only AutoQoS VoIP. Catalyst switches with Cisco IOS are configured differently from Catalyst switches with Cisco Catalyst operating systems. The ONT course and exam focus on the Cisco IOS-based configuration and commands. More specifically, the emphasis is put on 2950(EI), 3550, and 4500 switches, with a few references made to 6500 switches. Please note that the 2950 switches require the Enhanced Image (EI) software and not the Standard Image (SI) for AutoQoS VoIP.

To enable AutoQoS VoIP on Catalyst switches, you need to be aware of two commands. The first one is meant for an access port where either a workstation or an IP phone is connected. The second command you need is meant for ports that are connected to other trusted devices such as routers and switches. A trusted device is a device whose marked traffic (QoS marking) is honored by the local device. Please note that AutoQoS VoIP support for IP softphone is only available on Catalyst 6500 switches (up to the time the Cisco ONT course was first released).

NOTE An IP phone has a built-in 3-port Ethernet switch. One port is connected to the IP phone and is not visible from outside the IP phone case. The two other Ethernet ports are accessible and located under the IP phone case. One port is meant to be connected to a LAN switch and the other is for a user workstation to plug into it and get connectivity to the LAN switch.

From the following two AutoQoS VoIP commands, the first command is for the IP phone connections, and the other is for trusted connections to other network devices:

tmp9-13_thumb

The command auto qos voip trust is applied to an interface that is assumed to be connected to a trusted device; the interface is usually an uplink trunk connection to another switch or router. This command also reconfigures the egress queues on the interface where it is applied.

On the interface where you apply the auto qos voip cisco-phone command, you must have CDP version 2 enabled. Using CDP version 2, the switch determines whether a Cisco IP phone is attached to the port. If CDP is not enabled or if it is CDP version 1, a syslog warning message is displayed. When a Cisco IP phone is detected on a port where the auto qos voip cisco-phone command is entered, the port classification trusts the QOS marking of the incoming packets. The command is said to extend the trust boundary to the Cisco IP phone when it is detected. The command also reconfigures the egress queues on the interface. The mls qos global configuration command is automatically enabled when you enter the auto qos voip command on the first interface. The mls qos command enables the QoS feature on the Catalyst switch.

The AutoQoS VoIP commands should not be applied to an interface where QoS commands have previously been configured. However, after you enable AutoQoS on an interface, you can fine-tune and modify the AutoQoS-generated configuration commands if necessary. The QoS markings of the incoming traffic are honored (trusted) on an interface in two cases. The first case is when the auto qos voip trust command is applied to an interface. The second case is when a Cisco IP phone is attached to the switch port, and the auto qos voip cisco-phone is applied to the interface. If a Cisco IP phone is disconnected from such a port and a workstation is connected to the port directly, the switch discovers the departure of the Cisco IP phone (using CDP version 2), and it changes its behavior to no trust on that port. The egress queuing and buffer allocation on a port are determined automatically based on the interface type; AutoQoS VoIP generates optimal priority queuing (PQ) and weighted round-robin (WRR) configurations for all port types, including static, dynamic access, voice VLAN (VVLAN), and trunk ports. As for mapping of the QoS markings, AutoQoS VoIP maps class of service (CoS) to DSCP as it forwards traffic toward the egress interface queue.

Verifying AutoQoS on Cisco Routers and lOS-Based Catalyst Switches

Monitoring and verifying AutoQoS on routers and switches have similarities and differences. Recall that AutoQoS Enterprise, which includes an initial protocol discovery phase, is not supported on Catalyst switches yet. On the other hand, Cisco Catalyst switches have a unique behavior of mapping the CoS setting of the incoming frames to DSCP, using a CoS-to-DSCP mapping scheme; this is useful for egress interface queuing purposes.

On both Cisco routers and Cisco IOS-based Catalyst switches, the show auto qos command displays the AutoQoS templates and initial configuration, whereas the show policy-map interface command displays the autogenerated policies and QoS parameters for each interface. The show auto discovery qos command, which relates to the discovery phase of the AutoQoS for enterprise and is therefore applicable only to routers, displays autodiscovery results for you to review. On Cisco IOS-based catalyst switches, the CoS-to-DSCP mapping can be displayed using the show mls qos maps command. Table 7-3 shows some important QoS verification commands for routers and Cisco IOS-based Catalyst switches.

Table 7-3 AutoQoS Verification Commands

Command Type

Command Syntax

Router

show auto discovery qos [interface interface]

Router

show auto qos [interface interface]

Router

show policy-map interface interface

Switch

show auto qos [interface interface]

Switch

show mls qos interface [interface 1 vlan vlan-id 1 buffers 1 policers 1 queuing 1 statistics]

Switch

show mls qos maps [cos-dscp 1 dscp-cos]

Sample (and partial) output of the router commands included in Table 7-3 is shown in Example 7-1. As displayed, the output of the show auto discovery qos interface command on a router displays the results of the collected data during the autodiscovery phase on the specified interface. It is recommended that you run the discovery phase for at least three days for more accurate results.

Example 7-1 Sample Output of AutoQoS Monitoring Commands

Sample Output of AutoQoS Monitoring Commands

Example 7-1 Sample Output of AutoQoS Monitoring Commands

Sample Output of AutoQoS Monitoring Commands

As shown on the sample output display, the show auto qos interface command on a router displays the MQC-based policy maps, class maps, and access lists generated by AutoQoS for the specified interface. The show policy-map interface command displays the packet statistics for all classes that are configured and referenced by the policy that is applied to the specified interface. Please note that for brevity, only small portions of the outputs are displayed.

In Example 7-2, you can see sample (and partial) output of the switch commands included in Table 7-3. The show auto qos command on a Catalyst switch displays the commands that the AutoQoS VoIP has initially generated for the switch (prior to any modifications that might have been applied). The sample output shows that 20 percent of the bandwidth is allocated to queue 1, 1 percent to queue 2, and 80 percent to queue 3. Because a value of 0 percent is assigned to queue number 4, this queue is the designated priority queue. CoS values of 0, 1, 2, and 4 are directed to queue 1, whereas CoS values 3, 6, and 7 are mapped to queue 3. CoS value 5 is mapped to queue 4. Queue 2 is not used at all. Finally, the CoS-to-DSCP mappings are shown (CoS 0 to DSCP 0, CoS 1 to DSCP 8, and so on).

Example 7-2 Sample (and Partial) Output of the Switch Commands Included in Table 7-3

Sample (and Partial) Output of the Switch Commands Included in Table 7-3

The output of the show mls qos interface interface command has various optional keywords available. A sample output in which the statistics keyword is used is shown in Example 7-2. The output of the show mls qos maps dscp-cos is shown last; it is obvious that the output displays the way DSCP is mapped to the CoS value for the egress packets. Please note that you can modify the default CoS-to-DSCP and DSCP-to-CoS mappings using the global configuration mode mls qos map command.

Next post:

Previous post: