www.center.hu / Tudástár / Cikkek / QoS switchelt hálózatokban 

QoS switchelt hálózatokban

A QoS szükségessége switchelt hálózatban

A gyártók váltakozó állásponton vannak a Layer2 QoS szükségességének mértékét illetően, azonban a vezető gyártók egyetértenek abban, hogy alapvető Layer2 QoS nélkül nem lehet felsőbb szintű QoS-t sem implementálni. A csomagot legalább az indulásakor vagy az első aktív eszközbe érkezésekor meg kell jelölni, és ezután a jelölésnek megfelelő módon kezelni (DiffServ modellel összhangban). Mért kell bárhogyan is kezelni ezeket a csomagokat? Azért, mert a hálózatok általában alultervezettek: az uplink sávszélessége nem nagyobb, mint az access portok maximum sávszélességeinek összege. Ritka az a hálózat, ahol 48 portnyi 10/100-as kapcsolatra legalább 5Gbit/s felszálló sávszélesség esik (általában ez 1-2 Gbit/s). Mi történik, ha mindenki egy e-Learning tanfolyam anyagát hallgatja, és közben egy kolléga FTP-zni kezd, vagy egyszerűen csak elküld egy nagy melléklettel rendelkező levelet? Jó esetben csak szakadozni fog a hang, rossz esetben az egész alkalmazás time-outra fut. Fontos tehát, hogy a hálózaton kavargó forgalmak között rendet tegyünk, és megmondjuk, hogy

-milyen fontossági sorrendet tudunk felállítani (megjelölés prioritás szerint)
-mit teszünk a torlódás elkerülése érdekében, miből dobunk el (torlódás elkerülés)
-hogyan szolgáljuk ki a prioritási osztályba tartozó forgalmakat torlódás esetén (queuing)
-milyen sávszélességet rendelünk hozzá az egyes forgalmakhoz (queuing szintén)
-milyen egyéb technikákat vonunk be (többnyire Layer3) a késleltetés és késleltetés változás minimalizálására

A QoS tehát nem csak queuing (pl. WRR, SP, CBWFQ, FIFO), hanem a forgalommenedzsment technikák összessége. Fontos alaptétel, hogy queuing addig hatásosan nem történik, amíg nincs torlódás.

A QoS fajtái
Queuing – FIFO
First  In  –  First Out, vagyis  minden  csomagot érkezési sorrendben továbbítunk. A várakozási sorunk tulajdonképpen egy csővezeték, ami bement, az előbb-utóbb ki is jön. A fontos vagy sürgős csomagok nem előzik meg a kisebb prioritású csomagokat.

Queuing – Priority Queuing (PQ) és Strict Priority (SP)
A csomagokat érkezéskor a négy vagy nyolc prioritási szint egyikébe soroljuk megjelölésük alapján. A prioritási sorokból úgy szolgáljuk ki a forgalmakat, hogy amíg a felsőbb (fontosabb) prioritási sorban van csomag, addig az alsóbb prioritási sorban lévő sorokból nem továbbítunk csomagot. Ez a kisebb prioritású várakozási sorok „kiéheztetését” eredményezheti.

 
Queuing – Custom Queuing (CQ) és Weighted Round Robin (WRR)
Amíg a PQ és SP mindig a fontosabb, feljebb lévő várakozási sorban lévő forgalmakat feltétel nélkül kiteszi a kimenő interface-re, addig a CQ és WRR esetén megadható, hogy a teljes sávszélesség hány százalékát kapja meg egy várakozási sor, illetve mekkora csomagmennyiség után ugorjon az ütemező a következő várakozási sor kiszolgálására.

 
Queuing – Wighted Fair Queuing (WFQ)
A WFQ egy nagyon könnyen beállítható, automatikusnak mondható önkonfiguráló queuing algoritmus, amely a flow-k, vagyis folyamok sávszélesség igényének megfelelően és a csomagméretekhez alkalmazkodva próbál kiegyensúlyozott sávszélességet nyújtani. A kis csomagokat beágyazza a nagy sávszélesség igényű streamek nagy csomagjai közé az élni és élni hagyni számítógépes implementációjának megfelelően. Az algoritmus hibája, hogy jelentős túlterhelés esetén a működése nem lesz megjósolható.

