Again, I have never done traffic shaping with voice. However, here are some guidelines from a WAN technologies presentation at Networkers 2000. I don't have a URL for it or softcopy of the slides - it was on the web prior to Networkers 2001 but I think it's probably been removed now.
Scenario: Central site has 2 Mbps line speed (we're in Australia, not the US, but I'm sure the same guidelines apply to T1 :-) Multiple remote sites - remote site used in example has line speed of 128 kbps, CIR 64 kbps. Traffic shaping for data only: At remote site: 1. set CIR to match line speed, so CIR=128k 2. Leave Tc at default=125ms, therefore don't set Bc 3. Set MINCIR to network 'real' CIR value, so MINCIR=64k 4. Don't set Be, default=0 At Central site: 1. Set CIR to match remote line speed, so CIR=128k 2. Leave Tc at default=125ms, therefore don't set Bc 3. Set MINCIR to network 'real' CIR value, so MINCIR=64k 4. Don't set Be, default=0 Traffic shaping for data and VoIP: At remote site: 1. set CIR to match 'real' CIR, so CIR=64k 2. Set Tc to smallest value=10ms, therefore Bc=640 3. Set MINCIR to match 'real' CIR value, MINCIR=64k, or alternatively disable adaptive shaping 4. Don't set Be, default=0 At Central site: Match remote site. The example configs for data and VoIP also include frame relay fragmentation. Hope that helps. JMcL ----- Forwarded by Jenny Mcleod/NSO/CSDA on 05/10/2001 09:03 am ----- "Lange, Eric" cc: Sent by: Subject: RE: Traffic Shaping [7:21991] nobody@groups tudy.com 05/10/2001 05:24 am Please respond to "Lange, Eric" John, Most of the traffic shaping I have done is with data only. T1 to 56k for example. The rules may be very different (and I'm sure they are) while doing VoIP. Traffic shaping a T1 to a 56K is pretty strait foreword. I try and follow the 1/8th rule when configuring my bc value. I also always configure my CIR to available bandwidth (not true CIR) and mincir to what is the "true CIR". map-class frame-relay 56k no frame-relay adaptive-shaping frame-relay cir 56000 frame-relay bc 8000 frame-relay be 0 frame-relay mincir 28000 This rule seems to work great until you traffic shape a T1 pvc. The Cisco algorithm seems to break while applying the 1/8th rule to bc. I have been advised, please correct me if I am wrong, that the bc value should never exceed 80000. If you are shaping T1 PVC (T1 to T1) your map class should look like the following. map-class frame-relay T1 no frame-relay adaptive-shaping frame-relay cir 1536000 frame-relay bc 80000 frame-relay be 0 frame-relay mincir 768000 To verify this after applying these map class changes do a 'sh traffic' and verify the math. Take your interval value (given in ms) and invert it (1 / interval time in ms). This will give you the amount of intervals per second. Multiply this number by Sustain bits/interval. This should be close to the Cisco CIR value plus or minus a little bit. Here is an example: c3640A#sh traffic Interface Se1/0.101 Access Target Byte Sustain Excess Interval Increment Adapt VC List Rate Limit bits/int bits/int (ms) (bytes) Active 101 56000 875 7000 0 125 875 - 1/.125 * 7000 = 56000 (Your target rate) This is what has worked for me in the past. You may want to do adaptive shaping, but probably not with voice. Hope this helps. If someone can add additional insight to FRTS with VoIP please help. Thanks, -Eric -----Original Message----- From: John Neiberger [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 12:05 PM To: [EMAIL PROTECTED] Subject: RE: Traffic Shaping [7:21991] Here is a portion of one of the configs. For some reason, whenever I turn on FRTS my telnet sessions get *really* jumpy. Sometimes it almost seems the router locks up but I think it's just my telnet session. If I turn off FRTS on the main interface that jumpiness goes away. In this particular case I haven't applied the VoIP class to all PVCs and I'm wondering if that might cause a problem. We have two other locations that we're testing VoIP with and they have a direct PVC between them. VoIP calls between them sounds fine. When we shutdown that PVC and then route the traffic through the location whose config I'm including, the call quality is beyond horrid. Demons gargling acid in Hell probably sound better than this. :-) Any thoughts? Thanks, John class-map match-any voicecalls match ip precedence 4 class-map match-all VoIP-Control match access-group name VoIP-Control ! ! policy-map voice class voicecalls priority 192 class VoIP-Control bandwidth 8 class class-default fair-queue interface Serial0/0 encapsulation frame-relay no ip mroute-cache no fair-queue frame-relay traffic-shaping ! interface Serial0/0.16 point-to-point ip address 10.12.11.75 255.255.255.0 no ip mroute-cache frame-relay interface-dlci 16 ! interface Serial0/0.18 point-to-point ip address 10.12.24.70 255.255.255.0 frame-relay interface-dlci 18 class VoIP ! interface Serial0/0.23 point-to-point ip address 10.12.26.70 255.255.255.0 no ip mroute-cache frame-relay interface-dlci 23 class VoIP ! map-class frame-relay VoIP no frame-relay adaptive-shaping frame-relay cir 256000 frame-relay bc 2560 frame-relay be 0 frame-relay mincir 256000 service-policy output voice >>> "[EMAIL PROTECTED]" 10/4/01 10:25:25 AM >>> Can you send the config? I have been spending allot of time doing traffic shaping and may be able to lend some insight if I see the config. -Eric -----Original Message----- From: John Neiberger [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 04, 2001 10:07 AM To: [EMAIL PROTECTED] Subject: Re: Traffic Shaping [7:21991] I've had odd results implementing FRTS, as well. I've been told by a Cisco engineer that it helps to reload the router after applying or changing FRTS commands. I don't know if it's necessary but he said it makes things work a little better. I haven't noticed a difference but perhaps it's worth a try. John >>> "Thomas N." 10/3/01 10:11:15 PM >>> Hi All, I implemeted the Traffic Shaping using map-class and assigned to subinterfaces. The PVCs sharing that physical interfaces however increase in reply time and eventually timeout. What did I do wrong? When I tried General Traffic Shaping, it worked with "traffic-shape rate" and "traffic-shape adaptive" commands. The reason I would like to implement Traffic Shaping with map-class because I would like to apply "Frame-Relay fragmentation" into some PVC to reduce delay time... Any idea why Traffic Shaping with map-class timeouts my PVCs? Thanks All! Thomas N. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=22134&t=21991 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]