Understood.
Inquiring QoS minds want to know...
Do you, or anyone else, know of any detrimental effects to having
mis-matched Tc on opposite ends of a circuit? i.e. a 75xx with 4ms at the
hub and 10ms on 26xx/36xx at the spokes? If no detriment, will there still
be a benefit to running it this way? or would a network have to have a 75xx
on both ends to see an improvement in jitter reduction?
Thanks,
Ken W
-----Original Message-----
From: Goodwin, Dustin T [IT] [mailto:dustin.t.goodwin@ssmb.com]
Sent: Friday, August 17, 2001 10:21 AM
To: 'Wortendyke, Ken'
Cc: cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
Just to clarify the console log was from 3660 not a 7500.
- Dustin -
-----Original Message-----
From: Wortendyke, Ken [mailto:KWortendyke@Timebridge.com]
Sent: Friday, August 17, 2001 10:17 AM
To: Goodwin, Dustin T [IT]; Wortendyke, Ken
Cc: cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
Thanks for the info. I thought 10ms was the floor when it came to Bc.
Ken W
-----Original Message-----
From: Goodwin, Dustin T [IT] [mailto:dustin.t.goodwin@ssmb.com]
Sent: Friday, August 17, 2001 10:10 AM
To: 'Wortendyke, Ken'
Cc: cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
-----Original Message-----
>From: Wortendyke, Ken [mailto:KWortendyke@Timebridge.com]
>Subject: RE: [nsp] CBWFQ On frame relay Interfaces
>
>
>really?! how did you find that out?
>That'll impact the design of QoS configs a bit if you want both ends to use
>10ms - which is a good thing for VoIP at least.
On the 36xx platform it will not allow you to configure BC value smaller
then this. Of course it will not produce an error, it will just not set it.
Notice console log below. 10ms is good, 4ms is better. The smaller the TC
the smaller the jitter when the shape is active. On 7500 with distributed
shaping a developer at Cisco confirmed that the min value for TC is 4ms even
thought with modular QOS cli you can not display TC at this time. Cisco
always keeping it interesting.
For instance given a BC of 3840 on 384bps link the calculation TC would
10ms.
map-class frame-relay frmap-384
no frame-relay adaptive-shaping
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
service-policy output qos-hoot1
frame-relay fragment 640
r3640lab2#show fram pvc 500
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 500, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
<SNIP>
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 640
cir 384000 bc 3840 be 0 limit 480 interval 10
mincir 192000 byte increment 480 BECN response no
frags 479270 bytes 58038522 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
So now I will set BC for a TC of 4ms
.004 * 384000 = 1536
r3640lab2(config)#map-class frame-relay frmap-384
r3640lab2(config-map-class)#frame bc 1536
r3640lab2(config-map-class)#^Z
r3640lab2#show frame pvc 500
1w0d: %SYS-5-CONFIG_I: Configured from console by console
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 500, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
<SNIP>
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 640
cir 384000 bc 3840 be 0 limit 480 interval 10
mincir 192000 byte increment 480 BECN response no
frags 479432 bytes 58058222 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Notice the bc and the interval(tc) have not changed. I can set it higher but
not lower. See the difference in BC and interval when I increase it 20ms.
r3640lab2(config)#map-class frame-relay frmap-384
r3640lab2(config-map-class)#frame bc 7680
r3640lab2(config-map-class)#^Z
r3640lab2#show frame pvc 500
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 500, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
Output queue size 0/max total 600/drops 0
fragment type end-to-end fragment size 640
cir 384000 bc 7680 be 0 limit 960 interval 20
mincir 192000 byte increment 960 BECN response no
frags 479498 bytes 58066274 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
- Dustin -
-----Original Message-----
From: Wortendyke, Ken [mailto:KWortendyke@Timebridge.com]
Sent: Thursday, August 16, 2001 12:48 PM
To: Goodwin, Dustin T [IT]
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
really?! how did you find that out?
That'll impact the design of QoS configs a bit if you want both ends to use
10ms - which is a good thing for VoIP at least.
Ken W
-----Original Message-----
From: Goodwin, Dustin T [IT] [mailto:dustin.t.goodwin@ssmb.com]
Sent: Thursday, August 16, 2001 11:25 AM
To: 'Wortendyke, Ken'; cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
More annoying to me is that the minimum TC value for shaping is 4ms on 7500
distributed and 10ms on the 36xx/26xx platforms.
- Dustin -
-----Original Message-----
From: Wortendyke, Ken [mailto:KWortendyke@Timebridge.com]
Sent: Thursday, August 16, 2001 11:19 AM
To: Goodwin, Dustin T [IT]; cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
It's because the good folks over at Cisco cooked up DTS - Distributed
Traffic Shaping for the 7500, where the rest of the platforms can use the
traditional GTS/FRTS mechanisms. Why they are actually implemented
differently at the CLI is a mystery to me as well.
This link does a decent job of showing the config procedure for DTS:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121
t/121t5/dtdts.htm
Ken W
-----Original Message-----
From: Goodwin, Dustin T [IT] [mailto:dustin.t.goodwin@ssmb.com]
Sent: Thursday, August 16, 2001 10:33 AM
To: cisco-nsp@puck.nether.net
Subject: RE: [nsp] CBWFQ On frame relay Interfaces
Glad you asked, I had the same question several months ago.
12.1(5)T and 12.2(1-3) this is supported see example configuration below.
The config is different depending on the platform, don't ask me why it just
is.
- Dustin -
**** On 7500 with nbma interface
class-map match-all voicegws
match access-group name voicegws
class-map match-all matchhoot
match ip precedence 5
!
!
policy-map qos-hoot1
class matchhoot
priority 80
class class-default
fair-queue
random-detect
policy-map shaper-512
class class-default
shape average 512000 2048 0
service-policy qos-hoot1
policy-map shaper-192
class class-default
shape average 192000 768 0
service-policy qos-hoot1
policy-map shaper-384
class class-default
shape average 384000 1536 0
service-policy qos-hoot1
interface Hssi5/1/0
ip address 10.253.1.1 255.255.255.0
ip pim nbma-mode
ip pim sparse-mode
encapsulation frame-relay
ip mroute-cache distributed
load-interval 30
hssi internal-clock
frame-relay interface-dlci 502
class frmap-384
frame-relay interface-dlci 503
class frmap-192
frame-relay interface-dlci 504
class frmap-512
no frame-relay broadcast-queue
frame-relay ip rtp header-compression
!
map-class frame-relay frmap-384
no frame-relay adaptive-shaping
service-policy output shaper-384
frame-relay fragment 640
!
map-class frame-relay frmap-192
no frame-relay adaptive-shaping
service-policy output shaper-192
frame-relay fragment 320
!
map-class frame-relay frmap-512
no frame-relay adaptive-shaping
service-policy output shaper-512
frame-relay fragment 960
******** On 36xx or 26xx with subinterface per pvc.
class-map match-all matchhoot
match ip precedence 5
match ip dscp 46
!
!
policy-map qos-hoot1
class matchhoot
priority 80
class class-default
fair-queue
random-detect
interface Serial0/0
no ip address
encapsulation frame-relay
load-interval 30
clockrate 512000
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
bandwidth 384
ip address 10.253.1.2 255.255.255.0
ip pim sparse-mode
frame-relay class frmap-test
frame-relay interface-dlci 500
frame-relay ip rtp header-compression
!
map-class frame-relay frmap-384
no frame-relay adaptive-shaping
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
service-policy output qos-hoot1
frame-relay fragment 640
!
map-class frame-relay frmap-192
no frame-relay adaptive-shaping
frame-relay cir 192000
frame-relay bc 2304
frame-relay be 0
service-policy output qos-hoot1
frame-relay fragment 320
!
map-class frame-relay frmap-512
no frame-relay adaptive-shaping
frame-relay cir 512000
frame-relay bc 6144
frame-relay be 0
service-policy output qos-hoot1
frame-relay fragment 960
-----Original Message-----
From: Edward S. Desouza [mailto:edward_desouza@yahoo.com]
Sent: Thursday, August 16, 2001 1:16 AM
To: cisco-nsp@puck.nether.net
Subject: [nsp] CBWFQ On frame relay Interfaces
Hi,
I have a frame Relay PVC of 16 k CIR. My access
links at both end are E1. I need to configure class
based weighted fair queueing on this interface.
Class Based Weighted fair queuing allows a
percentage of bandwdith to be configured per traffic
class. However, Since my access link is much higher
than the PVC, My router will keep on pumping data into
the FR network since the access speed is much higher
than the PVC.
A solution to the above would be to confiugre FRTS.
However, FRTS does not support CBWFQ !
Have any of you guys run into a similar problem
where you need to do a class based queuing on a frame
relay PVC ? I dont want to use multiple PVC's for
multiple classes of traffic.
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:49 EDT