---

Hej!

Er der nogle, som ved hvilke scheduling algoritmer og/eller AQM, der
understøttes på billige (cpe) routere, som f.eks. Cisco 1600 og lign.?
Med algoritmer mener jeg f.eks. DRR, RED mv.

En henvisning ville være fint!

Venlig hilsen
Mikkel

---

Mikkel wrote:
> Hej!
>
> Er der nogle, som ved hvilke scheduling algoritmer og/eller AQM, der
> understøttes på billige (cpe) routere, som f.eks. Cisco 1600 og lign.?
> Med algoritmer mener jeg f.eks. DRR, RED mv.
>
> En henvisning ville være fint!
>
> Venlig hilsen
> Mikkel

Hej Mikkel

Der er nogle forudsætninger for at routerne kan understøtte RED og WRED;
1) mere RAM f.eks. 64 MB (2621)
2) mere flash RAM 8 helst 16 MB (2621)
3) IOS 12.0-12.2 (den kræver en vis mængde RAM og flash)

RED er også set kaldet Random Early Discard.

Kig på:

12.0: Configuring Weighted Random Early Detection:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart3/qcwred.htm

12.1: Configuring Weighted Random Early Detection:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt3/qcdwred.htm
Citat: "...
The WRED feature is supported on the following Cisco router platforms:
* Cisco 1600 series
* Cisco 2500 series
* Cisco 3600 series
..."

Understøttes sikkert af flere platforme i 12.2:

12.2: Configuring Weighted Random Early Detection:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt3/qcfwred.htm

Understøttes af mange platforme i 12.4:

12.4: WRED - [med] Explicit Congestion Notification (ECN):
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part15/ch05/hwrdecn.htm
Supported Platforms:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part15/ch05/hwrdecn.htm#wp1015343

-

Jeg formoder at du med DRR mener WRR (Weigted Round Robin).

WRR er interessant hvis man har flere (udgående) hardware pakkekøer. WRR
fordeler den udgående båndbredde i f.eks. 10, 20, 20, 50% ved 4
hardwarekøer.

Eksempelvis har 1600, 2600 kun én indgående og én udgående hardwarekø
per interface/netkortgrænseflade. Det er muligt, at man kan lave en
højprioriteret kø. Men der understøttes såvidt jeg ved ikke WRR.

mvh

Glenn

---

Glenn Møller-Holst <no_email_address@xx.dk> writes:

> Mikkel wrote:
>> Hej!
>> Er der nogle, som ved hvilke scheduling algoritmer og/eller AQM, der
>> understøttes på billige (cpe) routere, som f.eks. Cisco 1600 og
>> lign.? Med algoritmer mener jeg f.eks. DRR, RED mv.
>
> Jeg formoder at du med DRR mener WRR (Weigted Round Robin).

Så vidt jeg husker står DRR for Deficit Round Robin. Om det så i
praksis er det sammen som WRR, kan jeg ikke huske.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

> Så vidt jeg husker står DRR for Deficit Round Robin.
Jep.

> Om det så i
> praksis er det sammen som WRR, kan jeg ikke huske.

Det er det ikke. DRR fungerer med et deficit samt quantum pr. kø, for at
fordele mere fair. (Byte niveau fremfor pakkeniveau) Check evt. wikipedia.

(Jeg skal selvfølgelig ikke kunne sige, om Ciscos implementation af WRR
i virkeligheden er en DRR, men det tror jeg nu ikke, eftersom de vistnok
understøtter DRR på de store routere.)

Venlig hilsen
Mikkel

---

Glenn Møller-Holst wrote:

[...]
Tak for info. Det var ikke alt sammen, der faldt inden for mit
spørgsmål, men tak alligevel.

> Jeg formoder at du med DRR mener WRR (Weigted Round Robin).
Næh, det gjorde jeg ikke, men det er ikke så vigtigt i denne her
sammenhæng. Jeg prøver blot at danne mig et billede over funktionalitet
i low-end routere.

