Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Some of you may have caught this over on groupstudy where I posted last week. I thought it would be nice to share it here on CCIE Journey as well. We all know that in FRTS the formula that is always supposed to hold true is this:

Tc = Bc / CIR

With this simple formula we can calculate everything we need to know, and all the math works out…according to every book and Cisco doc I have ever read. What they don’t tell you about are the limitations of the traffic-shaping. For instance…

R2(config-map-class)#do sh run int s0/1/0 | i frame-relay
encapsulation frame-relay
frame-relay class foo
frame-relay traffic-shaping
frame-relay map ip 100.100.100.5 205 broadcast
no frame-relay inverse-arp

R2(config-map-class)#do sh run | beg map-class
map-class frame-relay foo
frame-relay cir 768000
frame-relay bc 80007

With this setup, I expect the long standing formula Tc = Bc / CIR to hold true. Therefore Tc should be equal to 80007 / 768000 = 0.10417578125 seconds = 104ms rounded down and indeed it is

R2(config-map-class)#do sh traffic

Interface  Se0/1/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
205 768000 10000Â 80007 0 104 9984 –

However, as soon as I cross the Bc boundary of 80007 and set it to 80008 my Tc is changed to what appears to be (Bc / CIR) / 2 !!! WTF?

R2(config-map-class)#do sh traffic

Interface Se0/1/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
205 768000 5000 80008 0 52 4992 –

As you can see the Tc has been set to 52 ms which just so happens to be 1/2 of the previous value of 104. As it turns out, it appears there is a limit in the IOS that only allows you to have up to a 10,000 Byte Limit. The byte-limit is the number of bytes you can send per Tc. So if we send 80007 bits per Tc (The Bc) we send 80007 / 8 bytes = 10000.87500 bytes which IOS will round down to 10,000 bytes. The minute we change Bc to 80008 the formula for how Tc is calculated is dynamically changed.

Tc = Bc / CIR. Tc = 80008 / 768000 SHOULD give us a Tc of 104ms but it doesn’t. It gives us a Tc of 52ms (exactly half). Why? 80008 / 8 = 10001 Byte limit. Apparently if you cross a 10,000 byte limit the formula for calculating Tc changes. Nice huh?

One other note: Try manipulating Bc or CIR sometime to give yourself a Tc of 250ms. You won’t be able to : ) It seems the IOS maxes out at a Tc of 249ms. If you try to go higher it will just make the Tc 125ms.

Comments

2 Responses to “FRTS Can Be A Lying Whore”

  1. CCIE Journey on December 4th, 2009 4:08 pm

    How about that scoring rumor going around that you need to have the whole section right now to get the points? No partial credit for a whole section would be insanity…

  2. Joe on December 4th, 2009 10:57 pm

    Yeah — It does seem to be the case that the entire topic is now worth a set number of points and there are no subtasks within a section. For instance, you might just have “OSPF” now instead of “OSPF” and then 4 tasks on it. However, from all accounts so far it seems each main task is not worth a huge amount of points (maybe 2-5 points or so each section) so it is not like if you fail one subtask you fail the exam.

    The rule that you need 80% on config still holds true so I don’t think it is that bad or different than before.

Leave a Reply