RE: [nsp] CBWFQ On frame relay Interfaces

From: Goodwin, Dustin T [IT] (dustin.t.goodwin@ssmb.com)
Date: Fri Aug 17 2001 - 10:20:37 EDT


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