From: OhioHondo (ohiohondo@columbus.rr.com)
Date: Thu Apr 17 2003 - 12:14:57 GMT-3
Andy
I know you asked for Brian's input but I'd like to inject something here.
FRTS is used to solve a problem, not just set parms on a pvc.
Possible problems are:
1) a mismatch between the signaling rates of two sides of a pvc
2) Oversubscription of spoke pvc's running into a hub
3) allow real time traffic to accomplish QOS objectives on a FR circuit
The information on the slide you mentioned, and many of the questions on the
FRTS subject both past and present, do not mention the problem scenario for
which FRTS is being used to fix. For example: in problem scenario# 1 above,
the "cir" value set in the router should be the lowest signaling rate
between the two routers that are the endpoints of the pvc.
In your question since Bc is set to 4000 and Tc=125 milliseconds I would
assume that:
map-class frame TEST
frame cir 32000 ----------- > normally suggested to be signaling rate
frame bc 4000 -------- > if cir above was signaling rate, change to 8000
frame be ???
The max setting for Be should be [(AR*Tc)- Bc]= 64000*.125 - 4000 = 4000
The max data sent over the pvc in 1 second is [Bc/Tc + Be]= 4K/.125 + 4K =
36K
Now I do not know what problem is trying to be solved so I do not know why
we would limit our bursting over CIR to 36K-32K or only 4K.
If the parms above were changed to cir= signaling rate, bc=cir*.125=8000
then
Be= [(AR*Tc)- Bc]= 64000*.125 - 8000 = 0.......and
The max data sent over the pvc in 1 second is [Bc/Tc + Be]= 8K/.125 + 0 =
64K
In this scenario a burst of up to 32K over the contracted CIR is allowed.
Not knowing the problem that is trying to be solved, this is a better use of
the FR circuit.
Be = 32000 when CIR = 32000, port speed = 64000, Bc = 4000
and Tc = 125ms. Are they incorrect? Shouldn't Be have been 4000?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ANDF@nnpi.com
Sent: Thursday, April 17, 2003 9:46 AM
To: brian@cyscoexpert.com; ccielab@groupstudy.com
Subject: RE: FRTS Revealed (was RE: MINCIR = CIR?)
Brian,
I appreciate your input on this. On page 66 of the 2002 CCIE Power Session
slides they show Be = 32000 when CIR = 32000, port speed = 64000, Bc = 4000
and Tc = 125ms. Are they incorrect? Shouldn't Be have been 4000?
Thanks,
Andy Fernandes
-----Original Message-----
From: Brian McGahan [mailto:brian@cyscoexpert.com]
Sent: Thursday, April 17, 2003 12:40 AM
To: 'OhioHondo'; 'Jonathan V Hays'; ccielab@groupstudy.com
Cc: 'Mike Williams'
Subject: FRTS Revealed (was RE: MINCIR = CIR?)
Due to incorrect documentation, FRTS is one of the most
misunderstood topics within the CCIE domain. Since this is my favorite
lecture which I usually end up giving 5 or 6 times per week, I'll just go
for the complete explanation to start with :)
To calculate FRTS values, we will use the following formulas:
Bc = (CIR * Tc) / 1000
Be = ((AR - CIR) * Tc)/1000
In the CCO example you are referencing, the hub has an access-rate
of 192000bps, while the remote only has an access-rate of 64000bps.
Therefore, the fastest speed that can be sustained over the second is
64000bps. This is what we want to average per second, which is Cisco's term
CIR.
Hub:
AR = 192000
CIR = 64000
Remote:
AR = 64000
CIR = 64000
Since CIR <= 640Kbps, the default Tc is 125ms. (I'll explain this
later) Now we have the following:
Hub:
AR = 192000
CIR = 64000
Tc = 125
Remote:
AR = 64000
CIR = 64000
Tc = 125
Now that we have both CIR and Tc, we can solve for Bc. Since both
the CIR and Tc are the same for the Hub and the Remote, Bc will be the same:
Bc = (CIR * Tc)/1000
Bc = (64000 * 125)/1000
Bc = (8000000)/1000
Bc = 8000 bits
Now we have:
Hub:
AR = 192000
CIR = 64000
Tc = 125
Bc = 8000
Remote:
AR = 64000
CIR = 64000
Tc = 125ms
Bc = 8000
Now we must solve for Be, starting with Hub:
Be = ((AR - CIR) * Tc)/1000
Be = ((192000 - 64000) * 125) / 1000
Be = ((128000) * 125) / 1000
Be = (16000000) / 1000
Be = 16000
Now the Remote:
Be = ((AR - CIR) * Tc)/1000
Be = ((64000 - 64000) * 125) / 1000
Be = ((0) * 125) / 1000
Be = (0) / 1000
Be = 0
So far, our calculations have nothing to do with how our line is
actually provisioned. Instead, we have simply calculated how our token
bucket will shape the traffic. The example then states "In case of
congestion, it can drop down to 32Kbps at the minimum." This statement
implies that the provider has provisioned 32000bps for us on this VC. In
order to dynamically react to congestion from the cloud, we must enable BECN
adapt, which is where the following two statements come
from:
frame-relay mincir 32000
frame-relay adaptive-shaping becn
The following statement in the document is wrong:
"Ideally for data PVCs Bc = CIR/8 so that Tc = 125msec."
There is a maximum Tc value per CIR. The greater the CIR the
smaller the Tc value must be. Unfortunately, this behavior is not
documented. In the following example, the frame-relay map-class X is
applied to an interface with one VC. We can test this behavior based on the
following:
Suppose we have a CIR of 640000. If Bc = CIR/8, then Bc = 640000/8
= 80000.
map-class frame-relay X
frame-relay cir 640000
frame-relay bc 80000
no frame-relay adaptive-shaping
end
Rack2R6#show traffic-shape
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 640000 10000 80000 0 125 10000 -
This indicates that we have 8 intervals per second (1000ms per
second, 125ms per interval), and are sending 80000 bits per interval, which
works out to an average of 640000bps. So far so good.
Now let's change our CIR to 800000bps:
Current configuration:
!
map-class frame-relay X
frame-relay cir 800000
frame-relay bc 100000
no frame-relay adaptive-shaping
end
Rack2R6#sh traffic
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 800000 6300 100000 0 63 6300 -
Notice that our interval is not 125ms now, but our Bc still conforms
to the formula Bc = CIR/8. In actuality, we have (bear with
me) 1000/63 = 15.873015873015873015873015873016 intervals per second. At
100000 bits per interval, we are averaging about 1587301bps, which is
clearly beyond 800Kbps. This is due to the fact that for a CIR of 800Kbps,
the maximum Tc value is 63ms.
Instead, let us compute Bc using 63 as the Tc:
Bc = (CIR * Tc) / 1000
Bc = (800000 * 63) / 1000
Bc = 50400
Rack2R6#sh run map-class
Building configuration...
Current configuration:
!
map-class frame-relay X
frame-relay cir 800000
frame-relay bc 50400
no frame-relay adaptive-shaping
end
Rack2R6#sh traffic-shape
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment
Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes)
Active
604 800000 6300 50400 0 63 6300 -
We still have 1000/63 = 15.873015873015873015873015873016 intervals
per second. If we are sending 50400bits every
15.873015873015873015873015873016ms, we will be averaging 800000bps.
I'm not sure exactly where the cutoff values are for the max Tc, but
the router will tell you the appropriate Tc value for a CIR if you enter it
in the map-class, apply it, then show traffic-shape.
Hope I didn't confuse you all further :)
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866-CyscoXP
Outside US: 847.674.3392
Fax: 847.674.2625
> -----Original Message-----
> From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> Sent: Wednesday, April 16, 2003 10:08 PM
> To: Jonathan V Hays; 'Brian McGahan'; ccielab@groupstudy.com
> Cc: 'Mike Williams'
> Subject: RE: MINCIR = CIR?
>
> This new equation/explanation for calculating FRTS parameter -- I've
never
> seen it before. It doesn't make sense with anything I've read on the
> subject. How does it relate to the CCO iformation found at:
>
>
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
xa
> mp
> le09186a00800942f8.shtml
>
> where:
> Bc=CIR*Tc
> Be= (AR*Tc) - Bc
>
> Where is the source of your information?
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Jonathan V Hays
> Sent: Wednesday, April 16, 2003 9:00 PM
> To: 'Brian McGahan'; ccielab@groupstudy.com
> Cc: 'Mike Williams'
> Subject: RE: MINCIR = CIR?
>
>
> > -----Original Message-----
> > From: Brian McGahan [mailto:brian@cyscoexpert.com]
> > Sent: Wednesday, April 16, 2003 1:33 PM
> > To: 'Jonathan V Hays'; ccielab@groupstudy.com
> > Cc: 'Mike Williams'
> > Subject: RE: MINCIR = CIR?
> >
> [snip]
> > The following formulas hold true for Cisco's implementation of
> > Frame-Relay Traffic Shaping:
> >
> > Bc = (CIR * Tc)/1000
> > Be = ((AR - CIR) * Tc)/1000
> >
>
> Brian,
>
> What units are you using to require division by 1000? Most Cisco
> documents seem to give Bc= CIR * Tc.
>
>
http://www.cisco.com/en/US/tech/tk713/tk237/technologies_configuration_e
> xample09186a00800942f8.shtml
>
> See the document I cited in my earlier post (included above) under
> "Nonconfigurable parameters - interval (Tc)" -
> ---
> "The time interval during which you send the Bc bits in order to
> maintain the average rate of the CIR in seconds.
>
> Tc = Bc/CIR in seconds.
>
> The range for Tc is between 10 ms and 125 ms."
> ---
> In the example given in the Cisco document, Bc is 8000 bits, CIR is
> 64000 bps, then Tc = 8000 bits / 64000 bps = 1/8 second.
>
> Or if you use Bc = CIR * Tc, then
> Bc = 64000 bps * 1/8 second = 8000 bits.
>
> What does dividing by 1000 get me?
>
> Thanks.
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:35:56 GMT-3