Frame relay tc question

[bellocarico]

Reading on frame relay I can see that the time interval is for most of the providers 1/8 sec, which is 125 ms.

I'm trying a couple of configs on my lab I'm running into the following dilemma.

Please seethe config below:

interface Serial0

bandwidth 1544

no ip address

encapsulation frame-relay

no fair-queue

no arp frame-relay

frame-relay traffic-shaping

no frame-relay inverse-arp

!

interface Serial0.1 multipoint

ip address 192.168.0.1 255.255.255.252

frame-relay class SLOW

frame-relay map ip 192.168.0.2 501

!

interface Serial0.2 point-to-point

ip address 192.168.0.5 255.255.255.252

frame-relay class FAST

frame-relay interface-dlci 502

!

map-class frame-relay SLOW

frame-relay adaptive-shaping becn

frame-relay cir 28800

frame-relay bc 3600

frame-relay be 200

frame-relay mincir 24400

!

map-class frame-relay FAST

frame-relay adaptive-shaping becn

frame-relay cir 2048000

frame-relay bc 256000

frame-relay be 44000

frame-relay mincir 1544000

now... when I verify doing a show traffic-shape I get this:

Interface Se0.1

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

501 28800 475 3600 200 125 450 BECN

Interface Se0.2

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

502 2048000 13500 256000 44000 32 8192 -

Why has the time interval changed to 32ms in serial 0.2?

Should't have staid set to 125ms (1/8 second)?

Also, what does the Increment (bytes) rapresent exacplty?

Thanks to read!

[pkhatri · Accepted solution]

Q: Why has the time interval changed to 32ms in serial 0.2?

IOS will allow the following maximum values of Tc depending on the configured CIR:

o For CIR <= 640007 bps, Tc = 125ms

o For 640000 < CIR <= 1280007 bps, Tc = 63ms

o For CIR > 1280007 bps, Tc = 32ms

If you happen to configure a CIR and Bc that results in a Tc that is less than the maximum allowed for that CIR, IOS will accept it as long as it is greater than the minimum allowed Tc of 10ms. If the calculated Tc happens to be greater than the maximum from above, IOS will force it to be that maximum value. In your case, since CIR=2048000, the max Tc you can use is 32ms. And that is why you see that.

Q: Also, what does the Increment (bytes) rapresent exacplty?

The Increment(bytes) is the number of bytes that will be sent in each Tc interval. In your first example, the increment is 450 bytes, which is 3600 bits, which matches your Bc.

For the second case, it is 8192 bytes = 65536 bytes, which is worked out as 2048000 * 0.032 = 65536.

Pls do remember to rate posts...

Paresh

[bellocarico]

Thanks for that! It really helps.

I just miss one thing...

When you say:

If you happen to configure a CIR and Bc that results in a Tc that is less than the maximum allowed for that CIR, IOS will accept it as long as it is greater than the minimum allowed Tc of 10ms. If the calculated Tc happens to be greater than the maximum from above, IOS will force it to be that maximum value.

I've tried (inside the map-class)

frame-relay tc 15 (ms)

which is less than 32 and more than 10, but the output of the sh traffic-shape it's still the same:

Interface Se0.2

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

502 2048000 8750 65536 4464 32 8192 -

You see? Interval (ms) = 32

Everything else it's clear, I just miss this point.

[pkhatri]

Hi again,

The 'frame-relay tc' command is useful only when using frame-relay policing and not shaping.

To test what I indicated in my post, use the following config:

map-class frame-relay class1

frame-relay cir 128000

frame-relay bc 1000

According to the calculation for Tc, the above parameters should result in a Tc of 1000/128000 = 7.8 ms. However, when you do a 'show frame-relay pvc' command, you will see that the interval will be set to 10ms. That is what I meant.

Pls do remember to rate the post if it helps.

Regards,

Paresh