Applied traffic shaping causing severe latency

[ronfitz1]

Hi all,

I hope someone can help me out. I'm trying to set up QoS for VoiP over Frame Relay and I'm running into a problem. My customer has a link speed of 1536 which is split across 14 PVC's. I'm trying to do QoS on 2 of them out to remote sites. Below is the main site and the remotes look similar. The problem is that every time I apply "frame-relay traffic-shaping" command to the serial0/0/0 interface, the entire frame network comes to a crawl. Is there something I'm missing?

Thank you.

class-map match-all voice-signaling
match access-group 103
class-map match-any Voice
match access-group 102
!
!
policy-map Voice-Policy
class voice-signaling
bandwidth percent 5
class Voice
priority percent 60
class class-default
fair-queue

map-class frame-relay VOIPovFR
frame-relay cir 192000
frame-relay bc 19200
frame-relay be 0
frame-relay mincir 192000
service-policy output Voice-Policy
!
map-class frame-relay VoiPovFR
access-list 102 permit udp any any range 2048 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720

interface Serial0/0/0
description Primary T1
bandwidth 1544
no ip address
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
no fair-queue
frame-relay traffic-shaping
frame-relay lmi-type cisco

interface Serial0/0/0.430 point-to-point
ip address 10.x.x.1 255.255.255.252
no arp frame-relay
frame-relay interface-dlci 430
class VOIPovFR
frame-relay ip rtp header-compression

 

[plshlpme]

you will want to add the framerelay fragment statement to your map class...

frame-relay fragment 240

the fragment is typically set to the number if timeslots x 80..

the latency is caused due to the serialization of the packets.. the amount of time taken to put the packet onto the line. when the packet is fragmented into smaller chunks it can be transmitted quicker...

cehck out

http://www.rhyshaden.com/frame.htm#frts

specifically: FRF.12 Frame Relay Fragmentation