Průzkum a ověření možností použití QoS na platformě Mikrotik (L2+L3) Zdeněk Dubnický, Miroslav Hrubec, David Osička
Abstrakt: Cílem projektu je průzkum a ověření možností použití právě Quality of Service na platformě Mikrotik na druhé a třetí vrstvě referenčního modelu ISO/OSI.
Klíčová slova: Mikrotik, QoS (Quality of Service)
červen 2008
1/19
Obsah 1.
Úvod
3
2.
Základní pojmy
3
3.
4.
5.
2.1
Mikrotik
3
2.2
QoS
3
Volba topologie sítě a nastavení Mikrotiku 3.1
Nastavení používaných rozraní
6
3.2
Nastavení DHCP (klient i server)
6
Třetí vrstva referenčního modelu ISO/OSI
8
4.1
Popis problematiky
8
4.2
DiffServ model – klasifikace paketů
8
4.3
Nastavení systému Mikrotik pro účely testování.
10
4.4
Otestování chování sítě při nastavené priorizaci paketů a bez ní
11
4.5
DiffServ model – označování paketů
13
4.6
Nastavení systému Mikrotik pro účely testování priorizace DSCP značením
14
4.7
Aplikace Traffic Control a její nastavení za účelem DSCP označení
15
4.8
Testování priorizace provozu podle DSCP značení
16
Druhá vrstva referenčního modelu ISO/OSI 5.1
6.
4
Testování priorizace podle VLAN ID
Použitá literatura
červen 2008
17 17 19
2/19
1. Úvod Rozlišení paketů v síti je dáno toky, které tyto pakety vytváří. Přístup Best-effort popisuje síťové služby, kde síť negarantuje přenesená data a neřeší upřednostnění jistých datových toků. Chceme-li provozovat v síti služby multimediálního charakteru, jako jsou hlasové, video a další přenosy, či obecně aplikace s různými specifickými požadavky a nároky na síť, musíme v této mít mechanismy, které zaručí plnění našich požadavků. Splnění podstatné části takových požadavků si dává za cíl množina přístupů pro zacházení s datovým proudem, známá pod anglickým názvem Quality of Service (kvalita služby, QoS).
2. Základní pojmy 2.1
Mikrotik
Mikrotik (obchodní název MikroTik®) je operační systém směrovače, založen na bázi Linux OS. Původně byl tento OS vyvíjen v tehdejším Sovětském svazu. Oficiálně byl zveřejněn v roce 1995. Následné zkušenosti přivedly vývojáře k vybudování směrovacího software MikroTik v2, který přinesl lepší stabilitu, ovladatelnost a flexibilitu pro všechny typy komunikačních periférií a obecnou kompatibilitu směrovacích systémů v počítačových sítích. Komunikace s tímto OS je v současnosti zprostředkována např. přes GUI Winbox, ssh, telnet, nebo sériovou konzoli. V našem případě byla využívána především aplikace Winbox (v 3.4).
Obrázek 1: Mikrotik
2.2
QoS
QoS (Quality of Service) je řízení datových toků v síti. Tento soubor pravidel zajišťuje dělení síťových prostředků, za účelem priorizace některých datových proudů. V sítích totiž může docházet k situacím, jako je například tato: Z jedné koncové stanice se začne stahovat velké množství dat plnou rychlostí, čímž může dojít k vyčerpání limitů přidělených ISP (poskytovatelem služeb internetu), a další uživatelé již nemohou služby sítě využívat se stejnou kvalitou. K výše popsané situaci může dojít v případě, že v síti nejsou aplikována žádná pravidla, zajišťující kvalitu služeb.
červen 2008
3/19
3. Volba topologie sítě a nastavení Mikrotiku Před samotným nastavováním všemožných parametrů do OS Mikrotik, je důležité zvolit si vhodnou topologii sítě.
Obrázek 2: Zvolená topologie
červen 2008
4/19
Pro administraci, jak již bylo zmíněno, jsme zvolili aplikaci dodanou firmou Mikrotik, WinBOX v 3.4, běžící pod OS Windows.
Obrázek 3: Prostředí Winbox
červen 2008
5/19
3.1
Nastavení používaných rozraní
V menu interfaces se nacházejí všechny dostupné hardwarové, či nakonfigurované virtuální adaptéry. Implicitně je každé rozhraní (ethernetu, nikoliv tedy WiFi) pojmenováno „etherX“, kde X značí pořadové číslo rozhraní. Toto pojmenování lze samozřejmě libovolně změnit.
Obrázek 4: Nastavení interfaces Popis, jak „naklikat“ jednotlivá rozhraní je docela zbytečný, neboť ovládání aplikace WinBOX je relativně intuitivní a každý z příkazů, který se dá nastavit přímo v GUI WinBOXu, lze rovněž exportovat v podobě konfiguračních příkazů v konzoli (rovněž přístupné z aplikace WinBOX), proto zde uvádíme raději tyto. add address=192.168.88.1/24 broadcast=192.168.88.255 comment="default" disabled=no interface=ether1 network=192.168.88.0 add address=192.168.89.1/24 broadcast=192.168.89.255 comment="" disabled=no interface=ether2 network=192.168.89.0
3.2
Nastavení DHCP (klient i server)
Mikrotik může být nakonfigurován do režimu DHCP serveru. Nejprve je třeba definovat rozsah přidělovaných adres, který lze nastavit v ip –> IP Pool. Název a rozsah požadovaných adres můžeme zvolit ve tvaru např. 192.168.1.2-192.168.1.10, popř. pomocí tlačítka […] můžeme přidat jednotlivé IP adresy či více rozsahů.
červen 2008
6/19
Obrázek 5: IP Pool
Ostatní nastavení se provádí v ip –> DHCP server. Na záložce DHCP definujeme nastavení serveru, který adresy přiděluje, interface, na kterém mají být adresy přidělovány, expirační dobu a rozsah IP adres, který je definovaný v IP Pool.
Obrázek 6: nastavení serveru
V záložce Networks jsou údaje přidělované DHCP serverem – výchozí brána, maska sítě, DNS servery, doména a servery WINS. Pomocí položky Address nastavíme, jakým IP adresám se mají údaje přidělovat.
Obrázek 7: nastavení výchozích bran jednotlivých sítí
červen 2008
7/19
4. Třetí vrstva referenčního modelu ISO/OSI 4.1
Popis problematiky
Myšlenka o rozlišování typů paketů a následné možnosti jeho zpracování v rámci QoS, vznikla již v počáteční době specifikaci IP (RFC791). Jedná se o pole ToS (Type of Service), 1 Byte v hlavičce IP paketu. V raných dobách internetu nebyla podpora ToS důležitá a proto ji většina IP implementací ignorovala. Počátkem 90. let 20. století se začaly uplatňovat mechanismy pro plánování front paketů na směrovačích, jako například WRED. Tento mechanizmus slouží k zahazování paketů s nižší prioritou, z přeplněných front směrovačů. Rozšířením aplikací mající striktní požadavky na šíři pásma byl zaveden model „integrated services“ (RFC1633) pro garance predikovatelného chování sítě těmto aplikacím (protokoly RSVP, COPS). Velkou nevýhodou tohoto modelu je nepřetržité signalizování a špatná škálovatelnost. Zatímco u „integrated services“ signalizují požadavky na specifický QoS aplikace, u následného modelu „differentiated services“ (RFC2430) jsou jednotlivé třídy provozu, jež vyžadují QoS, rozpoznávány aktivními prvky v síti (přepínači a směrovači). Mikrotik zvládá QoS na třetí vrstvě bez větších problémů. Nabízí také několik možností jak provoz řídit. Následující realizace využívá zmiňovaný differentiated services model (dále DiffServ model), a to pomocí klasifikace paketů a označování paketů.
4.2
DiffServ model – klasifikace paketů
Je prostředkem pro identifikaci paketu určité třídy podle jednoho či více polí v hlavičce paketu. Těmi mohou být: •
Identifikace toků protokolu IP podle: o
zdrojové a cílové IP adresy
o
zdrojového a cílového čísla portu
o
hlavičky IP protokolu
•
IP precedence nebo DSCP pole
•
TCP/IP parametry hlavičky (např. délka paketu)
•
URL adresa
Vnitřní logika systému Mirkotik je schopná rovněž rozpoznávat P2P provoz, což se jistě může hodit při klasifikaci a filtrování případného škodlivého provozu. Rozeznávány jsou následující P2P protokoly: •
BitTorrent
•
Blubster
•
DirectConnect (DC++, MLDonkey)
•
eDonkey (eDonkdey 2000, eMule, xMule, Shareaza, MLDonkey)
•
Fasttrack (Kazza a jeho klony – např. Kauzalitě, Grokster, iMesh)
•
GNUtella (Shareaza, XoLoX, GNUcleus, BearShare, LimeWire, Morpheus, Phex, atd.)
•
GNUtella 2 (Shareaza, MLDonkey) červen 2008
8/19
Klientských programů existuje stále více. Jedná se však vesměs o programy využívající jednu z výše uvedených výměnných sítí, nejčastěji Fasttrack a GNUtella.
Jak je detekce P2P provozu v systému Mikrotik konfigurována, je patrné z následujících příkazů. Všechny pakety detekovaného P2P provozu jsou značeny „p2p“, ostatní provoz je značen „other“. Toto značení se týká pouze vnitřního „průchodu“ paketů systémem Mikrotik. Značky slouží pouze k účelu další práce s pakety (např. priorizace), ještě než tyto „opustí“ samotný směrovač.
/ip firewall mangle add chain=forward \ p2p=all-p2p action=mark-connection new-connection-mark=p2p_conn /ip firewall mangle add chain=forward \ connection-mark=p2p_conn action=mark-packet new-packet-mark=p2p /ip firewall mangle add chain=forward \ connection-mark=!p2p_conn action=mark-packet new-packet-mark=other /ip firewall mangle print
Vytvoříme dvě fronty, které limitují provoz od/ke klientovi pomocí nastavení hodnoty priority. Priorita všech p2p paketů je nastavena na nejnižší hodnotu, aby tyto zbytečně neblokovaly síť důležitějším. Z následujících příkazů je patrné, že v systémech Mikrotik, je priorizace paketů převrácena (oproti většině jiných systémů). Třída priority 1 je tedy nejvyšší a 8 nejnižší. Dá se říct, že je zde zohledněno lidské chápání dané věci. Pokud totiž značky priority chápeme jako číslovky řadové, ihned víme, který paket bude zpracován přednostně. /queue simple add interface=all name=p2p packet-marks=p2p priority=8 add interface=all name=ostatni packet-marks=other priority=1
Dvě výše uvedená nastavení jsou uvedena pouze pro představu, jak se na OS Mikrotik aplikují pravidla pro detekci a nastavení priority p2p sítí. Pro jakýkoliv jiný provoz se postupuje velice obdobně. (Viz. Další části).
červen 2008
9/19
4.3 Nastavení systému Mikrotik pro účely testování. Kromě výše uváděných přiřazení IP adres jednotlivým rozhraním bylo potřeba nastavit omezení šířky pásma a jednoduchou detekci libovolného provozu. Pro omezení šířky pásma použijeme menu Firewall Æ Mangle Æ datový tok Æ Simple Queues Æ general Æ max-limit. Po nastavení, ve výpisech příkazů nalezneme následující (limit pro p2p sítě je pro oba směry proudů dat omezen na 1Mbps (cca 125kB/s): Značkování paketů TCP protokolu, na všech portech, kromě 80 a paketů ostatních protokolů: /ip firewall mangle add action=mark-connection chain=forward comment="" disabled=no dst-port=!80 \ new-connection-mark=soub_conn passthrough=yes protocol=tcp src-port=!80 add action=mark-packet chain=forward comment="" connection-mark=soub_conn \ disabled=no new-packet-mark=soub_pack passthrough=yes add action=mark-packet chain=forward comment="" disabled=no \ new-packet-mark=other passthrough=yes protocol=!tcp
nastavení šířky pásma a priorizace jednotlivých paketů /queue simple add comment="" direction=both disabled=no dst-address=0.0.0.0/0 interface=all \ limit-at=1000000/1000000 max-limit=1000000/1000000 name="queue1" \ packet-marks=soub_pack parent=none priority=8 \ queue=default-small/default-small total-queue=default-small add comment="" direction=both disabled=no dst-address=0.0.0.0/0 interface=all \ limit-at=0/0 max-limit=0/0 name="ostatni" packet-marks=other parent=none\ priority=1 queue=default-small/default-small total-queue=default-small
červen 2008
10/19
Obrázek 8: limitování provozu
4.4 Otestování chování sítě při nastavené priorizaci paketů a bez ní Na vybudované síti (topologie viz. Obr. 2), bylo testováno chování sítě před a po aplikaci určitých pravidel QoS. V první iteraci testování v síti nebyly aplikovány žádné podpůrné prostředky QoS. Celková průchodnost (šířka pásma) linky byla pouze omezena na 1Mbit/s (viz předchozí příkazy „\queue simple“). Jednalo se o úmyslné omezení šířky pásma, aby zbyl dostatek času na testování a abychom tak obešli rezervace síťových prostředků, používané v systémech Windows (100MBit síť se chová jako 80MBit a zbytek jsou rezervy, které jsou v případně nutnosti uvolňovány). Samotné testování probíhalo tak, že byl z jedné koncové stanice přenášen velký (cca 1GB) soubor do stanice v jiném segmentu sítě tak, aby provoz procházel přes OS Mikrotik (a bylo tak aplikováno omezení šířky pásma na 1Mbit). Současně bylo na obou stanicích spuštěno vzájemné zasílání paketů ICMP protokolu, tzv. ping, tedy zjišťování doby, kterou trvá přijetí odpovědi stanice B na dotaz stanice A. Doby odpovědí se chovaly tak, jak bylo očekáváno, tedy C:\>ping 192.168.89.2 /n 10 /w 1000 Příkaz PING na 192.168.89.2 s délkou 32 bajtů: Odpověď Odpověď Odpověď Odpověď Odpověď Vypršel Odpověď Odpověď Odpověď Vypršel
od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 časový limit žádosti. od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 od 192.168.89.2: bajty=32 časový limit žádosti.
čas=425ms TTL=64 čas=234ms TTL=64 čas=598ms TTL=64 čas=3ms TTL=64 čas=792ms TTL=64 čas=18ms TTL=64 čas=379ms TTL=64 čas=430ms TTL=64
Statistika ping pro 192.168.89.2: Pakety: Odeslané = 10, Přijaté = 8, Ztracené = 2 (ztráta 20%), Přibližná doba do přijetí odezvy v milisekundách: Minimum = 3ms, Maximum = 792ms, Průměr = 360ms
Z rychlostí odezev je patrné, že fronta datových proudů systému Mikrotik byla téměř zahlcena. Ve dvou případech pravděpodobně dokonce došlo k zahození paketu ICMP protokolu z důvodu přeplnění fronty v systému Mikrotik. Poté bylo aplikováno jednoduché nastavení pro upřednostnění paketů, podle pravidel na předchozí stránce. Pro přenos souborů v sítích MS Windows slouží protokol TCP, proto bylo jednoduše nastaveno, že každý provoz na protokolu TCP, kromě toho se zdrojovým portem 80 (na tom rozhodně sdílené soubory ve Windows neběží), bude mít prioritu nejnižší (8). Naopak, každý provoz na protokolu jiném, než TCP bude mít prioritu nejvyšší (1). Protokol ICMP jistě není TCP, proto tímto nastavením docílíme upřednostnění paketů ICMP před pakety TCP (kromě portu 80). Po aplikaci těchto pravidel jsme testovali úplně stejným způsobem jako před ní a výsledek, který jsme dostali, byl jistě více, než uspokojivý:
červen 2008
11/19
C:\>ping 192.168.89.2 /n 10 /w 1000 Příkaz PING na 192.168.89.2 s délkou 32 bajtů: Odpověď Odpověď Odpověď Odpověď Odpověď Odpověď Odpověď Odpověď Odpověď Odpověď
od od od od od od od od od od
192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2: 192.168.89.2:
bajty=32 bajty=32 bajty=32 bajty=32 bajty=32 bajty=32 bajty=32 bajty=32 bajty=32 bajty=32
čas čas čas čas čas čas čas čas čas čas
< < < < < < < < < <
1ms 1ms 1ms 1ms 1ms 1ms 1ms 1ms 1ms 1ms
TTL=64 TTL=64 TTL=64 TTL=64 TTL=64 TTL=64 TTL=64 TTL=64 TTL=64 TTL=64
Statistika ping pro 192.168.89.2: Pakety: Odeslané = 10, Přijaté = 10, Ztracené = 0 (ztráta 0%), Přibližná doba do přijetí odezvy v milisekundách: Minimum = 0ms, Maximum = 0ms, Průměr = 0ms
Z výpisu programu „ping“ je zcela jasné, že systém Mikrotik začal upřednostňovat námi definovaný provoz (ICMP protokol), před provozem nad protokolem TCP. Můžeme tedy poznamenat, že priorizace na základě klasifikace paketů, se povedla a funguje.
červen 2008
12/19
4.5
DiffServ model – označování paketů
Klasifikovaný paket lze označit pro indikaci jeho třídy provozu. Na směrovači máme k dispozici možnost označit (někdy termín obarvit) paket pomocí jeho IP precedence nebo DSCP polem v IP hlavičce, nebo QoS group polem paketu v interní datové struktuře směrovače. DSCP
Na třetí vrstvě (tj. v hlavičce IP paketu) je třída provozu identifikována hodnotou v 8-bitovém poli DSCP (Differentiated Service Code Point). Původně se jednalo o 3-bitové pole Type of Service (ToS), umožňující zvolit jednu z předdefinovaných 8 tříd IP Precedence, později však bylo toto pole při zachování zpětné kompatibility hodnot rozšířeno a nyní lze mimo původních 8 tříd použít ještě 64 různých dalších tříd provozu. Do pole DSCP však není možné vložit libovolnou hodnotu, jelikož je dále strukturováno. Když paket vstupuje do oblasti sítě podporující QoS, musí být označkován na 2. i na 3. vrstvě. Značka na 2. vrstvě umožní správně priorizovaný průchod rámce přepínanou částí sítě, značka na 3. vrstvě pak odpovídající průchod směrovanou částí sítě po vybalení paketu z rámce na směrovači. Implicitně je hodnota DSCP nastavena na 0 (default). Kterékoliv jiné nastavení má tedy vyšší prioritu. IP precendence Indikuje v IP hlavičce relativní prioritu pro zacházení s paketem pomocí 3 bitů z pole ToS. K obarvení může dojít v libovolném uzlu sítě nebo přímo aplikací generující provoz. Celkem má 8 tříd:
Hodnota IP precedence
Bity IP precedence
Název IP precedence
0
000
Routine
1
001
Priority
2
010
Immediate
3
011
Flash
4
100
Flash Override
5
101
Critical
6
110
Internetwork control
7
111
Network control
Tabulka 1: hodnoty IP precedence
červen 2008
13/19
QoS group Jedná se o pole v datové struktuře paketu interně ve směrovači. Je tedy pouze značkou pro směrovač a není součástí IP hlavičky. (0 - 64) tříd. Velice zajímavé a aktuální je i využití QoS při priorizaci hlasových služeb, čili VOIP. VOIP SW/HW klient umít nastavit DSCP pole následně: •
SIP signalizující zprávy bude označen DSCP=0x68 (=104)
•
RTP audio data budou označena DSCP=0xB8 (=184)
Toto jsou implicitní hodnoty pro SPA-XXXX VOIP brány. Tato označení jsou schopny provést rovněž softwarové (klientské) aplikace.
4.6
Nastavení systému Mikrotik pro účely testování priorizace DSCP značením
Pro otestování tohoto způsobu priorizace datových toků je potřeba do systému Mikrotik zavést následující nastavení: Označení paketů s hodnotou DSCP 0x16, 0x00 (dekadické vyjádření 22 resp. 0): /ip firewall mangle add chain=prerouting tos=22 action=mark-packet new-packet-mark=pkt22 passthrough=yes add chain=prerouting tos=0 action=mark-packet new-packet-mark=pkt0 passthrough=yes
Nastavení nejvyšší priority pro označené pakety: /queue simple add name="PAKET-22" interface=all packet-marks=pkt22 priority=1 add name="PAKET-0" interface=all packet-marks=pkt0 priority=8
Pro účely této cesty priorizace nejsou potřeba žádná další nastavení, kromě již dříve zmíněného omezení šířky pásma na 1MBit a samozřejmého nastavení jednotlivých rozhraní. Ty už ale považujeme za implicitně nastavené, neboť není potřeba je přenastavovat. Abychom byli schopni zjistit, zda námi definované přiřazení priority fungují, je potřeba si pomoci další aplikací, jež nám pomůže provoz označit. Tedy do hlavičky IP paketu, v sekci DSCP, nastavit pro určitý proud námi požadované hodnoty (např 22).
červen 2008
14/19
4.7 Aplikace Traffic Control a její nastavení za účelem DSCP označení Aplikace Traffic Control funguje tak, že na požadovaném toku (řekněme, že si pro přenos dat vyhradíme port 2345), každý odchozí paket značkuje tak, jak je nastaveno. Pokud v ní tedy nastavíme, že má pakety značkovat na hodnotu 0x68, tak toto provede, nehledě na to, zda paket již označen je, či není. Nejprve zvolíme adaptér, na němž chceme značení paketů aplikovat (v případě, že jich je v počítači více). Nový datový tok, na nějž chceme značení paketů aplikovat, přidáme tlačítkem „Add“
Obrázek 9: Traffic Control Monitor
Nyní je třeba nový datový tok nadefinovat: 1) Na kartě „Parameters“ stačí nastavit pouze „token rate“ (1 000 000 b/s ~ 1Mbit). 2) V „Advanced Parameters” nastavíme dekadicky požadovanou hodnotu (22), aplikace ji sama přepočítá do šestnáctkového vyjádření 0x16. 3) A konečeně v kartě „Filters“ nastavíme port, který služba využívá, ostatní pole ponecháme. Ostatní údaje není potřeba nastavovat, vzhledem k jednoduché topologii sítě. Víme, že data půjdou vždy na adresu, na kterou potřebujeme. Nastavení se projeví ihned po potvrzení, není potřeba provádět restart žádných služeb. Ukládání probíhá do registrů. Při uložení proběhne přibližně 8000 přístupů ke klíčům registru, z velké většiny závislých na SID identifikátorech, což prakticky zabraňuje konfiguraci provádět (přenášet) jiným způsobem, než za použití aplikací, jako Traffic Monitor. Eventuelně můžeme používat aplikace, jež si QoS zajistí samy.
červen 2008
15/19
4.8 Testování priorizace provozu podle DSCP značení Testování probíhalo obdobně, jako při předchozích testech. Tentokrát jsme však byli omezeni na protokol TCP, protože Traffic Monitor neumožňuje nastavení toků jiných, než UDP a TCP protokolů. Program ping, by nám tedy spolehlivě fungující priorizaci nemusel odhalit. Proto do počítače ve druhém segmentu sítě byla odesílána data zároveň ze dvou počítačů na prvním segmentu. A to tak, že na prvním počítači byly pakety priorizovány DSCP značkami, nastavenými na hodnotu 22 (0x16). Zatímco na druhém počítači datový tok označován nebyl vůbec a pakety měly tedy implicitně nastavenou hodnotu pole DSCP na 0x00, měly tedy nižší prioritu. Na přijímající stanici, bylo možné sledovat jednoznačně vyšší přenosovou rychlost u dat pocházejících z počítače, na němž byly pakety označovány. Mikrotik se tedy choval správně a upřednostňoval správný datový tok.
červen 2008
16/19
5. Druhá vrstva referenčního modelu ISO/OSI Na vytížených LAN sítích může být žádoucí oddělit např. VoIP přenos od normálního datového. Administrátoři drží hlasovou a datovou komunikaci odděleně pro lepší bezpečnost a správu. VoIP přenos je tak pro Mikrotik oddělen použitím VLANu (nebo další Ethernetovou kartou). Datové přenosy používají odlišný VLAN (nebo síťovou kartu). Mikrotik je schopen jednotlivé VLANy priorizovat. To umožňuje nastavit VoIP VLAN vyšší prioritu než VLANům určeným pro datové přenosy. Priorizace musí být povolena a konfigurována na každém zařízení, kterým data prochází. Hlavička rámce v 802.1p obsahuje tří bitové pole pro priorizaci, které umožňuje seskupit rámce do různých skupin podle tříd. Existuje osm stupňů (0-7) priorizace společně s osmi frontami. Osmý stupeň reprezentuje nejvyšší prioritu.
Obrázek 12: rámec s tříbitovým polem pro QoS
5.1
Testování priorizace podle VLAN ID
Ověřili jsme možnosti pomocí virtuálních sítí, neboli VLANů. Opět jsme zaujali předpoklad, že jako správce sítě, máme představu, ve které části se nachází např. VOIP telefony, jejichž provoz chceme upřednostnit. Rozhodli jsme se vytvořit topologii, ve které máme na rozhraní Ether1 Mikrotiku připojené pomocí přepínače 2 stanice, přičemž každá je v jiné VLAN. Na rozhraní Ether2 Mikrotiku máme připojenou stanici, na které výsledný provoz analyzujeme. Mezi oběma rozhraními je nutné vytvořit most. Následně upřednostňujeme VLAN pojmenovaný voip s vlan-id =2.
červen 2008
17/19
Vytvoříme dva VLAN interface vlan> add name=voip vlan-id=2 interface=ether1 interface vlan> add name=provoz vlan-id=3 interface=ether1 name – název VLAN interface – interface do sítě, kde je VLAN vlan-id (default:1) - VLAN identifikátor nebo značka, která odlišuje jednotlivé VLAN, musí být stejná pro všechna zařízení v rámci jedné VLAN. Vytvoříme most mezi rozhraními ether1 a ether2 v obou směrech interface bridge add name=most interface bridge port add interface=ether1 bridge=most interface bridge port add interface=ether2 bridge=most Zbývající výpis z konzole definující zacházení rámci se nám nepodařilo vyexportovat korektně. Nicméně provoz přicházející z vlan voip (id =2) byl při plném vytížení linky upřednostněn.
červen 2008
18/19
6. Použitá literatura [1] Mangle, Mikrotik Documentation, 5. listopad http://www.mikrotik.com/testdocs/ros/2.9/ip/mangle.php
2005.
Dokument
dostupný
na
URL:
[2] Petr Kabilka, Tomáš Kraus : Průzkum a ověření praktických možností mechanismů podpory kvality služby (QoS) v sítích 802.11 na bázi mechanismů IEEE 802.11e. VŠB-TU Ostrava, 2006 [3] Quality of Service (QoS) and 802.1p Techniques, 1. listopad 2007. Dokument dostupný na URL: http://www.mytnconnection.transition.com/quality-of-service-qos-and-8021p-techniques/93/#more-93 [4] QoS for VOIP in Mikrotik, 11. prosinec 2007. http://nestranici.slavicin.org/index.php/QoS_for_VOIP_in_Mikrotik
Dokument
dostupný
na
URL:
[5] Virtual LAN (VLAN) Interface, 3. březen 2003. Dokument http://www.mikrotik.com/documentation//manual_2.7/Interface/VLAN.html
dostupný
na
URL:
červen 2008
19/19