>
> WRR er interessant hvis man har flere (udgående) hardware pakkekøer. WRR
> fordeler den udgående båndbredde i f.eks. 10, 20, 20, 50% ved 4
> hardwarekøer.

Så vidt jeg kan se understøttes WRR ikke på de små routere (f.eks. 800
series), er det korrekt?

Venlig hilsen
Mikkel

---

On Wed, 12 Apr 2006 09:49:12 +0200, Mikkel <mhn@FJERNMIG.onbeat.dk>
wrote:

> Så vidt jeg kan se understøttes WRR ikke på de små routere (f.eks.
> 800 series), er det korrekt?

Jo, man kan godt opnå simpel WRR ved tildeling af båndbredde til de
forskellige klasser. (Det er software forwarding platforme, så det er
ikke fysiske køer, der skal scheduleres).

Man kan dog også lave det mere avanceret, og fx konfigurere tail drop
eller WRED per klasse, police eller shape per klasse, lade en klasse
køre som priority (EF) etc.

Se mere i QoS Configuration Guide: http://tinyurl.com/mhwyk

-A

---

On Tue, 11 Apr 2006 11:38:39 +0200, Mikkel <mhn@FJERNMIG.onbeat.dk>
wrote:

> Er der nogle, som ved hvilke scheduling algoritmer og/eller AQM, der
> understøttes på billige (cpe) routere, som f.eks. Cisco 1600 og lign.?
> Med algoritmer mener jeg f.eks. DRR, RED mv.

De små Cisco-routere er jo software forwarding engines, så features
afhænger primært af, hvilken software de kører. I dag kan de lave PQ,
CQ, WFQ, CBWFQ, og LLQ. 'Ingen' bruger PQ og CQ længere, så enten
kører folk default (ren WFQ) eller laver CBWFQ eller LLQ.

For congestion avoidance understøtter routerne WRED, og desuden kan de
shape'e og police'e.

Hvilke software-version, der kan hvad, kan man udforske med Feature
Navigator: www.cisco.com/go/fn

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:

>> Er der nogle, som ved hvilke scheduling algoritmer og/eller AQM, der
>> understøttes på billige (cpe) routere, som f.eks. Cisco 1600 og lign.?
>> Med algoritmer mener jeg f.eks. DRR, RED mv.
>
>De små Cisco-routere er jo software forwarding engines, så features
>afhænger primært af, hvilken software de kører. I dag kan de lave PQ,
>CQ, WFQ, CBWFQ, og LLQ. 'Ingen' bruger PQ og CQ længere, så enten
>kører folk default (ren WFQ) eller laver CBWFQ eller LLQ.

Heh. Det ligner en konkurrence i hvem der kan skrive flest akronymer
på kortest tid. I øvrigt synes jeg at QoS er møgbesværligt fordi det
er forskelligt på stort set enhver platform. Mere eller mindre. Og så
er der jo forskel på switch QoS og router QoS. Ellers ville det jo
være for let.

--
Lars Kim Lund
http://www.net-faq.dk/

---

On Tue, 11 Apr 2006 22:55:51 +0200, Lars Kim Lund <lkl@fabel.dk>
wrote:

> I øvrigt synes jeg at QoS er møgbesværligt fordi det er forskelligt
> på stort set enhver platform.

Nej, det er stort set ens på routerne, mens det er forskelligt fra
routere til switche og fra switch til switch, fordi de er hardware-
forwading platforme (altså switchene), og der simpelthen er forskel
på, hvad hardwaren kan.

Når det er sagt, kunne jeg da også godt tænke mig, at de designede
hardwaren lidt mere ens mht. QoS. Jeg kan fx rigtig godt lide C4K-
måden at konfigurere det på, men ikke det faktum, at det er en shared
buffer arkitektur, og fire køer er lidt lidt.

Well, det skal som du er inde på ikke være alt for let.

