Re: rate-limit

On Tue, 25 Mar 2003 19:59:34 +0200 (EET), "Adrian Racasan" <[email protected]>
said:
> 
> In primul rand, vreau sa incep cu recomandarea mea CLARA: foloseste
> policy-map-uri, class-mapuri si, mai ales instructiunea police in loc de
> rate-limit, intr-un cuvant cbwfq.

aha si astea sunt pe input sau output sau si si???

> 
> Acum cu rate-limiturile ce se  intampla:
> 
> Tu trebuie sa garantezi 1000000kbps (average rate). Ai normal burst-ul de
> 100000, asta inseamna ca daca iti vin in 1/10 secunde pana in 100000bps
> totul este in regula, intra in vigoare conform-action si pachetele sunt
> transmise. Daca iti vin in aceasta cuanta de timp mai mult de 1000000bps,
> se imprumuta din urmatoarele normal-bursturi pana la alti 100000bps
> (adica
> valoarea max-burst-ului). Ce e exceeded si peste asta, e dropuit.
> * 1/10 vine de la average 1 / (rate/ bc ) = bc/rate  , ca sa iasa in
> secunde.

deci ne imaginam un grafic cu debit pe verticala si timpul pe orizontala,
am trafic de 2m.
consideram toate valorile in biti
am rata la 1m, nb=100k, mb=200k
am rata de 1m, apoi in urm 1/10 sec, urca cu inca 100k, apoi urca cu inca
200k, deci a ajuns la 1300k, ramane la 1300k sau scade la 1m???

> Daca il pui prea mare, s-ar putea chiar sa ai surpriza sa nu iti dea
> mir-ul dorit, ci mai mult... S-ar putea sa nu am eu destul "skill", dar e
> cam empirica treaba (te pot ajuta daca imi spui ce vrei sa garantezi cu
> un
> friendly advice).

pai problema este asa: 
CE - SW - BB, linkurile sunt 100 sau 1000, se doreste simularea catre CE
a unui link de 256k up si 1024k down, se ignora latentele dintr-un link
real (adsl), si as dori sa fac acest lucru pe switch direct pe portul
catre CE. Vad ca rate-limit stie switchul, si chiar merge :)) dar am
probleme in parametrizare.

> 
> Partea buna - priveste bc si be ca niste potentiometre de reglat loss si
> bandwidth. Scopul e sa duci lossul la 0, si asta din doua motive, pentru
> ca loss sux pentru aplicatiile client, si pentru ca pierzi banda spre
> upstream providerul tau, fiecare pachet dropuit trecand totusi prin sarma
> ta, deci poti privi lossul ca bandwidth irosit (daca intelegi asta, well,
> o sa incepi sa urasti dc++ si download accelerator-urile like I do).

dar ordinea prioritatilor este limitarea benzi la x bits +-y%, realizarea
cat mai la marginea retelei, si apoi un loss cat mai mic in reteaua ta.
Oricum eu am trafic numai in interiorul retelei, cel exterior este
nesemnificativ :))

> 
> A doua parte buna - nu iti creste latenta extrem pe circuitele
> suprasolicitate - ca si in cazul shaperelor (in cisco policy-map ->
> class-map -> shape average etc etc - sunt foarte bune si shaperele,
> merita
> folosite).

care sunt pe in pe out???

C
---
Send e-mail to [email protected] with subject "unsubscribe cisco" 
(without quotes) to unsubscribe from this list.