VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority)

Introduction

This document shows Voice over IP (VoIP) over a Frame Relay network sample configuration with Quality of Service (QoS). This document includes background technical information on the configured features, design guidelines, and basic verification and troubleshooting strategies.

It is important to note that the configuration in this document has two voice routers that are connected to the Frame Relay network. In many topologies however, the voice enabled routers can exist anywhere. Usually, the voice routers use LAN connectivity to other routers which are connected to the WAN. This is important because if your voice routers are not directly connected to the Frame Relay network, all WAN configuration commands must be configured on those routers connected to the WAN, and not on the voice routers, as shown in the configurations in this document.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

• Cisco 3640 Router with Cisco IOS® Software Release 12.2.6a (Enterprise Plus)

• Cisco 2621 Router with Cisco IOS Software Release 12.2.6a (Enterprise Plus)

• Low latency queueing (LLQ) on Frame Relay permanent virtual circuits (PVCs). This is introduced in Cisco IOS Software Release 12.1.(2)T.

• Frame Relay IP Real-Time Transport Protocol (RTP) Priority which is introduced in Cisco IOS Software Release 12.0(7)T.

• Frame Relay Forum (FRF).12 Fragmentation which is introduced in Cisco IOS Software Release 12.0(4)T.

• Cisco IOS Software Releases later than 12.0.5T contain significant performance improvements for compressed RTP (cRTP).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

QoS Design Guidelines for VoIP over Frame Relay

There are two basic requirements for good voice quality:

• Minimal end-to-end delay and jitter avoidance (delay variation).

• Link bandwidth requirements optimized and correctly engineered.

To guarantee the previously mentioned requirements, use these guidelines:

• Strict Priority for Voice Traffic LLQ or IP RTP Priority

• Frame Relay Traffic Shaping (FRTS) for Voice

• Fragmentation FRF.12

• Bandwidth Reduction

Strict Priority for Voice Traffic (LLQ or IP RTP Priority)

There are two primary methods to provide strict priority for voice traffic:

• IP RTP Priority (also called Priority Queue / Weighted Fair Queuing (PQ/WFQ))

• LLQ (also called PQ / Class Based Weighted Fair Queuing (PQ/CBWFQ))

IP RTP Priority

Frame Relay IP RTP Priority creates a strict priority queue on a Frame Relay PVC for a set of RTP packet flows that belong to a range of User Datagram Protocol (UDP) destination ports. While the actual ports used are dynamically negotiated between end-devices or gateways, all Cisco VoIP products utilize the same UDP port range (16384 through 32767). Once the router recognizes the VoIP traffic, it places it into the strict PQ. When the PQ is empty, the other queues are processed based on standard WFQ. IP RTP Priority does not become active until there is congestion in the interface. This image illustrates the operation of IP RTP Priority:

Note: IP RTP Priority allows bursting the PQ when there is available bandwidth on the default queue (WFQ). However, it strictly polices the PQ contents when there is congestion on the interface.

LLQ

LLQ is a feature that provides a strict PQ to CBWFQ. LLQ enables a single strict PQ within CBWFQ at the class level. With LLQ, delay-sensitive data (in the PQ) is dequeued and sent first. In a VoIP with LLQ implementation, voice traffic is placed in the strict PQ.

The PQ is policed to ensure that the fair queues are not starved of bandwidth. When you configure the PQ, you specify, in Kbps, the maximum amount of bandwidth available to the PQ. When the interface is congested, the PQ is serviced until the load reaches the configured Kbps value in the priority statement. Excess traffic is then dropped to avoid the problem with Cisco's legacy priority-group feature of starving the lower PQs.

Note: With LLQ for Frame Relay, queues are set up on a per-PVC basis. Each PVC has a PQ and an assigned number of fair queues.

This method is more complex and flexible than IP RTP Priority. The choice between the methods needs to be based on the patterns of traffic in your real network and your needs.

LLQ vs. IP RTP Priority

This table summarizes the main differences between LLQ and IP RTP Priority and provides guidelines of when to use each method.

FRTS for Voice