-A
--
Heroes: Vint Cerf & Bob Kahn, Leonard Kleinrock, Robert Metcalfe, Jon Postel
Links : http://www.hojmark.net/
FAQ : http://www.net-faq.dk/

---

Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:

>> I øvrigt synes jeg at QoS er møgbesværligt fordi det er forskelligt
>> på stort set enhver platform.
>
>Nej, det er stort set ens på routerne,

Ja, okay - når vi taler rigtige routere. Ikke bare layer3 switche. Det
er lidt skægt, på den ene side er det jo mere eller mindre det samme,
på den anden side er der store forskelle i hvordan man gør ting og
hvad softwaren kan. Hardwareunderstøttelse kontra software, jeg ved
det. Men som stakkels slutbruger er det fanme ikke let.

Og med det sagt, så er der vel også forskel i hvilke nye features der
understøttes alt efter generation af router.

>mens det er forskelligt fra
>routere til switche og fra switch til switch, fordi de er hardware-
>forwading platforme (altså switchene), og der simpelthen er forskel
>på, hvad hardwaren kan.

Ja, det er rigtig skægt. Så og så mange køer til ditten, så og så
mange priority køer, forskellige antal thresholds per kø og jeg skal
komme efter dig. Komplet umuligt.

>Når det er sagt, kunne jeg da også godt tænke mig, at de designede
>hardwaren lidt mere ens mht. QoS. Jeg kan fx rigtig godt lide C4K-
>måden at konfigurere det på, men ikke det faktum, at det er en shared
>buffer arkitektur, og fire køer er lidt lidt.

Jeg kunne godt tænke mig de standardiserede det. De kunne jo starte
med at lave HQF overalt

>Well, det skal som du er inde på ikke være alt for let.

Ja, så netværksnørder som dig skal jo også leve. Jeg er i øvrigt
kommet til den konklusion at jeg ikke orker at sætte mig mere ind i
QoS end at jeg kan formulere nogle krav til en konsulent.

Bortset fra HQF - det synes jeg faktisk ser lidt interessant ud - og
næsten gennemskueligt.

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund <lkl@fabel.dk> writes:

> Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>
>>> I øvrigt synes jeg at QoS er møgbesværligt fordi det er forskelligt
>>> på stort set enhver platform.
>>
>>Nej, det er stort set ens på routerne,
>
> Ja, okay - når vi taler rigtige routere. Ikke bare layer3 switche. Det
> er lidt skægt, på den ene side er det jo mere eller mindre det samme,
> på den anden side er der store forskelle i hvordan man gør ting og
> hvad softwaren kan. Hardwareunderstøttelse kontra software, jeg ved
> det. Men som stakkels slutbruger er det fanme ikke let.

Heh. Som tidl. udvikler af Layer-2/3 switche så kender jeg
problematikken alt for godt. Ballade nr. 1 er at leverandørerne
typisk ikke vil betale for et rigt QoS featuresæt, og at de er uenige
om hvad de gerne vil have. Og hvor mange køer man har behov for. Alt
sammen noget som koster - også for dem som ikke skal bruge det.

Når det hele laves i HW (og der er man nødt til med en GbE switch/
router) og det skal koste nada, ja, så skæres der en forfærdelig masse
hjørner.

>>Når det er sagt, kunne jeg da også godt tænke mig, at de designede
>>hardwaren lidt mere ens mht. QoS. Jeg kan fx rigtig godt lide C4K-
>>måden at konfigurere det på, men ikke det faktum, at det er en shared
>>buffer arkitektur, og fire køer er lidt lidt.

Har du nogensinde brugt mere end 4 køer til noget (fornuftigt)?

> Bortset fra HQF - det synes jeg faktisk ser lidt interessant ud - og
> næsten gennemskueligt.

Line-rate shaping/policing burde være til at kunne gennemskue


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

---

Kai Harrekilde-Petersen <khp@harrekilde.dk> wrote:

