From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Fri Aug 13 2004 - 01:57:34 GMT-3
Carlos,
I looked at the earlier e-mails in this thread and I can see
that you were talking with Brian McGahan about how many Tc's you should
burst to AR for. The proper answer is only one Tc. Although
theoretically you could have a scenario that asks to burst to AR for
more than one Tc, this would release more data to the interface than the
router could physically send out. In turn this excess data would be
queued up in the router's interface output queues.
One of the goals of FRTS is to never have packets queued up in
the router's interface queues or in a Frame Relay switch's queues. The
only queue that should have packets being queued up in is the FRTS queue
itself. So for a proper FRTS implementation, FRTS should never release
more data then can be sent by the router's interface or the Frame Relay
switches.
The Frame Relay switch queue issue should only, theoretically,
occur when there is a disparity in the interface speeds between two
routers. Example: A router with a T1 (1536kbps) bursts to port speed
for 1/8 of a second (125ms). This means the router sent 192000 bits in
125ms. If the remote router has a factional T1 (256kbps), it will only
be able to receive 32000 bits in that same 125ms time frame. This would
leave 160000 bits that need to be queued up in the Frame Relay cloud.
It will take an additional five Tc's or 625ms until the Frame Relay
cloud could send all the data to the remote router. This is where the
problem occurs. If after the router burst to AR for one Tc and then
VoIP data needed to be sent, the VoIP data would end up being held in
the FIFO queue of the Frame Relay switch. This would mean that the VoIP
data would need to wait in the Frame Relay switches FIFO queue until the
data from the original burst was emptied (roughly 600ms).
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian Dennis
Sent: Thursday, August 12, 2004 8:21 PM
To: Carlos G Mendioroz
Cc: Brian McGahan; Georg Pauwen; ccielab@groupstudy.com
Subject: RE: IEWB Lab1 - 9.6 - Be calculation
<Quote>
I'm asking why you first state that Be is not limited by AR * Tc and
then go with AR - CIR * Tc as the solution
</Quote>
Are you sure that I said this? Were you speaking with Brian McGahan
possibly?
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: Thursday, August 12, 2004 6:19 PM
To: Brian Dennis
Cc: Brian McGahan; Georg Pauwen; ccielab@groupstudy.com
Subject: Re: IEWB Lab1 - 9.6 - Be calculation
Brian,
we are drifting towards nonsense...
-I'm not talking about configuring wrongly CIR over AR.
I've labbed already that if you configure a huge Be, the router will
send at AR for as long as it can (i.e. as long as credit is available).
-I'm asking why you first state that Be is not limited by AR * Tc and
then go with AR - CIR * Tc as the solution
Following the thread, I get the impression that I've been clear in my
point and answers are not on the spot, so to say...
Brian Dennis wrote:
> Carlos,
> It would be a foolish implementation of the shutdown command to
> let you shutdown an interface that you are telneted in on, but it'll
let
> you. That is the beauty of the IOS. Right or wrong, you have power
to
> do what ever you want.
>
> FRTS does not have any idea as to what the AR is. Be it foolish
> or not, if you have 128k circuit but configure FRTS for a 512k
circuit,
> the router is not going to stop you. The router is just going to drop
> packets if FRTS releases more than can be sent out the interface. If
> you have doubts, try it out on a router.
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> bdennis@internetworkexpert.com
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
>
>
> -----Original Message-----
> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
> Sent: Thursday, August 12, 2004 4:12 PM
> To: Brian Dennis
> Cc: Brian McGahan; Georg Pauwen; ccielab@groupstudy.com
> Subject: Re: IEWB Lab1 - 9.6 - Be calculation
>
> Brian,
> that would be foolish of the implementation, and Cisco routers do not
do
>
> that. If you put a very large Be, routers will transmit @ AR for as
long
>
> as credit remains.
>
> My point is that there is no enough data in that requirement to
> configure only one answer (ok) but somehow the solution implies that
you
>
> should use the AR-CIR * Tc formula after (as I read the comment)
> disqualifying the grounds for it.
>
> Arggg
> I'm trapped in a pickiness state I don't like at all :-(
>
> Brian Dennis wrote:
>
>>Carlos,
>> Technically FRTS send as many bits per second as you would like
>>irrelevant of AR. Of course the interface will start dropping excess
>>packets outbound once AR is exceeded and the output buffers are full.
>>
>>Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
>>bdennis@internetworkexpert.com
>>Internetwork Expert, Inc.
>>http://www.InternetworkExpert.com
>>Toll Free: 877-224-8987
>>Direct: 775-745-6404 (Outside the US and Canada)
>>
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>
> Of
>
>>Carlos G Mendioroz
>>Sent: Thursday, August 12, 2004 3:33 PM
>>To: Brian McGahan
>>Cc: Georg Pauwen; ccielab@groupstudy.com
>>Subject: Re: IEWB Lab1 - 9.6 - Be calculation
>>
>>Is it ? If that were the case, you would never run out of excess
>
> credit.
>
>>Here is my understanding:
>>Be is a maximum credit (in bits) that you can gain by transmiting
>
> below
>
>>CIR. If you have credit, you would be able to transmit over CIR (up to
>
>
>>AR) using credits as long as credits remain.
>>
>>Tc is the lapse where calculations are made. Basically you receive Bc
>>credits each Tc...
>>
>>Am I wrong ?
>>
>>Brian McGahan wrote:
>>
>>
>>>The burst value, whether committed or excess, is always on a per
>>>interval basis.
>>>
>>>Brian McGahan, CCIE #8593
>>>bmcgahan@internetworkexpert.com
>>>
>>>Internetwork Expert, Inc.
>>>http://www.InternetworkExpert.com
>>>Toll Free: 877-224-8987 x 705
>>>Outside US: 775-826-4344 x 705
>>>24/7 Support: http://forum.internetworkexpert.com
>>>Live Chat: http://www.internetworkexpert.com/chat/
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>>>>Sent: Thursday, August 12, 2004 5:07 PM
>>>>To: Brian McGahan
>>>>Cc: Georg Pauwen; ccielab@groupstudy.com
>>>>Subject: Re: IEWB Lab1 - 9.6 - Be calculation
>>>>
>>>>Brian,
>>>>the lab asks for allowing busrsting up to AR but it does not say for
>>>
>>>how
>>>
>>>
>>>
>>>>much time...
>>>>So the default of 0 is wrong, but it seems to me that anything over
>>>>AR-CIR * Tc should be right. The solution guide is not clear about
>>>
>>>that...
>>>
>>>
>>>
>>>>Brian McGahan wrote:
>>>>
>>>>
>>>>
>>>>>By "There is no default Be value" it means the default is zero.
>>>>>
>>>>>Brian McGahan, CCIE #8593
>>>>>bmcgahan@internetworkexpert.com
>>>>>
>>>>>Internetwork Expert, Inc.
>>>>>http://www.InternetworkExpert.com
>>>>>Toll Free: 877-224-8987 x 705
>>>>>Outside US: 775-826-4344 x 705
>>>>>24/7 Support: http://forum.internetworkexpert.com
>>>>>Live Chat: http://www.internetworkexpert.com/chat/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>
> Behalf
>
>>>>>Of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Georg Pauwen
>>>>>>Sent: Wednesday, August 11, 2004 7:09 AM
>>>>>>To: tron@huapi.ba.ar; ccielab@groupstudy.com
>>>>>>Subject: RE: IEWB Lab1 - 9.6 - Be calculation
>>>>>>
>>>>>>Hello Carlos,
>>>>>>
>>>>>>AFAIK there is no default for the Be. Check this explanation from
>>>>>>Internetworkexpert:
>>>>>>
>>>>>>The amount of Be credits is derived from unused Bc credits in
>>>>>
>>>previous
>>>
>>>
>>>
>>>>>>intervals. There is no limit to how long Be can store unused Bc
>>>>>
>>>>>credits.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It
>>>>>>is a common misconception that Be can only store credits from the
>>>>>
>>>>>previous
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>interval or the previous second.
>>>>>>There is no default Be value.
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>Georg
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>From: Carlos G Mendioroz <tron@huapi.ba.ar>
>>>>>>>Reply-To: Carlos G Mendioroz <tron@huapi.ba.ar>
>>>>>>>To: Group Study <ccielab@groupstudy.com>
>>>>>>>Subject: IEWB Lab1 - 9.6 - Be calculation
>>>>>>>Date: Wed, 11 Aug 2004 08:43:32 -0300
>>>>>>>
>>>>>>>Requirement ask for setting traffic shapping given AR/CIR/minCIR
>>>>>>
>>>>>using
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>BECN
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"backof" (adaptive shapping).
>>>>>>>
>>>>>>>The sol guide indicates that it is a missconception that Be is to
>>>>>>
>>>be
>>>
>>>
>>>
>>>>>>>applied in only one Tc, but then go with a formula for
calculating
>>>>>>
>>>it
>>>
>>>
>>>
>>>>>>(Be)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>that is based in that...
>>>>>>>
>>>>>>>Is there a cisco source that would imply that (AR - CIR) * Tc
>>>>>>
>>>should
>>>
>>>
>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>used if no other data is available ?
>>>>>>>
>>>>>>>--
>>>>>>>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>>>>>>>
>>>>>>
>>>>>___________________________________________________________________
_
>
> _
>
>>_
>>
>>
>>>_
>>>
>>>
>>>
>>>>>>>Please help support GroupStudy by purchasing your study materials
>>>>>>
>>>>>from:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>http://shop.groupstudy.com
>>>>>>>
>>>>>>>Subscription information may be found at:
>>>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>>
>>>>>>_________________________________________________________________
>>>>>>MSN Search, le moteur de recherche qui pense comme vous !
>>>>>>http://search.msn.fr/worldwide.asp
>>>>>>
>>>>>>
>>>>>
>>>>>
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:42 GMT-3