FRTS provides parameters that are useful to manage network traffic congestion. FRTS eliminates bottlenecks in Frame Relay networks with high-speed connections to the central site and low-speed connections to the branch sites. You can configure rate enforcement values to limit the rate at which data is sent from the virtual circuit (VC) at the central site.

These definitions are related to FRTS:

• Committed Information Rate (CIR)—Rate (bits per second) the Frame Relay provider guarantees for data transfer. CIR values are set by the Frame Relay service provider and configured by the user on the router.

  Note: The port/interface access rate can be higher than CIR. The rate is averaged over a Committed Rate Measurement Interval (Tc) period of time.

• Committed Burst (Bc)—Maximum number of bits the Frame Relay network commits to transfer over a Tc. Tc = Bc / CIR.

• Excess Burst (Be)—Maximum number of uncommitted bits the Frame Relay switch attempts to transfer beyond the CIR over the Tc.

• Committed Rate Measurement Interval (Tc)—Time interval over which Bc or (Bc+ Be) bits are transmitted. Tc is calculated as Tc = Bc / CIR. The Tc value is not directly configured on Cisco routers. It is calculated after the Bc and CIR values are configured. Tc cannot exceed 125 ms.

• Backwards Explicit Congestion Notification (BECN)—A bit in the Frame Relay frame header that indicates congestion in the network. When a Frame Relay switch recognizes congestion, it sets the BECN bit on frames destined for the source router and instructs the router to reduce the transmission rate.

The configuration of FRTS for voice traffic is different from that of traffic shaping for data only. When configuring FRTS for voice quality, compromises are made with the data traffic parameters. For more information on these restrictions see the Fragmentation (FRF.12) section in this document.

Fragmentation (FRF.12)

A big challenge on voice-data integration is to control the maximum one way end-to-end delay for time sensitive traffic such as voice. For good voice quality, this delay needs to be less than 150 ms. An important part of this delay is the serialization delay on the interface. Cisco recommends that this be 10 ms and should not exceed 20 ms. Serialization delay is the time it takes to actually place the bits onto an interface.

Serialization Delay = frame size (bits) / link bandwidth (bps)

For example, a 1500-byte packet takes 214 ms to leave the router over a 56 Kbps link. If a non-real-time data packet of 1500 bytes is sent, real-time (voice) data packets are queued until the large data packet is transmitted. This delay is unacceptable for voice traffic. If non-real-time data packets are fragmented into smaller frames, they are interleaved with real-time (voice) frames. In this way, both voice and data frames can be carried together on low speed links without causing excessive delay to the real-time voice traffic.

For more information on fragmentation, refer to Frame Relay Fragmentation for Voice.

Note: In cases where you have a dedicated half T1 connection (768 kbps), you probably do not need a fragmentation feature. However, you still need a QoS mechanism (IP RTP Priority or LLQ, in this case). The half T1 or greater speeds offer enough bandwidth to allow voice packets to enter and leave the queue within the recommended serialization delay range (10 ms, no later than 20 ms). Also, you probably do not need cRTP, which helps to save bandwidth by compressing IP RTP headers, in the case of a full T1.

Bandwidth Reduction

cRTP

Based on RFC 2508 , the cRTP feature compresses the IP/UDP/RTP packet header from 40 bytes to 2 or 4 bytes. This reduces unnecessary bandwidth consumption. It is a hop-by-hop compression scheme. Therefore, cRTP must be configured on both ends of the link, unless the passive option is configured.

Note: cRTP is not required to ensure good voice quality. It is a feature that reduces bandwidth consumption. Configure cRTP after all other conditions are met and the voice quality is good. This procedure saves troubleshooting time because it isolates potential cRTP issues.

Monitor the router's CPU utilization. Disable cRTP if it is above 75 percent. At higher link rates, the bandwidth savings of cRTP might potentially be outweighed by the additional CPU load. Cisco only recommends using cRTP with links lower than 768 Kbps, unless the router runs at a low CPU utilization rate.

Note: At the absence of a standard, cRTP for Frame Relay was developed on Cisco Proprietary encapsulation. Therefore, it does not work with Internet Engineering Task Force (IETF) encapsulation of Frame Relay. Recently, FRF.20 was finalized to make RTP header compression possible on IETF encapsulation. However, as of the last update of this document (May, 2002), FRF.20 is not supported.

