From: Eric Rogers (Eric.Rogers@xxxxxxxxxxxxx)
Date: Sun Jun 02 2002 - 00:06:54 GMT-3
There was this thread a couple of weeks ago....
-Eric
Subject: Re: Generic Traffic Shaping - Fatkid Lab #461 / FRTS
> Correction & Apologies(my answer was incorrect)... but this is what I
found
> in the archives, It has come from Patrick @ cisco systems. It seems to
make
> more sense when you read thru it...
>
> ----Pat's original mail----
> This should help!
>
> Terminology:
>
> Tc = Bc/Cir ! time interval (the internalized version of Tc where the
> time interval can't exceed 125ms)
>
> CIR = Average rate you want to send out (This is generally not the
> same as the CIR you get from your provider unless you aren't
> allowed to send above CIR) This is measured in bits/second.
> Bc = Amount of data to send per each Tc interval. This is
> measured in bits.
> (this also gets internalized and real amount of data sent per
> interval is expressed in bytes by the "increment" variable).
> Be = Amount of excess data allowed to be sent during first
> interval once credit is built up. Also measured in bits.
>
> Mincir = Minimum amount of data to be sent during periods of congestion.
> This defaults to half of CIR.
>
> Interval = Bc/CIR with the maximum size being 125ms.
>
> byte increment = Bc/8 . Must be > 125. Upper side has no bound
> or limitation except if interval is locked at 125ms.
>
> limit = byte increment + Be/8 (measured in bytes)
>
> --------------------------------------------------------------------
>
> OK let me throw some numbers in which may help explain this better.
>
> Let's say you have a frame relay link with following parameters:
>
> Physical port speed 64KB
> CIR = 16KB (In this case I mean CIR your provider has guarenteed
> you in their network)
>
> Now let's say your provider has told you that you can send data on your
PVC
> up to port speed as long as there is no congestion in their network but
that
> when there is congestion they will only guarantee you CIR on your PVC.
>
> Here is what you should configure on the router:
>
> encap frame-relay
> ip address 10.10.10.1 255.255.255.0
> frame-relay traffic-shaping
> frame-relay map ip 10.10.10.2 200 broadcast
> frame-relay interface-dlci 200
> class 64KB
>
> //snip//
>
> Nick
> map-class frame-relay 64KB
> frame-relay cir 64000 ! This is rate you want to normally send at
> when
> there is no congestion
> frame-relay bc 8000 ! This is amount you will send per interval.
> rule of thumb is to make it 1/8 CIR
> frame-relay be 0 ! This is extra amount to send in first
> interval. In this case you are already
> sending at port speed so this should be 0.
> frame-relay mincir 16000 ! This is what you will slow down to during
> congestion. This should be set to your
true
> CIR that your provider has guarenteed you
> when
> there is congestion in their network
>
> *Note that BECN Response(ie dropping down when receiving BECNs) is
> enabled by default in 11.2
>
> Now here are a couple of other numbers that are used in traffic shaping:
>
> Tc= Bc/CIR where Tc is the measurement interval. This value should
> be no larger than 1/8 second for good shaping to take
affect.
>
> So in above example Tc = 8K/64K = 1/8 second
>
> So basically here is what you would see transmitted in 1/8 second
intervals:
>
> 8000(Bc+Be), 8000(Bc), 8000, 8000, 8000, 8000, 8000, 8000
>
> which equals 64000bits/second.
>
> Now if you actually had a 128KB port speed but you left all numbers the
same
> except you changed Be = 64000 then here is what you would see.
>
> 72000, 8000, 8000, 8000 ....
>
> You would keep sending at Bc(8000) until you had an idle interval or only
a
> partially used interval and you built up credit again. The maximum credit
> you
> can build up is Be.
>
>
> -----Original Message-----
> From: Bezverkhi, Serguei <Serguei.Bezverkhi@hp.com>
> To: Michael Kilpatrick <mjkilpat@yahoo.com>
> Cc: ccielab@groupstudy.com <ccielab@groupstudy.com>
> Date: Monday, 13 May 2002 1:43
> Subject: RE: Generic Traffic Shaping - Fatkid Lab #461
>
>
> >Hello,
> >
> >I think this should meet the requirements
> >
> >traffic-shape group 101 16000 2000 14000
> >
> >16000 it is CIR, so we guarantee 16kb
> >2000 it is Bc, just number of bit sent
> >14000 it is Be, so it can burst up to 30kbps but no more, and even after
> >30kb burst it will be able to send 16kbps.
> >
> >What do you think about this calculations??
> >
> >Serguei
> >
> >-----Original Message-----
> >From: Michael Kilpatrick [mailto:mjkilpat@yahoo.com]
> >Sent: May 12, 2002 8:43 PM
> >To: ccielab@groupstudy.com
> >Subject: Generic Traffic Shaping - Fatkid Lab #461
> >
> >
> >In Fatkid Lab #461, can someone please verify the given solution for
> >item #5.
> >
> >Item #5 says:
> >5. Configure R3 so that users on the Token Ring segment get at least 16K
> >of bandwidth, but not more than 32K, for their telnet traffic, and the
> >remaining bandwidth for everything else.
> >
> >And the given solution is:
> >interface Serial0
> > traffic-shape group 101 16000 32000 32000 1000
> >access-list 101 permit tcp any any eq telnet
> >
> >Please correct me if I am wrong, but it seems to me that this does
> >nothing to guarantee users get at least 16K of bandwidth. In addition,
> >this traffic-shape command would allow bursts up to the 64k access-rate
> >and would apply a tc interval of 2 seconds which would be very
> >inefficient.
> >
> >I think the solution should read:
> >interface Serial 0
> > custom-queue-list 1
> > traffic-shape group 101 32000 4000 0
> >access-list 101 permit tcp any any eq telnet
> >queue-list 1 protocol ip 1 tcp telnet
> >queue-list 1 default 2
> >queue-list 1 queue 1 byte-count 100
> >queue-list 1 queue 2 byte-count 300
> >
> >Can someone please verify?
> >Thanks alot! Mike
Eric
----- Original Message -----
From: "Bryan Ginman" <ginmanb@westnet.com>
To: <ccielab@groupstudy.com>
Sent: Saturday, June 01, 2002 7:36 PM
Subject: Custom Queueing
> I seem to remember a very good post a while back explaining how to do
custom queueing with average byte counts and figuring the byte count into
the average. The Archive database is down so I am unable to do a search for
it.I am interested in the following:
> How would I set up my queues if I wanted to give DLSW 50% avg byte count
980. IPX 25% with a average byte count of 128 and say IP 25% with a avg byte
count of 768. I am not looking for the command queue-list x queue x byte
count command but how I would figure the avg byte counts into determining
queue size.
>
> Cheers,
>
> Bryan
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:20 GMT-3