>>>Når det er sagt, kunne jeg da også godt tænke mig, at de designede
>>>hardwaren lidt mere ens mht. QoS. Jeg kan fx rigtig godt lide C4K-
>>>måden at konfigurere det på, men ikke det faktum, at det er en shared
>>>buffer arkitektur, og fire køer er lidt lidt.
>
>Har du nogensinde brugt mere end 4 køer til noget (fornuftigt)?

På LAN/WAN er det primært IPT der er interessant. Og jer bruger man jo
bare en priority kø. Det komiske er at hvis man ikke passer på, så kan
man ende med en dårligere løsning, hvis man allokerer for lidt
båndbredde til køen og taildropper resten. Jeg har hørt historier,
ikke prøvet det selv.

Dem jeg har talt med har en KISS tilgangsvinkel, hvor man kun skal
prioritere der hvor det er nødvendigt. Dvs. der hvor man alligevel har
nok båndbredde, der bør man helt lade være. Den tilgang er jeg et
langt stykke enig i.

Man kan så udvide P-køen med en scavenger kø, hvis man vil benytte
Ciscos QoS strategi til at imødekomme DDoS scenarier.

Og man kunne vælge at prioritere resten af sin trafik - men igen KISS.
Man må igennem nogle overvejelser om

1) Hvor meget tid man skal bruge på at lave det
2) Hvilken gevinst man får ud af det
3) Energi der skal bruges til vedligehold
4) Og risiko for at man kommer til at stille sig ringere end hvis man
ikke gjor det.

Pt. er jeg mest tilhænger af IPT i priority og resten best effort.

På Internetsiden hvor man måske terminerer forskellige interne netværk
og hvor man driver services, der kan give mening at lave nogle
garanterede serviceniveauer. Det er her HQF begynder at give mening,
hvis man ikke vil kaste penge efter Packetshaper, Netenforcer eller
lign. løsninger.

Men i princippet kan det også løses med båndbredde. Trenden går så
vidt jeg kan se mod at båndbredde koster mindre end det avancerede QoS
udstyr. F.eks. koster en 100 Mbps linie mindre end en 20 Mbps linie +
udstyr der kan QoS'e 20 Mbps. Hvad er så bedst? - jeg vil sige 100 M i
langt de fleste scenarier.

Man kan naturligvis blive bekymret for DDoS, men her kan man jo lave
det samme trick med at identificere "unormal" trafik og smide det i en
scavenger kø. Det største problem her er at identificere "unormal"
trafik.

Så svaret på dit spørgsmål. Ja, jeg har brugt mere end 4 køer. Jeg har
arbejdet end del med Packetshaper og den har virkelig gjort sit
arbejde godt - omend tiden er rindet ud for den.

>> Bortset fra HQF - det synes jeg faktisk ser lidt interessant ud - og
>> næsten gennemskueligt.
>
>Line-rate shaping/policing burde være til at kunne gennemskue

Ja, det er bare ikke så fedt.

PS: for at gøre det endnu mindre let, så er der hele problemstillingen
med ToS, CoS, DSCP og mapninger i mellem dem og tilknytning til
klasser / køer. Det er muligt det er meget fleksibelt, men jeg sidder
tilbage med følelsen af at leverandørerne har gjort alt hvad de kan
for at gøre det så besværligt som muligt. Det har de naturligvis ikke
- men følelsen er nu reel nok.

--
Lars Kim Lund
http://www.net-faq.dk/

---

On Tue, 11 Apr 2006 23:46:40 +0200, Lars Kim Lund <lkl@fabel.dk>
wrote:

> På LAN/WAN er det primært IPT der er interessant. Og jer bruger man
> jo bare en priority kø. Det komiske er at hvis man ikke passer på,
> så kan man ende med en dårligere løsning, hvis man allokerer for
> lidt båndbredde til køen og taildropper resten.

Selvfølgelig skal man vide, hvad man stiller på, hvis man begynder at
skrue. Hvis man ikke gør det, skal man få nogle andre til at skrue for
en. (Jeg ville heller ikke selv give mig til at tune på ... øh ... mit
ur).