For more information, refer to Compressed Real-time Transport Protocol .

Coder/Decoder (Codec) Selection

Use low bit-rate codecs on the VoIP call legs. G.729 (8 Kbps) is the default codec for the VoIP dial-peer.

Note: Although dual tone multifrequency (DTMF) is usually transported accurately when high-bit-rate voice codecs are used (such as G.711), low-bit-rate codecs (such as G.729 and G.723.1), are highly optimized for voice patterns and tend to distort DTMF tones. This approach can result in problems accessing interactive voice response (IVR) systems. The dtmf relay command solves the problem of DTMF distortion. It transports DTMF tones out-of-band or separate from the encoded voice stream. If you use low-bit-rate codecs (G.729, G.723) turn on the dtmf relay command under the VoIP dial-peer.

Enable Voice Activity Detection (VAD)

A typical conversation might potentially contain 35 to 50 percent silence. Silence packets are suppressed when VAD is used. For VoIP bandwidth planning, assume that VAD reduces bandwidth by 35 percent. VAD is configured by default under the VoIP dial-peers.

Configure

In this section, you are presented with the information to configure the features described in this document.

Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .

LLQ

Use this procedure to configure LLQ:

1. Create a class map for VoIP traffic and define match criteria.

   These commands explain how to complete this task:

   maui-voip-sj(config)#class-map ?
          WORD 		class-map name
          match-all 	Logical-AND all matching statements under this classmap
          match-any 	Logical-OR all matching statements under this classmap
   maui-voip-sj(config)#class-map match-all voice-traffic 
   
   !--- Choose a descriptive class_name. 
   
   
   maui-voip-sj(config-cmap)#match ?
     access-group         Access group
     any                  Any packets
     class-map            Class map
     cos                  IEEE 802.1Q/ISL class of service/user priority values
     destination-address  Destination address
     input-interface      Select an input interface to match
     ip                   IP specific values
     mpls                 Multi Protocol Label Switching specific values
     not                  Negate this match result
     protocol             Protocol
     qos-group            Qos-group
     source-address       Source address
   
   !--- In this example the access-group matching !--- option is used for its flexibility (it uses an access-list).
   
   
   maui-voip-sj(config-cmap)#match access-group ?
     <1-2699>  Access list index
     name      Named Access List
   maui-voip-sj(config-cmap)#match access-group 102 
   
   
   !--- Create the access-list to match the class-map access-group:
   
   
   maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
   
   !--- The safest and easiest way is to match with UDP port range 16384-32767. !--- This is the port range Cisco IOS H.323 products utilize to transmit !--- VoIP packets.
   
   

   These access-lists are also used to match voice traffic with the match access-group command:

   access-list 102 permit udp any any precedence critical
   
   !--- This list filters traffic based on the IP packet TOS: Precedence field. !--- Note: Ensure that the other non-voice traffic does not use the !--- same precedence value.
   
   
   access-list 102 permit udp any any dscp ef
   
   !--- In order for this list to work, ensure that VoIP packets are tagged !--- with the dscp ef code before they exit on the LLQ WAN interface. !--- For more information on DSCP, refer to !--- Implementing Quality of Service Policies with DSCP. !--- Note: If endpoints are not trusted on their packet marking, !--- mark incoming traffic by applying an inbound service policy on an !--- inbound interface. This procedure is out of the scope !--- of this document. 
   
   
   access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
   
   !--- This access-list can be used in cases where the VoIP !--- devices cannot do precedence or DSCP marking and you !--- cannot determine the VoIP UDP port range.
    

   These are other matching methods that can be used instead of access-group commands:

   • With Cisco IOS Software Release 12.1.2.T and later, IP RTP Priority functionality is implemented for LLQ. This feature matches the priority class contents that look at the UDP ports configured. It is subject to the limitation of serving only even ports in the PQ.

     class-map voice
       match ip rtp 16384 16383
     

   • These two methods operate under the assumption that VoIP packets are marked at the originating hosts or matched and marked in the router before the outbound LLQ operation is applied:

     class-map voice 
        match ip precedence 5
     

     OR

     class-map voice
        match ip dscp ef
     

     Note: In Cisco IOS Software Release 12.2.2T and later, VoIP dial-peers can mark voice bearer and signaling packets prior to the LLQ operation. This allows a scalable way to mark and match VoIP packets through DSCP code values for LLQ. For more information, refer to Classifying VoIP Signaling and Media with DSCP for QoS.

     Router(config-dial-peer)#ip qos dscp ?
     

