Chapter 7: Improving and Maintaining Voice Quality

Cisco Press

1 2 3 4 5 6 Page 3
Page 3 of 6

Note - Cisco AutoQoS is available in the following Cisco IOS software releases—Cisco IOS Software Release 12.1E or later for the Cisco Catalyst 2950 and 3550 Series switches; Cisco IOS Software Release 12.2T or later for the Cisco 2600, 2600XM, 3600, 3700, and 7200 Series routers; Cisco IOS Software Release 12.1E or later for the Cisco Catalyst 4500 Series switches; and Cisco Catalyst Operating System 7.5.1 or later for the Cisco Catalyst 6500 Series switches. For current information concerning AutoQoS platform support, check Cisco's Feature Navigator at http://www.cisco.com/go/fn.


Configuring AutoQoS on a Router

On a router platform, the following command enables AutoQoS from either interface configuration mode or from DLCI configuration mode (for a Frame Relay circuit):

Router(config-if)#auto qos voip [trust] [fr-atm]

The trust option indicates that AutoQos should classify voice traffic based on Layer 3 Differentiated Services Code Point (DSCP) priority markings, instead of using Network-Based Application Recognition (NBAR). The fr-atm option enables the AutoQoS feature for Frame Relay-to-ATM links and is issued from DLCI configuration mode.

Before enabling AutoQoS on a router interface, consider the following prerequisites:

  • Cisco Express Forwarding (CEF) must be enabled, because AutoQoS uses NBAR, which requires the CEF feature.

  • A QoS policy must not be currently attached to the interface.

  • The correct bandwidth should be configured on the interface, using the bandwidth command.

  • An IP address must be configured on an interface if its speed is less than 768 kbps.

  • The interface must not be administratively shut down.

Note that the interface's bandwidth determines which AutoQoS features are enabled. If an interface's bandwidth is less than 768 kbps, it is considered a low-speed interface. On a low-speed interface, AutoQoS configures Multilink PPP (MLP), which requires an IP address on the physical interface. AutoQoS takes the IP address from the physical interface and uses it for the virtual multilink interface that it creates.

To verify that AutoQoS is configured for a router interface, use the following command:

Router#show auto qos [interface interface-identifier]

To illustrate some of the configuration changes that AutoQoS can perform, consider the configuration of a serial interface shown in Example 7-1, without AutoQoS enabled.

Example 7-1  Router Configuration Without AutoQoS

interface Serial0/0
 bandwidth 128
 ip address 10.1.1.1 255.255.255.0
 encapsulation ppp

Example 7-2 illustrates the configuration changes after entering the auto qos voip command for interface Serial 0/0.

Example 7-2 Router Configuration with AutoQoS

class-map match-any AutoQoS-VoIP-Remark 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 ! 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 ! interface Multilink2001100114 bandwidth 128 ip address 10.1.1.1 255.255.255.0 service-policy output AutoQoS-Policy-UnTrust ip tcp header-compression iphc-format ppp multilink ppp multilink fragment delay 10 ppp multilink interleave ppp multilink group 2001100114 ip rtp header-compression iphc-format ! interface Serial0/0 bandwidth 128 no ip address encapsulation ppp auto qos voip clockrate 128000 no fair-queue ppp multilink ppp multilink group 2001100114 ! 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 ip access-list extended AutoQoS-VoIP-RTCP permit udp any any range 16384 32767 ! rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Drops" owner AutoQoS rmon alarm 33333 cbQosCMDropBitRate.1081.1083 30 absolute rising-threshold 1 33333

falling-threshold 0 owner AutoQoS

The bandwidth configured for interface Serial 0/0 was set to 128 kbps. Therefore, AutoQoS determined that certain link efficiency mechanisms (for example, Multilink PPP, RTP Header Compression, and TCP Header Compression) were appropriate. AutoQoS, therefore, automatically configured these link efficiency mechanisms in addition to multiple other QoS mechanisms, including classification, marking, LLQ, and Remote Monitoring (RMON) traps to alert administrators if packet drops are excessive.

AutoQoS for Enterprise