Queuing - Class Based Weighted Fair Queuing (CBWFQ) és Low Latency Queuing (LLQ)
A CBWFQ a CQ és a WFQ ötvözéséből született. A forgalmakat osztályokba soroljuk, és ezekre az osztályokra határozzuk meg, hogy CQ vagy WFQ legyen a queuing algoritmus. LLQ kiterjesztés esetén ehhez még hozzáveszünk egy PQ besorolási lehetőséget, amely a késleltetés érzékeny alkalmazásokat (pl. hang és videó) a többi forgalom elé sorolja. A teljes modell tehát a következő:
Forgalomhoz prioritás rendelése -» Prioritások osztályokba sorolása -» osztályok kiszolgálása (először PQ, majd CQ és WFQ)

 
Torlódás elkerülés - Weighted Random Early Detection (WRED)
Mielőtt a torlódás kialakulna, és ezért queuingra lenne szükség vagy nagymértékű torlódás kialakulna, választhatjuk azt, hogy megelőző csapást mérünk a TCP stream-ekre, és véletlenszerűen eldobálunk belőlük. Az eldobás hatására a TCP mérsékli az ablakméretét és újraküldi a csomagot, ezáltal csökkentve a stream által igényelt sávszélességet. A várakozási   sorok betelése előtti véletlenszerű eldobás azt is lehetővé teszi, hogy a várakozási sor  betelésekor fellépő sorvégi eldobás (tail drop) a stream-eket sokkal érzékenyebben érintse a stream-eket (néha-néha eldobni egy  csomagot sokkal jobb megoldás, mint egyszer csak 10 egymás utáni csomag eldobása). A WRED még a queuing előtt valósul meg, így a várakozási sorokba már olyan forgalmak jutnak, amiket „megegyeltünk” (WRED másként: http://www.ezermester.hu/articles/article.php?getarticle=2122).
 
Sávszélesség szabályozás – Traffic Policing és Traffic Shaping
Beszélhetnénk most mindenféle egy, két és háromszínű többvödrös policingról, de nem tesszük,mert ezt majd a Layer3 QoS-nél kifejtjük. A fontos azonban az, hogy a Traffic Policing egyértelmű sávszélesség határnál vágja le a forgalmat és nem bufferel, míg a Traffic Shaping bufferel. A késleltetés változás érzékeny felhasználások (pl. hang, videó) nem tesz jót a bufferelés, ezért ezeknél legfeljebb a Policing alkalmazható. A Traffic Policing másik neve a CAR (Committed Access Rate), míg a Traffic Shaping-é a GTS (Generic Traffic Shaping).

Általánosságban elmondható, hogy a switchek és routerek QoS konfigurálása abban különbözik, hogy a switchekben a QoS támogatása hardveres, így azok erősen kötődnek a hardver queue-khoz. A switchekben a forgalmakat a 802.1p prioritás (Layer2) vagy DSCP érték (Layer3) alapján Local

Precedence (LP) értékkel feleltetik meg, amely a hardveres várakozási sorral megfeleltetést jelenti. Vagyis ha egy forgalom LP értéke 4, akkor az a 4-es hardver queue-ba fog sorolódni. A porton egyedileg vagy globálisan megadható, hogy a 4-es queue WRR vagy SP legyen. Az ütemező a legmagasabb számú hardveres várakozási sortól a 0 felé haladva vizsgálja az ütemezés típusát és a sorban lévő forgalmat.

QoS példa egy switchre
acl number 2100
 rule 0 permit source 10.10.1.0 0.0.0.255
acl number 2101
 rule 0 permit source 10.10.11.0 0.0.0.255
acl number 2102
 rule 0 permit source 10.10.12.0 0.0.0.255
#
#
traffic classifier rede0 operator and
 if-match acl 2100
traffic classifier rede1 operator and
 if-match acl 2101
traffic classifier rede2 operator and
 if-match acl 2102
traffic classifier rede3 operator and
 if-match dscp cs6
#
traffic behavior limit3
 car cir 320 cbs 4000 ebs 4000 green pass red discard yellow pas
traffic behavior limit2
 car cir 256 cbs 4000 ebs 4000 green pass red discard yellow pas
traffic behavior limit1
 car cir 192 cbs 4000 ebs 4000 green pass red discard yellow pas
traffic behavior limit0
 car cir 128 cbs 4000 ebs 4000 green pass red discard yellow pas
#
qos policy Policy0
 classifier rede0 behavior limit0
 classifier rede1 behavior limit1
 classifier rede2 behavior limit2
 classifier rede3 behavior limit3
#
qos policy Policy0
 classifier rede0 behavior limit0
 classifier rede1 behavior limit1
 classifier rede2 behavior limit2
 classifier rede3 behavior limit3

2010-02-08 13:34

Vissza