Projekt SPS

Průzkum a ověření praktických možností mechanismů podpory kvality služby (QoS) v sítích 802.11 s využitím Cisco Aironet 1100

zpracoval: Dvořák Jiří, dvo139, SPS 2006

Co je to QoS

Běžně je provoz na počítačových sítích zajištěn metodou best-effort (snaha o doručení paketu, který se v případě zahlcení linky zahazuje). Tím je ovšem zajištěna základní konektivita bez jakýchkoliv garancí že paket (data) přijdou do určité doby (s určitým zpožděním) nebo dojde k přenosu určitého objemu dat za jednotku času. Mechanismy, které nám zajistí tyto potřeby, nazýváme souhrně QoS (Quality of Services). QoS je tedy soubor technik řídící:

šířku pásma (bandwidth)
ztrátovost paketů (packet loss)
zpoždění (delay)
rozptyl zpoždění (jitter)

Označení paketů

Na 3. vrstvě OSI modelu je v hlavičce IP protokolu 8 bitů vyhrazeno pro označení typu služby, původně ToS (Type of Service), později DSCP (Differentiated Service Code Point). Na 2. vrstě je v rámcích 802.11.q označení třemi bity CoS (Class of Service).

QoS na wi-fi

Jelikož provoz bezdrátových sítí je odlišný od provozu na běžném Ethernetu, s podporou kvality služeb to bude podobné. Je-li připojený klient k access pointu, sdílí celkovou možnou kapacitu média. Pomocí QoS budeme chtít zajistit, aby byli někteří klienti upřednostňováni podle typu provozu, který generují, tj. např. uživateli kopírujícímu data přes FTP snížíme přenosové pásmo a to dáme raději uživateli který si prohlíží WWW stránky, nebo klientovi používajícímu telnet nebo ssh připojení dáme přednost před uživateli www stránek, abychom co nejvíce snížili zpoždění přenosu.

Hlavní rozdíly mezi QoS na drátové síti a wi-fi (Cisco Aironet 1100):

QoS na wi-fi síti na základě hodnoty DSCP vytváří hodnotu CoS v 802.1q rámci a priorizuje pakety, popř. pracuje již s vytvořenou hodnotou CoS a může ji dále měnit
používání speciálních class map filtrů pro identifikaci paketů
podpora priorizace provozu od bezdrátových telefonů (IP protokol 119)
podpora fronty FIFO (First In First Out)

Aplikování pravidel QoS na Cisco Aironet 1100

Ačkoliv lze vytvořené pravidla QoS nastavit na obě rozhraní (FastEthernet a wi-fi), nejběžnější a logicky nejsmysluplnější je priorizace provozu z AP do wi-fi sítě (obr. 1).

Obr. 1
Stejně jako u QoS na drátových sítích se efekt QoS uplatní pouze při dostatečné zátěži na wi-fi rozhraní.

Priorita aplikování QoS pravidel na AP:

klasifikované pakety - přijdou-li pakety ze switche nebo routeru s již nenulovou hodnotou CoS v 802.1q rámci, neprovádí se další značkování paketů a používá se uvedená klasifikace; existující klasifikace paketu má přednost před jakýmkoliv vytvořeným pravidlem
QoS pravidla pro wireless telefony - je-li aktivní QoS pro bezdrátové telefony, je provoz od těchto klientů upřednostňován před ostatním provozem bez ohledu na nastavení ostatních QoS pravidel
vlastní pravidla pro QoS - vlastní pravidla aplikované na rozhraní AP
standardní klasifikace pro všechny pakety na VLAN

Postup tvorby QoS

QoS pravidla můžeme konfigurovat dvěma způsoby: přes webové rozhraní zařízení nebo přes příkazovou řádku (CLI). Vzhledem k tomu, že konfigurace přes CLI poskytuje mnohem komplexnější konfiguraci, věnujme se dále pouze tomuto způsobu konfigurace.
Po přihlášení na zařízení se nacházíme v prostředí typickém pro všechna zařízení Cisco. Příkazem configure terminal vstoupíme do globálního konfiguračního režimu. Základem Qos na AP je skupina pravidel (tzv. policy-map) definujících chování Vlastní pravidla QoS začneme konfigurovat definováním tříd pro identifikaci paketů, kde je na výběr nespočet možností pro jejich identifikaci. Nejzákladnější možnosti jsou podle následujících kritérií:

IP Precedence
hodnota DSCP
IP protokol 119 (provoz bezdrátových telefonů)
vlastní definované filtry (zdrojová/cílová IP/MAC adresa, typ protokolu, port)

Další možností je identifikovat paket např. podle jeho délky na 3. vrstvě, čísla VLANu apod.

Jako příklad vytvoříme třídu www a přiřadíme do ní provoz z www serverů. Vzhledem k tomu, že class-map filtry neumožňují identifikovat pakety podle čísla portu, je nutné použít pro tuto identifikaci rozšířené acces-listy. Je třeba si dobře rozmyslet, v jakém směru jsou pro nás čísla portů důležitá. Uvažujeme-li o QoS pravidlech na výstupním směru rozhraní 802.11g, zajímají nás zdrojové čísla portů.

ip access-list extended www // definuje rozšířený acces-list s názvem www permit tcp any eq 80 any // přidá do acces-listu pakety protokolu tcp z jakékoliv zdrojové IP adresy z portu 80 do jakékoliv cílové adresy permit tcp any eq 443 any permit ip any any class-map match-all www match access-group name www // do třídy www bude spadat provoz vyhovující acces-listu se jménem www