> Dem jeg har talt med har en KISS tilgangsvinkel, hvor man kun skal
> prioritere der hvor det er nødvendigt. Dvs. der hvor man alligevel har
> nok båndbredde, der bør man helt lade være. Den tilgang er jeg et
> langt stykke enig i.

Det er dog svært at kunne sige med nogen særlig autoritet, at man har
båndbredde nok. Hele tiden. Så snart man har droppet bare en enkelt
pakke, kan man diskutere, om det var den rigtige, når der nu *skulle*
droppes.

> Man kan så udvide P-køen med en scavenger kø, hvis man vil benytte
> Ciscos QoS strategi til at imødekomme DDoS scenarier.

Det er meget svært at implementere scavenger, hvis man ikke har et
godt indbilk i sin trafik. Hvis man kun har 'resten' og skal finde
scavenger i det, er det tæt på umuligt. Hvis man har klassificeret det
meste er det derimod meget nemmere at forholde sig til, om resten skal
være scanvenger eller simpelthen droppes.

> 1) Hvor meget tid man skal bruge på at lave det
> 2) Hvilken gevinst man får ud af det
> 3) Energi der skal bruges til vedligehold
> 4) Og risiko for at man kommer til at stille sig ringere end hvis man
> ikke gjor det.

Punkt 3 skal i hvert fald ikke undervurderes. Hvis man laver et vildt
kompliceret setup med mange trafiktyper i mange klasser, så bliver det
temmelig tungt at vedligeholde.

Hvis du gerne vil have det meget simpelt (med 'voice + resten', som du
er inde på), så brug AutoQoS på dit Cisco-udstyr. Så bliver det sat op
rimelig fornuftigt.

Engang kommer der nok også nogle management-systemer, der kan gøre det
lidt nemmere ... og på tværs af forskelle mellem platforme.

> Pt. er jeg mest tilhænger af IPT i priority og resten best effort.

Det kommer man også rigtig langt med. Mange organisationer har dog
også (mindst) en trafiktype, der er missionskritisk. For nogle kan det
fx være det ERP-system, der bliver pumpet produktionsdata ind i. Eller
det kunne være et CRM-system, som kunderne bliver slået op i, når de
ringer.

Hvis man har sådan et setup (voice + mission critical + resten), så
bliver det lidt mere kompliceret end fx AutoQoS kan håndtere, og for
en del stopper det ikke der.

> PS: for at gøre det endnu mindre let, så er der hele problemstillingen
> med ToS, CoS, DSCP og mapninger i mellem dem og tilknytning til
> klasser / køer.

Det behøver nu ikke så svært:

- Glem ToS
(Alt foregår med DSCP i dag)

- Klassificér og mærk med DSCP
(Der er et antal almindelig brugte værdier)

- Glem DSCP til CoS mapping
(Det bør ske default. Man dropper simpelthen de ekstra bit)

- Glem CoS til DSCP mapping
(Man bør have udstyr, der selv kan klassificere på L3+)

- Map klasser til køer efter behov.

Det er selvfølgelig lidt simplificeret, og især sidste punkt kan man
da godt bruge lidt tid på, men sådan med de brede penselstrøg...

-A

---

Først et spørgsmål til Kai og Asbjørn

Er dette den rigtige måde at designe RED kurven på - har f.eks. Cisco
implementeret den i så fald?:

An Analytical RED Function Design Guaranteeing Stable System Behavior:
http://www.ist-mobydick.org/publications/aqm_iscc2003.pdf
Citat: "... The resulting function is non-linear and can be described by
a polynomial expression. The advantage of this function lies not only in
avoiding heavy oscillations but also in avoiding link under-utilization
at low loads. The applicability of the derived function is independent
of the load range, no parameters are to be adjusted. Compared to the
original linear drop function applicability is extended by far.
For implementation the shape of the derived function can be approximated
with a normalized power function of the queue size. Our example with
realistic system parameters gives an approximation function of the cubic
of the queue size. The effort to implement the approximated cubic
function is not much higher compared to the linear function..."

