Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
Voice Troubleshooting
Modern enterprise network designs need to support the transmission of voice traffic. This
voice traffic can come from both analog phones (much like the phones typically found in
homes) and IP phones, which are Ethernet devices that transmit voice IP packets. Because
the analog phones cannot generate IP packets, they connect to analog gateways (such as
Cisco routers), which convert the analog waveforms into IP packets.
The term Voice over IP (VoIP) is used to describe the transmission of voice over an IP
network using voice-enabled routers. However, the term IP telephony refers to the use of
IP phones and a call-processing server (for example, Cisco Unified Communications
Manager). More recently, Cisco began using the term Unified Communications, which
encompasses more than just voice. Unified communications includes a collection of
applications and technologies that enhance user collaboration. This section, however,
focuses on the IP telephony component of unified communications.
Overview of IP Telephony
An IP telephony network not only duplicates the features offered in traditional corporate
Private Branch Exchange (PBX) systems, but IP telephony expands on those features.
Figure 11-1 shows the basic components of an IP telephony network, which are described
in greater detail in the list that follows:
■ IP phone: An IP phone provides IP voice to the desktop.
330 CCNP TSHOOT 642-832 Official Certification Guide
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 331
■ Gatekeeper: A gatekeeper provides call admission control (CAC), bandwidth control
and management, and address translation features.
■ Gateway: A gateway provides translation between VoIP and non-VoIP networks,
such as the Public Switched Telephone Network (PSTN). A gateway also provides
physical access for local analog and digital voice devices, such as telephones, fax
machines, key sets, and PBXs.
■ Multipoint control unit (MCU): An MCU mixes audio and/or video streams, thus
allowing participants in multiple locations to attend the same conference.
■ Call agent: A call agent provides call control for IP phones, Call Admission Control
(CAC), bandwidth control and management, and address translation. Although a call
agent could be server-based, Cisco also supports a router-based call agent, known as
Cisco Unified Communications Manager Express (UCME).
■ Application server: An application server provides services such as voice mail,
unified messaging, and presence information (which can show the availability of
another user).
■ Videoconference station: A videoconference station provides access for end-user
participation in videoconferencing. The videoconference station contains a video capture
device for video input and a microphone for audio input. The user can view
video streams and hear audio originating at a remote user station. Cisco targets its
Cisco Unified Video Advantage product at desktop videoconferencing applications.
Design Considerations for Voice Networks
Successfully transmitting voice traffic over an IP network involves more than merely superimposing
voice packets on an existing data network. Voice traffic needs to be treated
in a special way, where it has higher priority than many other traffic types. Other design
considerations include the availability of the voice network, securing the voice network,
and a collection of other voice-related services. First, consider voice quality.
Quality of Service for Voice Traffic
Unlike much data traffic, voice traffic is highly latency-sensitive and drop-sensitive. Therefore,
when a network experiences congestion due to a lack of bandwidth, the following
symptoms can occur:
■ Delay: Delay is the time required for a packet to travel from its source to its destination.
You might have witnessed delay on the evening news, when the news anchor is
talking via satellite with a foreign news correspondent. Due to the satellite delay, the
conversation begins to feel unnatural.
■ Jitter: Jitter is the uneven arrival of packets. For example, in a voice conversation,
packet #1 arrives. Then, 20 minutes later, packet #2 arrives. After another 70 minutes,
packet #3 arrives, and then packet #4 arrives 20 minutes behind packet #3. This variation
in arrival times is not necessarily resulting in dropped packets. However, this jitter
can make the conversation sound as if packets are being dropped.
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
■ Drops: Packet drops occur when a link is congested and a buffer overflows. Some
types of traffic, such as UDP traffic (for example, voice and video traffic), are not
retransmitted if packets are dropped.
Fortunately, Cisco offers a collection of quality of service (QoS) features that can recognize
high-priority traffic (for example, voice and video) and treat that special traffic in a
special way. To effectively configure QoS in a network, you should consider how traffic is
treated end-to-end through the network. This implies not only configuring QoS on WAN
routers, but also configuring QoS on multiple switches and routers along the traffic’s path.
For example, even a wiring closet switch could benefit from a QoS configuration. Cisco
recommends marking traffic as close to the source as possible. However, you typically do
not want end users setting their own priority markings. Therefore, you can use Cisco Catalyst
switches to create a trust boundary, which is a point in the network that does not
trust incoming markings. An exception to having a wiring closet switch acting as a trust
boundary would be a Cisco IP Phone connected to the switch. Because a Cisco IP Phone
performs priority marking for voice traffic, you can extend the trust boundary to the
phone.
High Availability for Voice Traffic
PBX administrators often boast about their telephone system having the five nines of
availability, meaning that their network is up 99.999 percent of the time. This uptime percentage
equates to only five minutes of down time per year. Unfortunately, a common
perception about data networks is that they are not nearly as reliable. As a result, many organizations
are reluctant to replace their PBX and its track record of high availability with
a voice system that relies on what is perceived to be a less reliable data network.
To combat this somewhat-deserved stigma, today’s network designers must focus on the
redundancy and reliability of their designs. Fortunately, by using data components (for example,
routers and switches) with a high mean time between failures (MTBF) and including
redundant links with fast converging protocols, today’s networks can also approach
the five nines of availability.
Securing Voice Traffic
Similar to data traffic, voice traffic needs to be protected as it flows across a network. Beyond
protecting voice traffic with traditional precautions such as firewalling, protecting
voice traffic from potential eavesdroppers might include the following:
■ Separating voice and data traffic into different VLANs
■ Encrypting and authenticating voice media packets
■ Encrypting and authenticating voice signaling traffic
Other Services for Voice Traffic
In addition to QoS, availability, and security, introducing voice traffic into a data network
brings with it several other design considerations:
■ In-Line Power: A Cisco IP Phone requires -48 Volts of direct current (DC) to boot
up and operate. This voltage can be provided by an external power brick, which
332 CCNP TSHOOT 642-832 Official Certification Guide
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 333
connects into a wall power outlet and converts the wall outlet’s 120 Volts of alternating
current (AC) into the phone’s required -48 VDC. Alternately, power can be
provided by a Cisco Catalyst switch. Specifically, the switch can apply the required
voltage across the same leads used for Ethernet (that is, pins 1, 2, 3, and 6 in an RJ-45
connector). One approach for in-line power (also known as Power over Ethernet
[PoE]) is a Cisco-proprietary approach, which uses a Fast Link Pulse (FLP) to determine
if a switch port is connected to a device needing power. An industry-standard
approach to providing in-line power, however, is IEEE 802.3af. The 802.3af approach
looks for a 25,000 Ohm resistance attached to a switch port. The presence of this resistance
on a switch port indicates that the port should provide power to the attached
device. From a design and troubleshooting perspective, you should confirm that a
Cisco Catalyst switch and its attached Cisco IP Phones support the same type of
in-line power.
■ DHCP: Chapter 10, “IP Services Troubleshooting,” introduced DHCP operation and
how an end station could obtain IP address information via DHCP. Beyond IP address,
subnet mask, DNS server, and default gateway information, a Cisco IP Phone
can also obtain via DHCP the IP address (that is, DHCP option 150) or DNS name
(that is, DHCP option 66) of a TFTP server.
■ TFTP: A Cisco IP Phone communicates with a TFTP server to receive some or all of
its configuration information, in addition to firmware updates. This TFTP server
might be a Cisco Unified Communications Manager (UCM) server if that server is
acting as a call-processing agent for the Cisco IP Phone. Alternately, a Cisco IOS
router might be acting as the TFTP server, if that router is configured as a Cisco
UCME call agent.
■ NTP: Cisco IP Phones can also benefit from Network Time Protocol (NTP). Most
models of Cisco IP Phones obtain their time information from their call agent. This
time is then displayed on the phone. However, having accurate time information goes
well beyond the convenience of having the local time displayed on a phone. For example,
a call agent might be configured to permit or deny certain calls (for example,
international calls) based on office hours.
■ CDP: Cisco Discovery Protocol (CDP) is used by a Cisco Catalyst switch to inform
an attached Cisco IP Phone of the phone’s VLAN.
■ VLAN: Many Cisco IP Phones include a PC port, which allows a PC to connect to the
Cisco IP Phone for its Ethernet network connectivity. The Cisco IP Phone then connects
to a Cisco Catalyst switch in a wiring closet. To keep the voice and data traffic
separate, the Cisco IP Phone can place the phone’s voice traffic and the PC’s data traffic
in different VLANs. Traffic from these two VLANs is sent to the Cisco Catalyst
switch over a single IEEE 802.1Q trunk connection, as seen in Figure 11-2. The voice
VLAN is often referred to as an auxiliary VLAN, and the data VLAN is the native
VLAN (that is, an untagged VLAN) on the 802.1Q trunk. Even though this connection
between a Cisco IP Phone and the Cisco Catalyst switch is a trunk connection,
many Cisco Catalyst switches allow the switch port to be configured as a multi-
VLAN access port, rather than a trunk port. Specifically, even though a single connection
supporting more than one VLAN is typically referred to as a trunk connection, a
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Step 1
PoE
Step 2
Load Firmware Step 3
VLAN Learned via CDP
Step 4
IP Phone Obtains IP Configuration Information via DHCP
Step 5
IP Phone Configuration Received via TFTP
Step 6
IP Phone Registers with its Call Agent
Cisco IP
Phone Cisco UCME Router
DHCP Server
TFTP Server
Cisco Catalyst
Switch
Figure 11-3 Boot-Up Process for a Cisco IP Phone
Data VLAN
Auxiliary
VLAN
Data VLAN
Cisco IP
Switch Port Phone
for PC
PC Cisco Catalyst
Switch
Figure 11-2 IP Voice and Data VLAN Separation
multi-VLAN access port is an access port that can send and receive untagged traffic
(that is, the native VLAN traffic) in addition to traffic from an auxiliary VLAN.
334 CCNP TSHOOT 642-832 Official Certification Guide
Cisco IP Phone Boot-Up Process
Understanding the steps involved in a Cisco IP Phone booting up can aid in troubleshooting
a Cisco IP Phone that does not successfully register with its call agent. Recall that a
call agent could be a Cisco UCM server or a Cisco UCME router. These call agents could
also act as DHCP and TFTP servers.
As an example of a Cisco IP Phone’s boot-up process, consider the steps illustrated in
Figure 11-3. Assumptions for this example include the following:
■ The call agent is a UCME router.
■ The Cisco Catalyst switch and Cisco IP Phone both support the 802.3af PoE standard.
■ The UCME router is also acting as a DHCP server and TFTP server.
■ DNS services are not being used. Therefore, a Cisco IP Phone will obtain the IP
address of the TFTP server via DHCP rather than the TFTP server’s DNS name.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Table 11-2 Common Voice Troubleshooting Targets
Voice Troubleshooting Target Recommended Solutions
IP Services Check the configuration of the following IP services: CDP,
DHCP, TFTP, NTP.
QoS Check QoS configurations on routers and switches to confirm
that voice traffic is being correctly classified, is being
allocated a minimum amount of bandwidth, and is given
priority treatment.
Security Confirm voice and data VLAN separation. Additionally,
check the encryption and authentication configurations
for voice media and voice signaling traffic.
Power In a modular Cisco Catalyst switch chassis (for example, a
Cisco Catalyst 6500 chassis), the switch’s power supply
might not be sufficient to provide PoE to all attached
Cisco IP Phones. Therefore, check the switch’s power capacity
and current utilization level.
Key
Topic
Chapter 11: IP Communications Troubleshooting 335
■ The Cisco IP Phone is using Skinny Client Control Protocol (SCCP) as its signaling
protocol, as opposed to Session Initiation Protocol (SIP).
The following is the phone boot-up process:
Step 1. The Cisco IP Phone receives power via PoE.
Step 2. The Cisco IP Phone loads its firmware from its flash storage.
Step 3. The Cisco Catalyst switch informs the Cisco IP Phone of the phone’s VLAN.
Step 4. The Cisco IP Phone requests and receives its IP configuration information (including
DHCP option 150, which is the IP address of a TFTP server) via DHCP.
Step 5. The Cisco IP Phone requests and receives a portion of its configuration information
(including the IP address of the phone’s call agent) from its TFTP server.
Step 6. The Cisco IP Phone registers with its call agent and is now able to place and receive
calls. Note that the protocol that carries voice calls between the two IP
phones is Real-time Transport Protocol (RTP).
Common Voice Troubleshooting Issues
Because Cisco IP Phones rely on their underlying data network for communication, a
troubleshooting issue on the data network could impact phone operation. Data networking
troubleshooting targets should therefore be considered when troubleshooting a reported
voice issue. Additionally, as a reference, Table 11-2 offers a collection of common
voice troubleshooting targets and recommended solutions.
Key
Topic
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
336 CCNP TSHOOT 642-832 Official Certification Guide
Key
Topic
Overview of Quality of Service
One of the biggest potential troubleshooting targets for voice traffic involves QoS. Although
a comprehensive treatment of QoS is a study in itself and beyond the scope of the
TSHOOT curriculum, this section introduces you to basic QoS configuration principles
and commands used to monitor and troubleshoot a QoS configuration.
First, understand that QoS can classify traffic into different traffic classes. Cisco recommends
that this classification be performed as close to the source as possible. When the
traffic is classified, Cisco also recommends marking the traffic with a priority marking.
One such marking is Differentiated Services Code Point (DSCP). A DSCP marking uses
the six left-most bits in the Type of Service (ToS) byte in an IPv4 header. These six bits
can be used to create as many as 64 different DSCP values (in the range 0–63). The Internet
Engineering Task Force (IETF) selected a subset of these values and assigned names to
those values. These names are called Per-Hop Behaviors (PHB), because these DSCP values
can influence how traffic is treated at each hop (that is, router hop or switch hop)
along the path from the traffic’s source to its destination.
As an example, the DSCP numerical value of 46 also has the PHB name of Expedited Forwarding
(EF). Cisco IOS accepts either DSCP numerical values or DSCP PHB names. A
PHB of EF is the DSCP value that Cisco recommends you use to mark voice packets
(specifically, voice payload traffic, not voice signaling traffic). Fortunately, a Cisco IP
Phone, by default, marks voice frames leaving the phone with a PHB of EF. Therefore, if
routers or switches in the topology are configured to classify traffic based on DSCP markings,
they can easily recognize voice packets sourced from a Cisco IP Phone. If, however,
you have analog phones in your network connected into voice gateways, realize that those
voice packets are marked with a default DSCP value of zero (that is, a DSCP PHB of Default).
Therefore, you might want to configure that voice gateway to mark those voice
packets with a DSCP value of EF before transmitting those packets out of the router.
Once traffic has been classified and marked, routers and switches can examine those
markings and make decisions based on those markings (for example, forwarding decisions
or dropping decisions).
MQC
Cisco IOS offers a powerful three-step approach to QoS configuration, as illustrated in
Figure 11-4. This approach is known as the Modular Quality of Service Command Line
Interface, or MQC for short.
The following are the steps for the Modular Qos CLI:
Step 1. The first step of MQC is to create class maps, which categorize traffic types.
The following command enters you into class map configuration mode:
Router(config)#class-map [match-any match-all] class-name
Step 2. Once in class-map configuration mode, you can specify multiple match statements
to match traffic, and all traffic meeting the criteria you specified with
the match commands is categorized under the class map. If multiple match
statements are specified, by default, all match statements must be met before
a packet is classified by the class map. However, if you use the match-any
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 337
Step #3:
Apply the Policy to
an Interface
Service Policy
Step #2:
Assign Policies to
the Traffic Classes
Policy Map
Step #1:
Classify Traffic
Class Map
Figure 11-4 Modular QoS CLI
option, if any individual match condition is met, the packet is classified by the
class map. After the class maps are defined, the first step of MQC is complete.
R1# conf term
R1(config)# class-map match-any EMAIL
R1(config-cmap)# match protocol pop3
R1(config-cmap)# match protocol imap
R1(config-cmap)# match protocol smtp
Key
Topic
Step 3. The second step is to create a policy map that defines how the classified traffic
is to be treated. To enter policy map configuration mode, issue the following
command:
Router(config)#policy-map policy-name
Step 4. From policy map configuration mode, enter policy map class configuration
mode, with the following command:
Router(config-pmap)#class class-name
Step 5. From policy map class configuration mode, you can assign QoS policies to
traffic classified by each class map. You might also have a situation where a
packet matches more than one class map. In that case, the first class map identified
in the policy map is used. Up to 256 class maps can be associated with a
single policy map.
Step 6. Finally, in the third step of MQC, the policy map is applied to an interface,
Frame Relay map class, or ATM virtual circuit with the following command:
Router(config-if)#service-policy {input output} policy-map-name
Example 11-1 provides an MQC sample configuration that classifies various types of
e-mail traffic (for example, SMTP, IMAP, and POP3) into one class map. The KaZaa
protocol, which is frequently used for music downloads, is placed in another class map.
Voice over IP traffic is classified by yet another class map. Then, the policy map assigns
bandwidth allocations or limitations to these traffic types.
Example 11-1 MQC Sample Configuration
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
338 CCNP TSHOOT 642-832 Official Certification Guide
Table 11-3 MQC Verification Commands
Command Description
show class-map [class-map-name] Used to view what a class map is matching.
show policy-map [policy-map-name] Used to view the policy applied to the classes
within a policy map.
show policy-map interface interfaceidentifier
[input | output]
Used to view policy map statistics for packets
crossing a specific interface.
Key
Topic
R1(config-cmap)# exit
R1(config)# class-map MUSIC
R1(config-cmap)# match protocol kazaa2
R1(config-cmap)# exit
R1(config)# class-map VOICE
R1(config-cmap)# match protocol rtp audio
R1(config-cmap)# exit
R1(config)# policy-map TSHOOT-EXAMPLE
R1(config-pmap)# class EMAIL
R1(config-pmap-c)# bandwidth 128
R1(config-pmap-c)# exit
R1(config-pmap)# class MUSIC
R1(config-pmap-c)# police 32000
R1(config-pmap-c)# exit
R1(config-pmap)# class VOICE
R1(config-pmap-c)# priority 256
R1(config-pmap-c)# exit
R1(config-pmap)# exit
R1(config)# interface serial 0/1
R1(config-if)# service-policy output TSHOOT-EXAMPLE
Notice that the policy map named TSHOOT-EXAMPLE makes at least 128 kbps of
bandwidth available to e-mail traffic. However, KaZaa version 2 traffic has its bandwidth
limited to 32 kbps. Voice packets not only have access to 256 kbps of bandwidth, but
they receive priority treatment, meaning that they are sent first (that is, ahead of other
traffic), up to a 256-kbps limit.
The next logical question is, “What happens to all the traffic that was not classified by
one of the configured class maps?” Interestingly, Cisco created a class map named classdefault,
which categorizes any traffic not matched by one of the defined class maps.
Finally in the example, the policy map is applied in the outbound direction on the Serial
0/1 interface.
Table 11-3 provides a listing of verification and troubleshooting commands for MQC
configurations.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 339
Example 11-2 provides sample output from the show class-map command. The output
shows each class map, including the default class map of class-default. You can also see
how traffic is classified in each class. For example, the EMAIL class is using match-any
logic, where a packet is classified in the class if it is POP3, IMAP, or SMTP.
Example 11-2 show class-map Command Output
Example 11-3 provides sample output from the show policy-map command. The output
shows how each class of traffic is to be treated. For example, the EMAIL class has access
to at least 128 kbps of bandwidth if it requires that much and more if it needs it and more
is available. The MUSIC class of traffic has a maximum bandwidth utilization limit of
32 kbps. If traffic exceeds that 32-kbps limit, that excess traffic is dropped. The VOICE
class of traffic guarantees the voice traffic has access to as much as 256 kbps of bandwidth
if that much is required. This traffic is configured to have priority treatment,
meaning this traffic is sent ahead of other traffic types. However, traffic from this class is
not allowed to exceed 256 kbps, to prevent protocol starvation of other traffic classes.
Example 11-3 show policy-map Command Output
R1# show class-map
Class Map match-any class-default (id 0)
Match any
Class Map match-all MUSIC (id 2)
Match protocol kazaa2
Class Map match-any EMAIL (id 1)
Match protocol pop3
Match protocol imap
Match protocol smtp
Class Map match-all VOICE (id 3)
Match protocol rtp audio
R1# show policy-map
Policy Map TSHOOT-EXAMPLE
Class EMAIL
Bandwidth 128 (kbps) Max Threshold 64 (packets)
Class MUSIC
police cir 32000 bc 1500
conform-action transmit
exceed-action drop
Class VOICE
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
340 CCNP TSHOOT 642-832 Official Certification Guide
Example 11-4 provides sample output from the show policy-map interface interfaceidentifier
command. The output in this example is from interface Serial 0/1. The output
shows how traffic is classified in each class and how the policy map is treating each traffic
class. Additionally, the output shows packet and byte counts for traffic matching each
class.
Example 11-4 show policy-map interface interface-identifier Command Output
R1# show policy-map interface serial0/1
Serial0/1
Service-policy output: TSHOOT-EXAMPLE
Class-map: EMAIL (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol pop3
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol imap
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: MUSIC (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol kazaa2
police:
cir 32000 bps, bc 1500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Strict Priority
Bandwidth 256 (kbps) Burst 6400 (Bytes)
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 341
Key
Topic
Table 11-4 AutoQoS Platform Support
AutoQoS Version Platform Support
AutoQoS VoIP Routers
Catalyst Switches
AutoQoS Enterprise Routers
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp audio
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 256 (kbps) Burst 6400 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
23 packets, 1715 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
AutoQoS
Optimizing a QoS configuration for VoIP can be a daunting task. Fortunately, Cisco
added a feature called AutoQoS VoIP to many of its router and switch platforms to generate
router-based or switch-based QoS configurations designed to ensure voice quality.
A few years after introducing AutoQoS VoIP, Cisco introduced AutoQoS Enterprise,
which can automatically generate a QoS configuration on a router that seeks to provide
appropriate QoS parameters for all of an enterprise’s traffic types (that is, not just voice
traffic).
Table 11-4 summarizes the platform support for these two versions of AutoQoS.
First, consider the configuration of AutoQoS VoIP on a router. In interface configuration
mode (or Frame Relay DLCI configuration mode), AutoQoS can be enabled with the following
command:
Router(config-if)# auto qos voip [trust] [fr-atm]
The trust option indicates that Auto QoS should classify voice traffic based on DSCP
markings, instead of using Network-Based Application Recognition (NBAR). The fr-atm
option allows Frame Relay Discard Eligible (DE) markings to be converted into ATM Cell
Loss Priority (CLP) markings, and vice versa.
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
342 CCNP TSHOOT 642-832 Official Certification Guide
Before enabling AutoQoS on a router interface, consider the following prerequisites:
■ CEF must be enabled.
■ A QoS policy must not be currently attached to the interface.
■ The correct bandwidth should be configured on the interface.
■ An IP address must be configured on an interface if its speed is equal to or less than
768 kbps.
Note that the interface’s bandwidth determines which AutoQoS features are enabled. If an
interface’s bandwidth is equal to or less than 768 kbps, it is considered to be a low-speed
interface. On a low-speed interface, AutoQoS might configure Multilink PPP (MLP),
which requires an IP address on the physical interface. AutoQoS takes that IP address
from the physical interface and uses it for a virtual multilink interface it creates.
To verify that AutoQoS is configured for a router interface, you can use the following
command:
Router# show auto qos voip [interface interface-identifier]
This command displays global and interface (or optionally, only interface) configuration
mode commands added by the AutoQoS VoIP feature.
Example 11-5 shows a sample of configuring and verifying AutoQoS VoIP on a router.
Example 11-5 Configuring and Verifying AutoQoS VoIP on a Router
Key
Topic
R1# conf term
R1(config)# int s0/0
R1(config-if)# auto qos voip
R1(config-if)# end
R1# show auto qos
!
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767
!
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
!
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 343
!
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
!
class-map match-any AutoQoS-VoIP-Remark
match ip dscp ef
match ip dscp cs3
match ip dscp af31
!
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
encapsulation ppp
no fair-queue
ppp multilink
ppp multilink group 2001100114
!
interface Multilink2001100114
bandwidth 128
ip address 10.1.1.1 255.255.255.0
service-policy output AutoQoS-Policy-UnTrust
ppp multilink
ppp multilink fragment delay 10
ppp multilink interleave
ppp multilink group 2001100114
ip rtp header-compression iphc-format
!
rmon event 33333 log trap AutoQoS description “AutoQoS SNMP traps for Voice
Drops” owner AutoQoS
rmon alarm 33334 cbQosCMDropBitRate.1271.1273 30 absolute rising-threshold 1
33333 falling-threshold 0 owner AutoQoS
Next, consider the configuration of AutoQoS VoIP on some models of Cisco Catalyst
switches (for example, most new models of Cisco IOS-based Catalyst switches). To configure
AutoQoS on these platforms, issue one of the following commands from interface
configuration mode:
Switch(config-if)# auto qos voip trust
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
344 CCNP TSHOOT 642-832 Official Certification Guide
This command configures the interface to trust Class of Service (CoS) markings (that is,
Layer 2 QoS priority markings on an Ethernet connection) for classifying VoIP traffic.
Switch(config-if)# auto qos voip cisco-phone
This command configures the interface to trust CoS markings only if those markings
came from an attached Cisco IP Phone. CDP is used to detect an attached Cisco IP Phone.
Example 11-6 shows a sample of configuring and verifying AutoQoS VoIP on a switch.
Example 11-6 Configuring and Verifying AutoQoS VoIP on a Switch
Cat3550# conf term
Cat3550(config)# int gig 0/1
Cat3550(config-if)# auto qos voip cisco-phone
Cat3550(config-if)# end
Cat3550# show run
Building configuration...
...OUTPUT OMITTED...
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos
!
interface GigabitEthernet0/1
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
wrr-queue bandwidth 10 20 70 1
wrr-queue queue-limit 50 25 15 10
wrr-queue cos-map 1 0 1
wrr-queue cos-map 2 2 4
wrr-queue cos-map 3 3 6 7
wrr-queue cos-map 4 5
priority-queue out
spanning-tree portfast
...OUTPUT OMITTED...
Next, consider the configuration of AutoQoS Enterprise. This version of AutoQoS has the
same collection of prerequisites shown earlier for AutoQoS VoIP. However, unlike Auto-
QoS VoIP, AutoQoS Enterprise targets all known applications on an enterprise network.
Fortunately, you do not have to specify the individual applications and protocols you
want to support. AutoQoS Enterprise instead dynamically learns the applications and protocols
seen on an interface. Cisco recommends that this learning process, called the
discovery phase, be conducted for at least two or three days. During this time, a router
can use existing DSCP values (that is, Layer 3 QoS markings) or NBAR to classify traffic
seen on an interface. Traffic can be classified into as many as ten classes by AutoQoS Enterprise.
The following interface configuration mode command is issued to begin the discovery
phase of AutoQoS Enterprise:
Router(config-if)# auto discovery qos [trust]
www.CareerCert.info
www.CareerCert.info
www - CareerCert - info
Chapter 11: IP Communications Troubleshooting 345
The trust keyword instructs the router to classify traffic based on existing DSCP markings,
as opposed to using NBAR.
After the discovery phase runs for at least two or three days, you can issue the show auto
discovery qos command to see what traffic has been classified and what behavior is specified
in the recommended policy.
After examining the output of the show auto discovery qos command, if you are satisfied
with the proposed configuration, you can apply the configuration by issuing the
auto qos command in interface configuration mode for the interface that performed the
discovery phase.
Example 11-7 shows these commands being issued for the Fast Ethernet 0/0 interface on a
router named R4. The output of the show auto discovery qos command shows the ten
classes of traffic that could be populated by the AutoQoS Enterprise feature, as indicated
by the highlighted output.
No comments:
Post a Comment