Introduced in Cisco IOS Software Release 12.3(7)T, AutoQoS for Enterprise extends the capabilities of AutoQoS on a Cisco router platform. Specifically, AutoQoS for Enterprise allows a router to recognize multiple protocols traversing an interface and recommends a customized policy, based on learned traffic patterns.

To configure a router's interface to begin learning traffic patterns, enter the following command in interface configuration mode:

Router(config-if)#auto discovery qos

After entering the previous command, wait for a period of time for the router to learn the traffic patterns crossing the interface. The ability to dynamically learn these patterns is made possible by the Cisco IOS software's NBAR feature.

After waiting a period of time (for example, 30 minutes to an hour in a time period representative of peak network usage) during which the router is learning the traffic patterns of the network, enter the following command to view the router's findings and to see the recommended policy for the interface:

Router#show auto discovery qos

Example 7-3 offers an example of the output received after issuing the show auto discovery qos command.

Example 7-3 Output from the show auto discovery qos Command

R4#show auto discovery qos
Serial0/0       
 AutoQoS Discovery enabled for applications
 Discovery up time—46 seconds
 AutoQoS Class information:
 Class Voice—
 Recommended Minimum Bandwidth—40 Kbps/31% (PeakRate)
 Detected applications and data:
 Application/    AverageRate    PeakRate      Total       
 Protocol        (kbps/%)       (kbps/%)      (bytes)      
 -----------     -----------    --------      ------------   
 rtp audio       28/21          40/31          161160      
 Class Interactive Video—
 No data found.
 Class Signaling—
 Recommended Minimum Bandwidth—0 Kbps/0% (AverageRate)
 Detected applications and data:
 Application/   AverageRate    PeakRate      Total       
 Protocol       (kbps/%)       (kbps/%)      (bytes)      
 -----------    -----------    --------      ------------   
 skinny         0/0            0/0           3648       
 Class Streaming Video—
  No data found.
 Class Transactional—
  No data found.
 Class Bulk—
  No data found.
 Class Scavenger—
  No data found.
 Class Management—
  No data found.
 Class Routing—
  Recommended Minimum Bandwidth—0 Kbps/0% (AverageRate)
  Detected applications and data:
  Application/    AverageRate    PeakRate      Total       
  Protocol        (kbps/%)       (kbps/%)      (bytes)      
  -----------     -----------    --------      ------------   
  eigrp           0/0            0/0           640        
  icmp            0/0            0/0           120        
 Class Best Effort—
  Current Bandwidth Estimation—77 Kbps/60% (AverageRate)
  Detected applications and data:
  Application/    AverageRate    PeakRate      Total       
  Protocol        (kbps/%)       (kbps/%)      (bytes)  
  -----------     -----------    --------      ------------      
  http            77/60          110/85        446413      
  unknowns        0/0            0/0           104        
  
Suggested AutoQoS Policy for the current uptime:
 !
 class-map match-any AutoQoS-Voice-Se0/0
 match protocol rtp audio
 !
 policy-map AutoQoS-Policy-Se0/0
 class AutoQoS-Voice-Se0/0
  priority percent 31
  set dscp ef
 class class-default
fair-queue

If you find the suggested policy acceptable and wish to apply the dynamically created policy, go into interface configuration mode for the monitored interface and enter the following command:

Router(config-if)#auto qos

This auto qos command applies the recommended policy to the router.

Configuring AutoQoS on a Catalyst Switch

The QoS mechanisms on a Catalyst switch differ from those QoS mechanisms found on a router. For example, while a router uses LLQ as a priority queuing strategy, a Catalyst switch might use weighted round-robin (WRR) as a priority queuing strategy. Fortunately, the AutoQoS feature available on some Catalyst switch models (for example, the Cisco Catalyst 2950(EI) and 3550 Series) apply voice-specific QoS features globally to a Catalyst switch and also at the port level.

To configure AutoQoS on supported Catalyst switch platforms (running the Native IOS), issue the following command from interface configuration mode:

Switch(config-if)#auto qos voip [trust | cisco-phone]

If the trust option is used in the previous command, the Catalyst switch makes queuing decisions based on Layer 2 Class of Service (CoS) markings. However, if the cisco-phone option is used, the Catalyst switch makes queuing decisions based on CoS markings originating from a Cisco IP phone. The switch detects the presence of a Cisco IP phone via the CDP.