Jeg ved at der en bedre måde DBL:
http://da.wikipedia.org/wiki/Undg%C3%A5else_af_datanet-trafikforstoppelse#Cisco_AQM:_Dynamic_buffer_limiting_.28DBL.29


Kai Harrekilde-Petersen wrote:
> Lars Kim Lund <lkl@fabel.dk> writes:
>
>
>>Asbjorn Hojmark <Asbjorn@Hojmark.ORG> wrote:
>>
>>
>>>>I øvrigt synes jeg at QoS er møgbesværligt fordi det er forskelligt
>>>>på stort set enhver platform.

Man skal bare stoppe trafikken ind i den åbne 2D DiffServ model (har
flere RFC'ere). De 2 dimensioner er i tabel 1 (der er dog også f.eks. ef
som også nævnes):
http://www.cisco.com/en/US/tech/tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml

"Type of Service" ToS er den gamle måde at gøre. som dog let kan mappes
ind i DiffServ.
...
> Kai

---

Glenn Møller-Holst <no_email_address@xx.dk> wrote:

>>>>>I øvrigt synes jeg at QoS er møgbesværligt fordi det er forskelligt
>>>>>på stort set enhver platform.
>
>Man skal bare stoppe trafikken ind i den åbne 2D DiffServ model (har
>flere RFC'ere). De 2 dimensioner er i tabel 1 (der er dog også f.eks. ef
>som også nævnes):
>http://www.cisco.com/en/US/tech/tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml
>
>"Type of Service" ToS er den gamle måde at gøre. som dog let kan mappes
>ind i DiffServ.

Jeg kender lidt til de modeller og standardiseringer der er lavet så
man har nogle faste mapninger mellem de forskellige klassifikationer.
Men dels synes jeg det er noget bøvl - og dels synes jeg opsætningen
på switche / routere (Cisco) er på grænsen til det komplet
uoverskuelige.

Det er naturligvis et spørgsmål om hvor meget energi man vil investere
i det og hvor vigtigt det er for en. Men du kan vel næppe være uenig i
at det ikke er særlig intuitivt?

--
Lars Kim Lund
http://www.net-faq.dk/

---

Lars Kim Lund wrote:
...
> Jeg kender lidt til de modeller og standardiseringer der er lavet så
> man har nogle faste mapninger mellem de forskellige klassifikationer.
> Men dels synes jeg det er noget bøvl - og dels synes jeg opsætningen
> på switche / routere (Cisco) er på grænsen til det komplet
> uoverskuelige.
>
> Det er naturligvis et spørgsmål om hvor meget energi man vil investere
> i det og hvor vigtigt det er for en. Men du kan vel næppe være uenig i
> at det ikke er særlig intuitivt?

Hej Lars

Jeg giver dig ret i at det ikke er let, men det er den måde IETF har
kræset sig ind på og en del leverandører heldigvis også har valgt at
understøtte.

Den sidste ting er, at der ikke er andre velkendte eller hardware
understøttede modeller.

Og dog der er jo de slot-baserede med reservation som f.eks. ATM, men de
er jo nok dyrere.

mvh/Glenn

---

On Tue, 11 Apr 2006 23:27:14 +0200, Kai Harrekilde-Petersen
<khp@harrekilde.dk> wrote:

>>> Når det er sagt, kunne jeg da også godt tænke mig, at de designede
>>> hardwaren lidt mere ens mht. QoS. Jeg kan fx rigtig godt lide C4K-
>>> måden at konfigurere det på, men ikke det faktum, at det er en shared
>>> buffer arkitektur, og fire køer er lidt lidt.

> Har du nogensinde brugt mere end 4 køer til noget (fornuftigt)?

Ja.

