This document discusses traffic shaping and prioritization for a Voice over IP (VoIP) over Frame Relay network with hub and spoke topology. The configuration of the hub is such that there are two permanent virtual circuits (PVCs), one for each remote spoke, and both data and voice are sent over the same PVCs. It is important to note that the prioritization and fragmentation discussed in this document applies not only to this scenario but also to a scenario where you may have one PVC with voice and data and another with only data. The data PVCs need to be traffic-shaped just as the voice and data PVCs. This is due to the fact that when a single physical pipe is shared, in this case at the hub, the serialization delay affects all data.
In the topology below, New York represents the hub central router. Raleigh and San Jose represent remote routers connected to the hub through a Frame Relay network. There are two PVCs that connect to the New York router. In this case, New York should never send more than 64 kbps to Raleigh and likewise, it should never send more than 192 kbps to San Jose because this exceeds the configured Committed Information Rate (CIR) on the Frame Relay mapclass.
In the topology shown in this document, the routers with VoIP configurations are directly connected to a Frame Relay cloud. In some topologies, however, the voice-enabled routers can exist anywhere in the network, with the exception of the Cisco AS5300. For more information on this, refer to the note provided. The voice routers can be connected through LAN connectivity to other routers that are connected to the WAN. This is important to note because if your voice routers are not directly connected to a Frame Relay service, all WAN connectivity configuration commands are configured on those routers that are connected to the WAN, and not on the voice routers.
Note: Cisco AS5300 routers with high-speed serial interfaces are not designed to support data connection to a WAN. You need to use your Cisco AS5300s as intermediate LAN routers with the main functionality to process voice calls. You need dedicated routers to act as direct connections to the WAN.
Before you attempt this configuration, ensure that you meet these prerequisites:
Basic understanding and configuration of Frame Relay Traffic Shaping (FRTS)
Basic understanding and configuration of VoIP
The information in this document is based on these software and hardware versions:
Three Cisco 3640 routers with Cisco IOS® Software Release 12.3(5) Enterprise Plus
Four analog phones connected to Foreign Exchange Station (FXS) ports on spokes
One PBX connected to a T1 controller on the hub router
The spokes can also be a Cisco 2600 or a 1750 platform. The hub can be a Cisco 2600 or 3600 platform in the case of digital voice, but it can also be a Cisco 1750 platform if only analog voice exists at the hub. All traffic shaping and configurations apply to other platforms as well.
Note: Though this document is not restricted to specific software, some of the commands used here are not available with all Cisco IOS Software versions. For example, the frame-relay fragment command is supported with IP Plus but not by an IP image.
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
When you run VoIP over Frame Relay, it is important that the traffic sent over the frame stays at a level that is less than or equal to the Frame Relay CIR. The router does not send traffic that exceeds the CIR when configured with Frame Relay Traffic Shaping (FRTS) as shown. If you configure the router to run at a speed greater than the CIR , you may experience voice quality issues, and voice quality is not guaranteed when you run PVCs above the guaranteed CIR.
Note: It is possible to configure adaptive shaping to enable a router to throttle down the transmission rate to a specified value if Frame Relay packets are received with the backward explicit congestion notification (BECN) bit set. You are advised however, that traffic rates are not to exceed the CIR of the Frame Relay service when voice packets are transmitted. This is to ensure proper quality and delivery when real time voice packets are sent across the network. The configuration where the CIR is exceeded is only recommended for data PVCs that do not carry voice traffic.
Note: Also, before you can configure your router to use VoIP, it is best if you understand the Quality of Service (QoS) features in Cisco IOS Software. To learn more about QoS features, refer to Queuing, Traffic Shaping, and Filtering and Fragmentation for Voice.
This document uses the network setup shown in the diagram here:
This document uses these configurations:
|New York Hub Router|
Current configuration: ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname newyork ! logging buffered 50000 debugging enable secret < password > [Choose a strong password with at least one capital letter, one number, and one special character.] ! controller T1 2/0 framing esf linecode b8zs ds0-group 1 timeslots 1-4 type e&m-wink-start ! ! interface Serial2/0 no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping !--- This CLI command enables traffic shaping for both PVCs. ! interface Serial2/0.1 point-to-point description Connection to Raleigh PVC ip address 172.16.120.2 255.255.255.0 frame-relay interface-dlci 100 class class-raleigh ! interface Serial2/0.2 point-to-point description Connection to San Jose PVC ip address 172.16.130.2 255.255.255.0 frame-relay interface-dlci 200 class class-sanjose ! ip classless ! map-class frame-relay class-raleigh frame-relay cir 64000 frame-relay bc 640 frame-relay be 0 frame-relay mincir 64000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 80 !--- Recommended fragment size for 10ms delay when carrying voice !--- traffic based on the configured CIR 64000. !--- based on the configured CIR 64000 frame-relay ip rtp priority 16384 16383 48 !--- Two calls with g729, no CRTP, at 24 kbps/each. ! map-class frame-relay class-sanjose frame-relay cir 192000 frame-relay bc 1920 frame-relay be 0 frame-relay mincir 192000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 240 !--- This is the recommended fragment size for 10ms delay when carrying voice traffic !--- based on the configured CIR 192000. frame-relay ip rtp priority 16384 16383 48 !--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach. ! ! voice-port 2/0:1 ! dial-peer cor custom ! dial-peer voice 100 pots !--- Calls to the Public Switched Telephone Network (PSTN). destination-pattern 212....... prefix 212 port 2/0:1 ! dial-peer voice 200 pots !--- Calls to the corporate network-four digit extension forwarded. destination-pattern 567.... port 2/0:1 ! dial-peer voice 110 voip !--- Calls to Raleigh. destination-pattern 919392.... session target ipv4:172.16.120.1 ip qos dscp cs5 media dtmf-relay h245-alphanumeric ! dial-peer voice 210 voip !--- Calls to San Jose. destination-pattern 408527.... session target ipv4:172.16.130.1 ip qos dscp cs5 media dtmf-relay h245-alphanumeric ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 no login ! end
The frame-relay ip rtp priority command reserves a strict priority queue for a set of Real-Time Protocol (RTP) packet flows that belongs to a range of User Datagram Protocol (UDP) destination ports.
Note: Because the frame-relay ip rtp priority command gives absolute priority over other traffic, use this command with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all of the excess traffic is dropped.
|Cisco 3640 Raleigh|
Current configuration: ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname raleigh3640a ! logging buffered 50000 debugging enable secret < password > [Choose a strong password with at least one capital letter, one number, and one special character.] ! no ip subnet-zero ! ! ! ! voice-port 1/0/0 ! voice-port 1/0/1 dial-peer voice 1 pots destination-pattern 9193924100 port 1/0/0 ! dial-peer voice 2 voip destination-pattern 2126789001 ip qos dscp cs5 media dtmf-relay h245-alphanumeric session target ipv4: 172.16.120.2 ! interface Loopback0 ip address 172.16.125.1 255.255.255.255 no ip directed-broadcast ! interface Serial2/0 no ip address encapsulation frame-relay frame-relay traffic-shaping ! interface Serial2/0.1 point-to-point description Connection to New York ip address 172.16.120.1 255.255.255.0 frame-relay interface-dlci 100 class fr_class_voip ! ! ip classless no ip http server ! ! map-class frame-relay fr_class_voip frame-relay cir 64000 frame-relay bc 640 frame-relay be 0 frame-relay mincir 64000 no frame-relay adaptive-shaping frame-relay fair-queue frame-relay fragment 80 !--- The recommended fragment size for 10ms delay when carrying voice traffic. !--- based on the configured CIR 64000. frame-relay ip rtp priority 16384 16383 48 ! ! line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 no login ! end
This section provides information you can use to confirm your configuration works.
show frame-relay fragment —Displays information about the Frame Relay fragmentation that takes place on the Cisco router.
show traffic-shape queue —Displays information about the elements queued at the virtual circuit (VC) data-link connection identifier (DLCI) level. This command is 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 is using the priority queue. Refer to the sample output provided.
show frame-relay pvc [dlci#]—Displays information such as traffic shaping parameters, fragmentation values, and dropped packets. Refer to the sample output provided here and also refer to Comprehensive Guide to Configuring and Troubleshooting Frame Relay for further information.
newyork#show frame-relay fragment interface dlci frag-type frag-size in-frag out-frag dropped-frag Serial1/0.1 100 end-to-end 80 16 20 0 Serial1/0.2 200 end-to-end 240 12 10 0 newyork#show traffic-shape serial 2/0.1 Interface Se2/0.1 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 100 64000 80 640 0 10 80 -
newyork#show traffic-shape queue Traffic queued in shaping queue on Serial2/0.1 dlci 100 Queueing strategy: weighted fair Queueing Stats: 0/600/64/0 (size/max total/threshold/drops) Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 16 kilobits/sec Traffic queued in shaping queue on Serial2/0.2 dlci 200 Queueing strategy: weighted fair Queueing Stats: 0/600/64/0 (size/max total/threshold/drops) Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 144 kilobits/sec newyork#show frame-relay pvc 100 PVC Statistics for interface Serial2/0 (Frame Relay DCE) DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1
input pkts 1078 output pkts 1078 in bytes 157792 out bytes 172284 dropped pkts 0 in pkts dropped 0 out pkts dropped 0 out bytes dropped 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 28 out bcast bytes 8498 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 00:27:48, last time pvc status changed 00:27:48 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 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 IF_CONG no frags 2707 bytes 172284 frags delayed 2707 bytes delayed 172284 shaping inactive traffic shaping drops 0 ip rtp priority parameters 16384 32767 48000
This section provides information you can use to troubleshoot your configuration.
Here is troubleshooting information and instructions relevant to this configuration:
Troubleshoot the Frame Relay and QoS implemented for voice and ensure its correct operation.
Proceed to voice call failure troubleshooting as necessary.
Note: For more detailed troubleshooting information, refer to VoIP over Frame Relay with QoS (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority).
Note: Refer to Important Information on Debug Commands before you use debug commands.
debug priority —Displays priority queueing (PQ) events and shows if a drop occurs in this queue. For more information, refer to Troubleshooting Output Drops with Priority Queuing.
debug frame-relay fragment —Displays event or error messages related to Frame Relay fragmentation. This command is only enabled at the PVC level on the selected interface.
newyork#debug priority Priority output queueing debugging is on newyork#ping 172.16.120.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms newyork# *Mar 1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2) *Mar 1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) *Mar 1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2) *Mar 1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) *Mar 1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) *Mar 1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) newyork#debug frame-relay fragment interface serial 2/0 100 This may severely impact network performance. You are advised to enable no logging console debug. Continue?[confirm] Frame Relay fragment/packet debugging is on Displaying fragments/packets on interface Serial2/0 dlci 100 only *Mar 1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, B bit set, frag_hdr 03 B1 9C 3D *Mar 1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, E bit set, frag_hdr 03 B1 5C 3E *Mar 1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, exp_seq-num 17,B bit set, frag_hdr 03 B1 80 11 *Mar 1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, exp_seq-num 18,E bit set, frag_hdr 03 B1 40 12
- show Commands for Frame Relay Traffic Shaping
- Frame Relay IP RTP Priority
- Configuring and Troubleshooting Frame Relay
- Frame Relay Traffic Shaping for VoIP and VoFR
- Voice Technology Support
- Voice and Unified Communications Product Support
- Troubleshooting Cisco IP Telephony
- Technical Support & Documentation - Cisco Systems
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.