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=22095&t=21991
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
