obr. 1 - základní QoS model
semestrální projekt do předmětu Směrované a přepínané sítě
autoři: Petr Jaššo (jas063) a Tomáš Chalupka (cha061)
16. června 2005
Teoreticky vypracujte a prakticky ověřte podporu QoS na Cisco 3550 (2950T). Klasifikace, priorizace na 2. vrstvě, 802.1p, vazba na 3. vrstvu (IP DSCP).
Zpět na obsahKlasická ethernetová síť se snaží každý paket doručit v co nejkratší době. Všechny pakety mají stejnou šanci na doručení a pokud dojde k zahlcení sítě, tak mají i stejnou šanci k zahození.
Pokud ale správně nakonfigurujeme službu QoS (Quality of Service = "kvalita služby"), můžeme vybírat jednotlivé datové toky a priorizovat je podle jejich důležitosti před ostatními. Preferovanému datovému toku lze s použitím správy zahlcení přiřadit větší prioritu pro zpracování, což má následně pozitivní vliv na výkon aplikací a efektivnější využití šířky pásma.
Základní QoS model při zpracování paketu je následující:
obr. 1 - základní QoS model
Abychom mohli jedny datové toky priorizovat před ostatními, musíme si je nějakým způsobem označit a rozdělit do tříd (tzv. klasifikovat). To, do jaké třídy je paket klasifikován je přenášeno ve třetí vrstvě Ethernetu s použitím šesti bitů zastaralé položky IP hlavičky TOS (Type Of Service):
Informace o klasifikaci však může být přenášena i v rámci 2. vrstvy Ethernetu:
obr. 2 - pozice QoS hodnot v různých typech rámců
Klasifikace je proces rozlišování jednoho typu toku od druhého zkoumáním obsahu paketů. Klasifikace je prováděna pouze pokud má switch zapnutou podporu QoS (ta je implicitně vypnuta).
Možnosti, jak paket klasifikovat jsou následující:
| CoS | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| DSCP | 0 | 8 | 16 | 24 | 32 | 40 | 48 | 56 |
tabulka 1 - implicitní nastavení CoS - DSCP mapy
Poté, co je paket klasifikován a označen interní DSCP hodnotou, začíná "Policing and Marking" (kontrola pomocí hlídače a označkování). Hlídač (Policer) kontroluje nepřekročení nastavené šířky pásma. Pokud k tomu dojde jsou dané pakety označeny jako neodpovídající profilu. Každý policer pak určí, co bude s paketem provedeno, zda bude zahozen nebo přeznačkován novou DSCP hodnotou pomocí policed-DSCP mapy.
Zpět na obsahBěhem QoS procesu pracuje switch pouze s interní DSCP hodnotou. V průběhu klasifikace QoS používá konfigurovatelné mapovací tabulky k odvození vnitřní DSCP hodnoty (6 bitů) z přijaté hodnoty CoS nebo "IP precedence" (3 bity):
| DSCP | 0-7 | 8-15 | 16-23 | 24-31 | 32-39 | 40-47 | 48-55 | 56-63 |
| CoS | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
tabulka 2 - implicitní nastavení DSCP - CoS mapy
| CoS | 0, 1 | 2, 3 | 4, 5 | 6, 7 |
| egress-queue (výstupní fronta) | 1 | 2 | 3 | 4 |
tabulka 3 - implicitní nastavení CoS-to-egress-queue mapy
V ukázkovém příkladě si ukážeme, jak na CISCO 3550 nastavit podporu QoS a také jeho funkci ověříme. V našem testu provedeme klasifikaci paketů prostřednictvím hodnoty CoS protokolu 802.1p/802.1q (2. vrstva Ethernetu) a na vstupních rozhraních 3550 budeme důvěřovat hodnotě CoS v příchozím paketu. Za pomocí této hodnoty a převodních map se pakety zařazují do čtyř výstupních front. Demonstrujeme si, jak se v sítí projeví, když:
Otestování funkce QoS probíhalo následujícím způsobem:
Na tomto zapojení jsme možnosti QoS testovli:
obr. 3 - Schéma zapojení
Pro nastavení protokolu 802.1p/802.1q na rozhraní PC s operačním systémem linux jsme použili program vconfig, jehož zdrojové kódy i binární spustitelná podoba jsou k dispozici na www stránkách: http://www.candelatech.com/~greear/vlan.html. Pro jeho správnou funkci je nutné, aby v jádře byla podpora 802.1q, nebo se v systému nacházel modul: 8021q. Námi použité příkazy mají následující syntaxi:
ifconfig eth0 0.0.0.0 - nutné pro nahození eth0 a následné vytvoření VLANU vconfig add eth0 10 - na rozhraní eth0 vytvoří VLAN s ID = 10 -> vznikne logické rozhraní eth0.10 ifconfig eth0.10 10.0.0.10 netmask 255.255.255.0 broadcast 10.0.0.255 - přiřadí logickému rozhraní eth0.10 IP adresu vconfig set_egress_map eth0.10 0 7 - všechny odchozí pakety z rozhraní eth0.10 budou mít hodnotu CoS = 7
ifconfig eth0 0.0.0.0 vconfig add eth0 10 ifconfig eth0.10 10.0.0.20 netmask 255.255.255.0 broadcast 10.0.0.255
ifconfig eth0 10.0.0.30 netmask 255.255.255.0 broadcast 10.0.0.255
; vstoupíme do privilegovaného režimu
enable
; vstoupíme do globálního konfiguračního režimu
# configure terminal
; Zapnutí funkce QoS globálně
(config)# mls qos
; vytvoření VLAN
(config)# vlan 10
(config-vlan)# name vystup
(config-vlan)# exit
; rozhraní fastEthernet 0/1 nastavíme jako trunk s 802.1q a povolíme důvěru v CoS
(config)# interface fastEthernet 0/1
(config-if)# switchport mode trunk
(config-if)# switchport trunk encapsulation dot1q
(config-if)# mls qos trust cos
(config-if)# exit
; rozhraní fastEthernet 0/2 nastavíme jako trunk s 802.1q a povolíme důvěru v CoS
(config)# interface fastEthernet 0/2
(config-if)# switchport mode trunk
(config-if)# switchport trunk encapsulation dot1q
(config-if)# mls qos trust cos
(config-if)# exit
; rozhraní fastEthernet 0/3 nastavíme pro přístup do VLAN 10 rychlostí 10Mb/s
(config)# interface fastEthernet 0/3
(config-if)# switchport mode access
(config-if)# switchport access vlan 10
(config-if)# speed 10
(config-if)# exit
; na všech rozhraních fastEthernet vypneme flowcontrol
(config)# interface range fastEthernet 0/1 - 24
(config-if)# flowcontrol receive off
(config-if)# exit
Zpět na obsah
Zde jsme vyzkoušeli, jak se změnilo množství přenesených paketů z PC1 a PC2, při změně šířky pásma pro jednotlivé výstupní fronty. Rozdělení šířky pásma mezi čtyři výstupní fronty na rozhraní se nastavuje poměrově (algoritmus Weighted Round Robin). Implicitně jsou všechny váhy WRR nastaveny na 25 (= 1/4 pásma pro každou frontu). Pro změnu tohoto poměru se používá příkaz:
(config-if)# wrr-queue bandwidth <weight1> <weight2> <weight3> <weight4>
V našem ukázkovém příkladě (zajímají nás pouze výstupní fronty 1 a 4) jsme na rozhraní fastEthernet 0/3 použili poměr vah 1:4. Tedy použili jsme tento příkaz:
(config)# interface fastEthernet 0/3
(config-if)# wrr-queue bandwidth 1 1 1 4
Zde jsou naměřené hodnoty na PC3:
| pakety z PC1 | rychlost z PC1 (kb/s) | pakety z PC2 | rychlost z PC2 (kb/s) | poměr (PC1 : PC2) | |
| před příkazem | 610 | 4750 | 610 | 4750 | 1 : 1 |
| po příkazu | 975 | 7625 | 245 | 1906 | 4 : 1 |
tabulka 4 - naměřené hodnoty před a po příkazu wrr-queue bandwidth 1 1 1 4
Pro potvrzení jsme ještě vyzkoušeli nastavit poměr 1:2. Tedy použili jsme tento příkaz:
(config)# interface fastEthernet 0/3
(config-if)# wrr-queue bandwidth 1 1 1 2
A zde jsou opět naměřené hodnoty na PC3:
| pakety z PC1 | rychlost z PC1 (kb/s) | pakety z PC2 | rychlost z PC2 (kb/s) | poměr (PC1 : PC2) | |
| před příkazem | 610 | 4750 | 610 | 4750 | 1 : 1 |
| po příkazu | 815 | 6350 | 407 | 3170 | 2 : 1 |
tabulka 5 - naměřené hodnoty před a po příkazu wrr-queue bandwidth 1 1 1 2
Z výsledků je patrné, že množství přenesených paketů z PC1 a PC2 na PC3 přesně odpovídá nastaveným poměrům mezi výstupní fronty.
Zpět na obsahZde jsme vyzkoušeli priorizovat pakety odcházející z PC1 na PC3 prostřednictvím prioritní expediční fronty. Pokud na rozhraní zapneme prioritní režim, jsou vždy nejprve vyprázdňovány pakety z fronty s nejvyšší prioritou (fronta číslo 4). Až se tato fronta vyprázdní, přistoupí se k vyprázdňování zbylých tří front s nižší prioritou. Tímto zajistíme, že určité pakety budou mít prioritu před všemi ostatními. Zapnutí prioritního režimu na rozhraní fastEthernet 0/3 provedeme tímto příkazem:
(config)# interface fastEthernet 0/3
(config-if)# priority-queue out
Pro připomenutí: PC1 odesílá pakety s CoS hodnotou 7, ta je implicitně mapována na 4. výstupní frontu, tedy tu s nejvyšší prioritou. Proto se PC2 nedostane, až do zastavení provozu z PC1, vůbec ke slovu.
Po provedení tohoto příkazu jsme na PC3 naměřili tyto hodnoty:
| pakety z PC1 | rychlost z PC1 (kb/s) | pakety z PC2 | rychlost z PC2 (kb/s) | |
| před příkazem | 610 | 4750 | 610 | 4750 |
| po příkazu - provoz generuje PC1 i PC2: | 1220 | 9540 | 0 | 0 |
| po příkazu - provoz generuje pouze PC2: | 0 | 0 | 1220 | 9540 |
tabulka 6 - naměřené hodnoty před a po příkazu priority-queue out
Úprava CoS-DSCP mapy se provádí následujícím příkazem:
(config)# mls qos map cos-dscp <dscp1> <dscp2> <dscp3> ... <dscp8>
Mapa se nastaví takto: CoS=0 » dscp1, CoS=1 » dscp2, ..., CoS=3 » dscp4
V našem ukázkovém příkladě jsme se pokusili přemapovat pakety z PC2 s CoS=0 na DSCP=32, namísto původní DSCP=0.
(config)# mls qos map cos-dscp 32 8 16 24 32 40 48 56
To, že příkaz funguje, jsme si ověřili prozkoumáním hlaviček příchozích paketů paketovým analyzátorem na PC3:
| DSCP na paketech z PC1 | DSCP na paketech z PC2 | |
| před příkazem | 0x38 | 0 |
| po příkazu | 0x38 | 0x20 |
tabulka 7 - naměřené hodnoty DSCP před a po příkazu mls qos map cos-dscp 32 8 16 24 32 40 48 56
Z tabulky je vidět, že před provedením příkazu na přemapování CoS-DSCP, měly příchozí pakety z PC2 hodnotu DSCP = 0, avšak po provedení příkazu, byla tato hodnota přemapována na nastavenou hodnotu 32 (0x20).
Zpět na obsahÚprava CoS-egress_queue mapy (hodnotu CoS přiřazuje na výstupní frontu) na rozhraní se provádí následujícím příkazem:
(config-if)# wrr-queue cos-map <queue-id> <cos>
V našem ukázkovém příkladě jsme vyzkoušeli přemapovat pakety odcházející z rozhraní fastEthernet 0/3 s hodnotou CoS=0 na frontu číslo 3, namísto implicitní fronty číslo 1.
(config)# interface fastEthernet 0/3
(config-if)# wrr-queue cos-map 3 0
Abychom si mohli účinost příkazu ověřit měřením, musíme na rozhraní fastEthernet 0/3 změnit i poměr šířek pásem pro nyní používané fronty 3 a 4:
(config-if)# wrr-queue bandwidth 1 1 4 2
Po nastavení mapy "tečou" pakety z PC1 do 4. fronty a z PC2 do 3. fronty. Tyto fronty jsou nastaveny v poměru 2:4 (1:2). Když přemapování zrušíme, vrátí se pakety z PC2 zpět do 1. fronty. Ta je již však se 4. frontou v poměru opačném, 2:1. (viz. tabulka 8):
| pakety z PC1 | rychlost z PC1 (kb/s) | pakety z PC2 | rychlost z PC2 (kb/s) | poměr (PC1 : PC2) | |
| po nastavení mapy | 407 | 3170 | 815 | 6350 | 1:2 |
| po zrušení mapy | 814 | 6359 | 407 | 3179 | 2:1 |
tabulka 8 - naměřené hodnoty při přemapované a implicitní CoS-egress_queue mapy
Z výsledku je patrné, že přemapování CoS na výstupní frontu funguje podle očekávání.
Zpět na obsahZávěrem lze říci, že funkce QoS na switchi Cisco Catalyst 3550 se ukázala být až překvapivě spolehlivá. V laboratorních podmínkách lze ale težko simulovat situaci na skutečné síti, proto se výsledky v praxi mohou znatelně lišit. Zpočátku se zdálo, že se nám funkce QoS vůbec nepodaří ověřit, protože jsme měli problém s vygenerováním dostatečného provozu, aby zatížil výstupní rozhraní (v našem případě fastEthernet 0/3) switche a došlo tak k aktivaci QoS. Zkoušeli jsme záplavový ping i software generující pakety, avšak bezúspěšně, proto jsme byli nuceni si sami naimplementovat program, s jehož pomocí jsme odesílali UDP packety ze zdrojových PC (PC1 a PC2) dostatečnou rychlostí tak, aby došlo k zahlcení výstupního rozhraní switche a aktivaci QoS. Také jsme si naimplementovali program, který monitoruje přijaté UDP packety a zobrazuje souhrnné informace (ten jsme použili na PC3). Zdrojové kódy obou programů jsou k dispozici zde
Zpět na obsah