Pro smysluplné QoS budeme mít takových tříd vytvořených více (viz dále Ověření funkčnosti).

Základem celých Qos je skupina pravidel (tzv. policy-map). Do policy-map přiřadíme požadovanou třídu a nastavíme, jak se s pakety dané třídy bude zacházet. Můžeme nastavit hodnotu CoS, rychlost přenosu (v kb nebo % celkové kapacity linky), velikost fronty, tvarování provozu (traffic shaping) atd.

Příklad vytvoření policy-map s názvem test1, přiřazení třídy www k této policy-map a nastavení hodnoty CoS:

policy-map test1 class www set cos 4

Poslední krok je přiřazení QoS pravidel na příslušné rozhraní. V našem případě příkazem service-policy nastavíme na výstupní směr wi-fi rozhraní AP policy-map s názvem test1.

interface Dot11Radio0 service-policy output test1

Nyní zbývá prakticky ověřit funkčnost QoS na AP Cisco Aironet 1100.

Praktické ověření funkčnosti

Pro ověření funkce QoS na AP Cisco Aironet 1100 jsem zvolil následující topologii sítě

Obr. 2

Stanice PC0 sloužila jako server (zdroj FTP, Windows Share, WWW), stanice PC1 a PC2 byly připojeny přes bezdrátové síťové karty Micronet Wireless LAN USB Adapter 11Mb/s, stanice PC3 byla připojena přes síťovou kartu Intel Wireless Pro. Stanice PC10 sloužila jako pomocná stanice (změny konfigurace QoS). Všechny stanice byly v jednom adresním prostoru 192.168.111.0/24.

Cílem bylo ověřit 2 základní veličiny: zaručení určité propustnosti a zaručení maximálního zpoždění.

Vzhledem k tomu, že se v testovací topologii nenachází žádný aktivní prvek (např. router), který by vytvářel hodnotu DSCP nebo CoS, a ani žádná aplikace hodnotu DSCP nevytváří (ověřeno programem pro zachytávání provozu na síti Ethereal), budeme označovat pakety podle čísla portu protokolu TCP.

První sledovaný parametr byla propustnost. Provoz byl klasifikován do několika tříd podle toho, zda šlo o přenos dat přes FTP, Windows Share nebo WWW. Stanice PC1 stahovala ze serveru (PC0) data přes FTP, stanice PC2 stahovala data z PC0 přes WWW a třetí stanice PC3 kopírovala objemný soubor z PC0 pomocí Windows Share. Konfigurace QoS měla za cíl výrazně omezit přenos dat přes FTP při zátěži jiného typu provozu. Ukázalo se však, že na Wi-Fi rozhraní není funkce omezení velikosti provozu (bandwidth) podporována (lze nastavit, ale zřejmě není brána v úvahu). Vyžaduje totiž obsluhu fronty CBWFQ (Class-Based Weighted Fair Queuing), Aironet 1100 disponuje pouze obsluhou fronty FIFO. Výrazné omezení přenosu dat přes FTP (na požadovaných 80 kbit/s) se tudíž nedostavilo.

Testovací konfigurace (pouze položky související výhradně s QoS):

ip access-list extended ftp permit tcp any eq ftp-data any permit tcp any eq ftp any permit ip any any ip access-list extended samba permit tcp any eq 139 any permit tcp any eq 138 any permit tcp any eq 137 any permit ip any any ip access-list extended web permit tcp any eq 80 any permit tcp any eq 443 any permit ip any any class-map match-all ftp match access-group name ftp class-map match-all www match access-group name web class-map match-all smb match access-group name samba policy-map test1 class smb bandwidth 300 class ftp bandwidth 80 class www bandwidth 500 interface Dot11Radio0 service-policy output test1
Druhým sledovaným parametrem bylo zpoždění na lince. Z jedné stanice (PC1) byl vysílán Echo Request na server v LAN síti (PC0). QoS byly nastaveny na priorizování ICMP protokolu (potřebujeme identifikovat Echo Reply) nastavením hodnoty CoS na 7. Při zátěži vytvořené přenosem dat ze serveru (PC0) na ostatní stanice (PC2 a PC3) se hodnoty zpoždění Echo Reply výrazně zvětšily. K totožné situaci došlo i při neaktivních QoS.

Testovací konfigurace (pouze položky související výhradně s QoS):

ip access-list extended ftp permit tcp any eq ftp-data any permit tcp any eq ftp any permit ip any any ip access-list extended samba permit tcp any eq 139 any permit tcp any eq 138 any permit tcp any eq 137 any permit ip any any ip access-list extended icmp permit icmp any any permit ip any any class-map match-all ftp match access-group name ftp class-map match-all icmp match access-group name icmp class-map match-all smb match access-group name samba policy-map test2 class smb set cos 2 class ftp set cos 3 class icmp set cos 7 interface Dot11Radio0 service-policy output test2

Závěr

Žádná z obou testovacích konfiguracací nedokázala (avšak ani nevyvrátila) reálnou funkčnost QoS na Ciscu Aironet 1100. Možnosti konfigurace jsou celkem obsáhlé, v žádné z testovacích konfigurací se ale nedostavil výsledek v podobě rozdílného "chování" při zapnutých či vypnutých QoS.