RE: FRTS Default Bc value

> In terms of the Be, if you don't configure the Bc value (only CIR), the IOS
it will always default to Be = CIR/8, but that's not the ideal value when
configuring shaping for high speed interface especially with voip. Is that a
correct statement?

It would not be ideal for *low* speed interfaces. When you're shaping on
interfaces of about T1/E1 or less, the inter-packet delay of the shaper
becomes an issue for low latency applications like VoIP. To fix this you need
to set the Tc to a low value - typically 10ms - by adjusting the Bc value, and
you may also need to configure fragmentation if your Byte Increment (basically
the Bc as expressed in Bytes) is lower than the MTU of the link.

The defaults that IOS uses depends if you're using legacy shaping or MQC/HFQ
based shaping. There's really no reason why you would want to use the legacy
unless you had really really old IOS code, or within the scope of the lab exam
if they specifically told you not to use MQC.

HTH,

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
http://www.INE.com

From: Tom Kacprzynski [mailto:tom.kac_at_gmail.com]
Sent: Sunday, April 01, 2012 10:56 PM
To: Brian McGahan
Cc: Cisco certification
Subject: Re: FRTS Default Bc value

Hello Brian,
Thank you very much for your quick response. The cosmetic bug does bring my
sanity back :)

So just so I'm clear. The "show frame-relay pvc xxx" command will display the
incorrect values in the Bc field, but will show it correctly in the byte
increment field? Is that the field I can rely on using that command? The same
cosmetic bug will be displayed with the "show traffic-shape" when looking
under the Sustained bits/int field, correct?

In terms of the Be, if you don't configure the Bc value (only CIR), the IOS it
will always default to Be = CIR/8, but that's not the ideal value when
configuring shaping for high speed interface especially with voip. Is that a
correct statement?

Basically, my other question relates to the default value that IOS sets. This
default value does not change with higher interface speed, but should be
configured manually differently. Is that also a correct statement?

Thank you

Tom

On Sun, Apr 1, 2012 at 10:07 PM, Brian McGahan
<bmcgahan_at_ine.com<mailto:bmcgahan_at_ine.com>> wrote:
Hi Tom,

This is a cosmetic bug in legacy FRTS. If you apply the same policy in MQC
you'll see the correct Bc value reflected. Also the Bc isn't always the
CIR/8. As the CIR goes up the router needs more intervals per second in order
for the shaper to achieve the desired rate. For low speed CIR values you will
see that Bc = CIR/8, but as CIR goes up this is not true. What would be more
accurate would be to say that the CIR in Bits / Second = Bc in Bits / Tc
milliseconds, or in other words that Bc = CIR/1000 * Tc, since Bc is expressed
in milliseconds as opposed to seconds. This formula always stays true as the
CIR goes up or down, or if you manually change the Bc.

HTH,

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
http://www.INE.com

-----Original Message-----
From: nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>
[mailto:nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>] On Behalf Of Tom
Kacprzynski
Sent: Sunday, April 01, 2012 9:51 PM
To: Cisco certification
Subject: FRTS Default Bc value

Hello,
I ran into an output of a FRTS show command that contradicts what I know so
far and figure ask the experts to see where is the disconnect.

Based on what I know and the Enterprise QoS SRND, the Bc value by default
should be set to Bc= CIR/8.
If I configure traffic shaping on an FR interface I see that bc on my DCLI
205 is set to 7000 bits (which is correct) :

Rack1R2#sh frame-relay pvc 205

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 205, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0

 input pkts 275289 output pkts 125138 in bytes 20715768
 out bytes 12816805 dropped pkts 0 in pkts dropped 0
 out pkts dropped 0 out bytes dropped 0
 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
 out BECN pkts 0 in DE pkts 0 out DE pkts 0
 out bcast pkts 13544 out bcast bytes 1013448
 5 minute input rate 1000 bits/sec, 1 packets/sec
 5 minute output rate 1000 bits/sec, 1 packets/sec
 pvc create time 2d10h, last time pvc status changed 00:01:48
 cir 56000 * bc 7000 * be 0 byte limit 875 interval 125
<-------------------bc 7000
 mincir 28000 byte increment 875 Adaptive Shaping none
 pkts 135 bytes 15363 pkts delayed 0 bytes delayed 0
 shaping inactive
 traffic shaping drops 0
 Queueing strategy: fifo
 Output queue 0/40, 0 drop, 0 dequeued

Now if I apply a map-class with cir of 256,000 I don't see what I would
expect, which is the Bc to be set to 32,000 but rather the Bc is set to
256,000. This does not make much sense to me especially that when I look at
show traffic-shape the Tc is still set to .125sec.

map-class frame-relay FRTS
 frame-relay cir 256000

interface Serial0/0/0
 ip address 136.1.245.2 255.255.255.0
 encapsulation frame-relay
 no fair-queue
 frame-relay class FRTS
 frame-relay traffic-shaping
 frame-relay map ip 136.1.245.5 205<tel:136.1.245.5%20205> broadcast no
frame-relay inverse-arp end

Rack1R2#sh frame-relay pvc 205

PVC Statistics for interface Serial0/0/0 (Frame Relay DTE)

DLCI = 205, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/0

 input pkts 107 output pkts 0 in bytes 9918
 out bytes 0 dropped pkts 0 in pkts dropped 0
 out pkts dropped 0 out bytes dropped 0
 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
 out BECN pkts 0 in DE pkts 0 out DE pkts 0
 out bcast pkts 0 out bcast bytes 0
 5 minute input rate 1000 bits/sec, 1 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 pvc create time 00:01:04, last time pvc status changed 00:01:04
 cir 256000 *bc 256000* be 0 byte limit 4000 interval 125
<<--------------bc 256,000
 mincir 128000 byte increment 4000 Adaptive Shaping none
 pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
 shaping inactive
 traffic shaping drops 0
 Queueing strategy: fifo
 Output queue 0/40, 0 drop, 0 dequeued

Does anyone have any idea where the disconnect is?

Thank you,

Tom

Blogs and organic groups at http://www.ccie.net
Received on Mon Apr 02 2012 - 10:36:58 ART