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í:

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):

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:
  1. 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
  2. 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
  3. vlastní pravidla pro QoS - vlastní pravidla aplikované na rozhraní AP
  4. 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í: 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.