2. Create a class map for VoIP signaling and define match criteria (optional).

   Use these commands to complete this task:

   class-map voice-signaling
     match access-group 103
   !
   access-list 103 permit tcp any eq 1720 any
   access-list 103 permit tcp any any eq 1720
   

   Note: VoIP calls can be established using H.323, session initiation protocol (SIP), Media Gateway Control Protocol (MGCP) or Skinny Call Control Protocol (SCCP) - proprietary protocol used by Cisco Call Manager. The previous example assumes H.323 Fast Connect. This list serves as reference for the ports used by VoIP signaling and control channels:

   • H.323/H.225 = TCP 1720

   • H.323/H.245 = TCP 11xxx (Standard Connect)

   • H.323/H.245 = TCP 1720 (Fast Connect)

   • H.323/H.225 RAS = UDP 1718 (To GateKeeper)

   • SCCP = TCP 2000-2002 (CM Encore)

   • ICCP = TCP 8001-8002 (CM Encore)

   • MGCP = UDP 2427, TCP 2428 (CM Encore)

   • SIP= UDP 5060, TCP 5060 (configurable)

3. Create a policy map and associate it to the VoIP class maps.

   The purpose of the policy map is to define how the link resources are shared or assigned to the different map classes. Use these commands to complete this task:

   maui-voip-sj(config)#policy-map VOICE-POLICY
   
   !--- Choose a descriptive policy_map_name.
   
   
   maui-voip-sj(config-pmap)#class voice-traffic
   maui-voip-sj(config-pmap-c)#priority ?
    <8-2000000>  Kilo Bits per second
   
   !--- Configure the voice-traffic class to the strict PQ !--- (priority command) and assign the bandwidth.
   
   
   maui-voip-sj(config-pmap)#class voice-signaling
   maui-voip-sj(config-pmap-c)#bandwidth 8
   
   !--- Assign 8 Kbps to the voice-signaling class.
   
   
   maui-voip-sj(config-pmap)#class class-default
   maui-voip-sj(config-pmap-c)#fair-queue 
   
   !--- The remaining data traffic is treated as WFQ.
   
   

   Note: Although it is possible to enqueue various types of real-time traffic to the PQ, Cisco recommends that you direct only voice traffic to it. Real-time traffic, such as video, potentially introduces variation in delay (the PQ is a First In First Out (FIFO) queue). Voice traffic requires that delay be nonvariable in order to avoid jitter.

   Note: The sum of the values for priority and bandwidth statements need to be less than or equal to minCIR for the PVC. Otherwise, the service-policy command cannot be assigned to the link. minCIR is half of CIR by default. To see the error messages, ensure that the logging console command is enabled for console access and the terminal monitor command is enabled for Telnet access.

   For more information on the bandwidth and priority commands, refer to Comparing the bandwidth and priority Commands of a QoS Service Policy.

4. Enable LLQ by applying the policy map to the outbound WAN interface.

   Use these commands to enable LLQ:

   maui-voip-sj(config)#map-class frame-relay VoIPovFR
   maui-voip-sj(config-if)#service-policy output VOICE-POLICY
   
   !--- The service-policy is applied to the PVC !--- indirectly by configuring !--- it under the map-class associated to the PVC.
   
   

IP RTP Priority

If you do not use LLQ, use these guidelines:

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port  
port-range  bandwidth 

• starting-rtp-port—The starting UDP port number. The lowest port number to which the packets are sent. For VoIP, set this value to 16384.

• port-range—The range of UDP destination ports. The number, added to the starting-rtp-port, yields the highest UDP port number. For VoIP, set this value to 16383.

• bandwidth—Maximum allowed bandwidth in kbps for the priority queue. Set this number based on the number of simultaneous calls, adding each call's bandwidth per call that the system supports.