To illustrate the configuration changes made by a Catalyst switch's AutoQoS feature, consider Example 7-4, which shows the initial configuration of interface Gigabit 0/1 on a Catalyst 3550 switch.

Example 7-4 Catalyst Switch Configuration Without AutoQoS

interface GigabitEthernet0/1
 no ip address

Example 7-5 illustrates the configuration changes after entering the auto qos voip cisco-phone command for interface Gigabit 0/1.

Example 7-5 Catalyst Configuration with AutoQoS

mls qos map cos-dscp 0 8 16 26 32 46 48 56
mls qos
!
interface GigabitEthernet0/1
 no ip address
 mls qos trust device cisco-phone
 mls qos trust cos
 auto qos voip cisco-phone 
 wrr-queue bandwidth 20 1 80 1
 wrr-queue queue-limit 80 1 20 1
 wrr-queue cos-map 1 0 1 2 4
 wrr-queue cos-map 3 3 6 7
 wrr-queue cos-map 4 5
 priority-queue out

Example 7-5 demonstrates that the AutoQoS feature configured the Catalyst switch to enable QoS globally (with the mls qos command) and remark Layer 2 CoS markings to Layer 3 Differentiated Services Code Point (DSCP) markings (with the mls qos map cos-dscp command). Also, AutoQoS configured WRR for interface Gigabit 0/1 and placed traffic with a CoS value of 5 (that is, voice traffic) in a priority queue, which is emptied ahead of other queues.

Implementing Call Admission Control

To prevent oversubscription of VoIP networks, the number of voice calls allowed on the network must be limited. This section describes the configuration parameters for implementing CAC, which can prevent oversubscription of WAN resources.

Effects of Bandwidth Oversubscription

QoS tools such as queuing ensure that voice traffic receives priority over data traffic. However, if a network link is oversubscribed with too much voice traffic, data packets are dropped, and the remaining voice calls suffer because they must compete for bandwidth available to the low-latency queue.

Figure 7-5 illustrates the effect of voice oversubscription. Using LLQ, voice traffic is directed into a priority queue (PQ) while all other traffic is directed into various CBWFQ queues. Note that the priority queue forwards packets while the data packets, destined for the CBWFQ queues, are denied entry to the queue and are dropped. In the case shown in Figure 7-5, even the priority queue buffer is full. Therefore, the voice packets are competing with other voice packets for access to the network link. This situation results in a degradation of all voice calls on this link.

Figure 7.5

Figure 7-5

Effect of Oversubscription

CAC Operation

CAC can function on the outgoing gateway and base its decision on nodal information, such as the state of the outgoing LAN or WAN link. For example, if the local IP network link is down, there is no point in executing complex decision logic based on the state of the rest of the network, because the network is unreachable.

As another example, if the network designer already knows that bandwidth limitations allow no more than two calls across the outgoing WAN link, as illustrated in Figure 7-6, then the local node can be configured to allow no more than two calls. You can configure this type of CAC on outgoing dial peers.

Figure 7.6

Figure 7-6

The Need for CAC

RSVP

RSVP is the only CAC mechanism that makes actual bandwidth reservations for calls. RSVP offers the unique advantage of not only providing CAC for voice but also guarantees the QoS against changing network conditions for the duration of the call. The RSVP reservation is made in both directions because a voice call requires a two-way speech path. Therefore, bandwidth is reserved in both directions, as depicted in Figure 7-7.

Figure 7.7

Figure 7-7

RSVP

The terminating gateway ultimately makes the CAC decision based on whether both reservations succeed. At that point, H.323 continues with either an H.225 Alerting/Connect (the call is allowed and proceeds), or with an H.225 Reject/Release (the call is denied). The RSVP reservation is in place by the time the destination phone starts ringing and the caller hears ringback.

RSVP has the following important differences from other CAC methods discussed in this section:

Related:
1 2 3 4 5 6 Page 3
Page 3 of 6
SD-WAN buyers guide: Key questions to ask vendors (and yourself)