Man kommer selvfølgelig et langt stykke med fx 4 WRR-køer + WRED
(eller DBL som i tilfældet C4K), men man får bedre kontrol med bl.a.
buffering og båndbredde, når man har flere køer.

Det skal siges, at det ikke lige har været low-end routere, jeg har
brugt det på... Jeg har været priviligeret at få lov at arbejde med de
største firmaer med de mest avancerede netværkssetup (og behov), og
det viser sig altid, at når hardware-folkene tror, at *nu* er der da
*aldrig* nogen, der får brug for mere, så er der *netop* nogen, der
støder hovedet mod et loft.

-A
(Der arbejder i NetDesign... lidt endnu i hvert fald)

---

> De små Cisco-routere er jo software forwarding engines, så features
> afhænger primært af, hvilken software de kører. I dag kan de lave PQ,
> CQ, WFQ, CBWFQ, og LLQ. 'Ingen' bruger PQ og CQ længere, så enten
> kører folk default (ren WFQ) eller laver CBWFQ eller LLQ.

Tak for info.

Såvidt jeg kan læse af Ciscos dokumentation, så kan WFQ fungere uden
videre opsætning. I så fald, hvordan klassificerer den trafikken til de
default 256 (vægtede?) køer? Har den f.eks. en indbygget liste over
tcp/udp porte i forhold til 'trafik typen'? Altså med andre ord,
klassificerer den trafik ved at genkende bestemte porte som f.eks. VoIP
osv? Hvis ikke, hvilke parametre bruger den så til automatisk at
klassificere flows?

2 andre spørgsmål:

Hvilke cisco routere vil normalt blive brugt til privat og små typiske
virksomheder med op til 50-100 medarbejdere? Er det kun 800 serien?

Er der et typisk skel mellem små og lidt større routere, hvor scheduling
funktionaliteten udvides til at kunne mere end WFQ, CBWFQ og LLQ?

Venlig hilsen
Mikkel

---

On Wed, 12 Apr 2006 10:01:21 +0200, Mikkel <mhn@FJERNMIG.onbeat.dk>
wrote:

> Såvidt jeg kan læse af Ciscos dokumentation, så kan WFQ fungere uden
> videre opsætning. I så fald, hvordan klassificerer den trafikken til de
> default 256 (vægtede?) køer?

Den gør det ikke ud fra køer men ud fra flows identificeret ved source
og destination IP-adresse plus portnumre.

> Altså med andre ord, klassificerer den trafik ved at genkende bestemte
> porte som f.eks. VoIP osv? Hvis ikke, hvilke parametre bruger den så
> til automatisk at klassificere flows?

Nej, den schedulerer ikke ved at vide, hvad trafikken *er*, men kun
hvordan de enkelte flows *opfører* sig. Grundlæggende sker det ved en
opdeling mellem høj og lav båndbredde per flow. Det er en lille smule
sort magi, som man ikke kan justere ret meget på, men det fungerer i
praksis OK for en del trafik.

> Hvilke cisco routere vil normalt blive brugt til privat og små typiske
> virksomheder med op til 50-100 medarbejdere? Er det kun 800 serien?

Nej, det er ikke kun 800-serien. Det kan variere utroligt meget, ud
fra hvad boxen skal bruges til, og hvilke interfaces, services og
performance, man har brug for.

Det kan være 800 på små remote kontorer, 1800 på de lidt større, 2800
hvis man har brug for forskellige moduler og måske 3800, hvis man har
brug for flere forskellige moduler og høj performance.

Hvis man fx bruger routeren som telefoncentral, så skal den jo kunne
køre med voice-interfaces.

> Er der et typisk skel mellem små og lidt større routere, hvor scheduling
> funktionaliteten udvides til at kunne mere end WFQ, CBWFQ og LLQ?

Nej, det er stort set det samme, med mindre man kommer op i meget
store routere, hvor dele af arbejdet laves i hardware, og så kan man
opleve, at der er *mindre* funktionalitet end i de små, billige boxe
(men selvfølgelig også en meget højere performance).

..A