Sample configuration:

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Traffic Shaping for Voice

Use these guidelines when you configure traffic shaping for voice:

• Do not exceed the CIR of the PVC.

• Disable Frame Relay adaptive shaping.

• Set the Bc value low so Tc (shaping interval) is 10 ms (Tc = Bc/CIR). Configure the Bc value to force the desired Tc value.

• Set the Be value to 0.

For more information of these guidelines, refer to Frame Relay Traffic Shaping for VoIP and VoFR.

Note: Some customers use separate PVCs for data and voice. If you have two separate PVCs and want to burst in the data PVC while you remain at or below CIR for the voice PVC, the voice quality still suffers since these PVCs use the same physical interface. In such cases, the Frame Relay provider, as well as the router, need to prioritize the voice PVC. The latter can be done by PVC Interface Priority Queueing (PIPQ) available as of Cisco IOS Software Release 12.1(1)T.

Fragmentation (FRF.12)

Turn on fragmentation for low speed links (less than 768 kbps). Set the fragment size so that voice packets are not fragmented and do not experience a serialization delay greater than 20 ms. Set the fragmentation size based on the lowest port speed between the routers. For example, if there is a hub and spoke Frame Relay topology where the hub has a T1 speed and the remote routers have 64 K port speeds, the fragmentation size needs to be set for the 64 K speed on both routers. Any other PVCs that share the same physical interface need to configure the fragmentation to the size used by the voice PVC. Use this chart to determine the fragmentation size values.

Sample configuration:

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Note: For 1536 Kbps, no fragmentation is technically needed. However, fragmentation is needed to enable the dual FIFO queueing system to ensure voice quality. A fragment size of 1600 bytes enables the dual FIFO. However, since 1600 bytes is higher than the typical serial interface maximum transmission unit (MTU), large data packets are not fragmented.

Network Diagram

This document uses the network setup shown in this diagram:

Configurations

This document uses the configurations shown here:

• maui-voip-sj (Cisco 3640)

• maui-voip-austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- Definition of the voice signaling and traffic class maps. !--- "voice-traffic" class uses access-list 102 for its matching criteria. !--- "voice-signaling" class uses access-list 103 for its matching criteria.

class-map match-all voice-signaling
 match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!--- The policy map defines how the link resources are assigned !--- to the different map classes. In this configuration, strict PQ !--- is assigned to the voice-traffic class !--- with a maximum bandwidth of 45 Kbps.
 

policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  class voice-signaling
  bandwidth 8


!--- Assigns a queue for voice-signaling traffic that ensures 8 Kbps. !--- Note that this is optional and has nothing to do with good voice !--- quality. Instead, it is a way to secure signaling.


  class class-default
  fair-queue


!--- The class-default class is used to classify traffic that does !--- not fall into one of the defined classes. !--- The fair-queue command associates the default class WFQ queueing.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not !--- enabled, then map-class does not start and FRF.12 and LLQ does !--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class. !--- See the map-class frame-relay VoIPovFR command here: !--- Note: The word VoIPovFR is selected by the user. !

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal !--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although adaptive shaping is disabled, make CIR equal minCIR !--- as a double safety. By default minCIR is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes. !--- This value is based on the port speed of the slowest path link. !--- This command also enables dual-FIFO.

!
access-list 102 permit udp any any range 16384  32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!

!--- access-list 102 matches VoIP traffic !--- based on the UDP port range. !--- Both odd and even ports are put into the PQ. !--- access-list 103 matches VoIP signaling protocol. In this !--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
ip subnet-zero
!
class-map match-all voice-signaling
match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache 
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Verify and Troubleshoot

This section provides the information to confirm that your configuration works properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only) . This allows you to view an analysis of show command output.

LLQ / IP RTP Priority Commands

These show and debug commands help you to verify your LLQ and IP RTP priority configurations.

• show policy-map interface serial interface# —This command is useful to view the LLQ operation and any drops in the PQ. For more information on the various fields of this command, refer to Understanding Packet Counters in show policy-map interface Output.

• show policy-map policy_map_name —Displays information about the policy-map configuration.

• show queue interface-type interface-number —Lists fair queueing configuration and statistics for a particular interface.

• debug priority—Displays PQ events and shows if dropping occurs in this queue. For more information, refer to Troubleshooting Output Drops with Priority Queuing.

• show class-map class_name —Displays information about the class-map configuration.

• show call active voice—Checks for lost packets at the DSP level.

• show frame-relay ip rtp header-compression—Displays RTP header compression statistics.

Fragmentation Commands

Use these debug and show commands to verify and troubleshoot Fragmentation configurations.

• show frame-relay fragment—Displays information about the Frame Relay fragmentation that takes place in the Cisco router.

• debug frame-relay fragment—Displays event or error messages related to Frame Relay fragmentation. It is only enabled at the PVC level on the selected interface.

Frame Relay / Interface Commands

Use these show commands to verify and troubleshoot the Frame Relay/Interface configurations.

• show traffic-shape queue interface —Displays information about the elements queued at the VC data-link connection identifier (DLCI) level. Used to verify the operation of IP RTP Priority over Frame Relay. When the link is congested, voice flows are identified with a weight of zero. This indicates that the voice flow uses the PQ. See the sample output here.

• show traffic-shape—Displays information such as Tc, Bc, Be, and CIR configured values. See the sample output.

• show frame-relay pvc dlci-# —Displays information such as traffic shaping parameters, fragmentation values, and dropped packets. See the sample output. Also refer to Troubleshooting Frame Relay.

Known Issues

A bug was identified with per VC LLQ where the PQ was strictly policed even when there is no congestion on the interface. That bug has been fixed and now non-conforming voice packets are dropped only if congestion occurs on the VC. This makes the behavior of the per VC LLQ the same as other interfaces that use LLQ. This behavior was changed with Cisco IOS Software Release 12.2(3) and later.

Sample show and debug Command Output

This is sample show and debug command output used for verification and troubleshooting.

!--- To capture sections of this output, the LLQ PQ bandwidth !--- is lowered and large data traffic is placed !--- on the link to force packets drops. !--- Priority queue bandwidth is lowered to 10 Kbps to force drops from the PQ. !--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0
    
   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0

      

!--- These commands are useful to verify the LLQ configuration.
 
      
maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
   Class voice-signaling
        Weighted Fair Queueing
           Bandwidth 8 (kbps) Max Threshold 64 (packets)
   Class voice-traffic
        Weighted Fair Queueing
         Strict Priority
             Bandwidth 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
         Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic (id 3)
         Match access-group 102


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0


 Output queue size 0/max total 600/drops 0
 fragment type end-to-end fragment size 80
 cir 64000 bc 640 be 0 limit 80 interval 10
 mincir 64000 byte increment 80 BECN response no
 frags 13 bytes 962 frags delayed 8 bytes delayed 642
 
 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command !--- output, the PQ bandwidth is lowered and heavy traffic !--- is placed on the interface to force drops. 

maui-voip-sj#show frame-relay pvc 300

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         fragment type end-to-end fragment size 80
         cir 64000 bc 640 be 0 limit 80 interval 10
         mincir 64000 byte increment 80 BECN response no
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms, !--- CIR equals 64000 BPS, and BC equals 640. 

     
maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where !--- the routers are configured with IP RTP Priority instead of LLQ.
 

maui-voip-austin#show frame-relay PVC 100

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0         
  PVC create time 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:   
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0 
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


!--- This command displays information of the VoIP dial-peers.
 
      
maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated: 
     type = voip, session-target = `ipv4:192.168.10.2',  
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort, 
         acc-qos = best-effort, 
     dtmf-relay = cisco-rtp, 
        fax-rate = voice,   payload size =  20 bytes
     codec = g729r8,    payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
     VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

Related Information

• Low Latency Queueing for Frame Relay
• Classifying VoIP Signaling and Media with DSCP for QoS
• show Commands for Frame Relay Traffic Shaping
• Frame Relay IP RTP Priority
• Configuring Frame Relay and Frame Relay Traffic Shaping
• Configuring and Troubleshooting Frame Relay
• Voice over Frame Relay Queueing Enhancement
• Voice Technology Support
• Voice and IP Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support - Cisco Systems