Proprietární řešení QoS na směrovačích Mikrotik

Rok / Year: 2012

Svazek / Volume: 14

Číslo / Issue: 2

Proprietární řešení QoS na směrovačích Mikrotik Proprietary solutions for QoS on Mikrotik router Mojmír Jelínek [email protected] Fakulta elektrotechniky a komunikačních technologií VUT v Brně.

Abstrakt: Tento článek uvádí základní pojmy z oblasti zajištění kvality služeb, používané metody a popisuje možnosti implementace proprietárního řešení QoS na systému RouterOS od společnosti MikroTik.

Abstract: This article introduces the basic concepts of quality assurance services, used methods, and describes the implementation of proprietary solutions for QoS system MikroTik RouterOS from.

2012/20 – 1. 3. 2012

Proprietární řešení QoS na směrovačích Mikrotik Mojmír Jelínek Fakulta elektrotechniky a komunikačních technologií VUT v Brně Email: [email protected]

Abstrakt – Tento článek uvádí základní pojmy z oblasti zajištění kvality služeb, používané metody a popisuje možnosti implementace proprietárního řešení QoS na systému RouterOS od společnosti MikroTik.

Tato metoda je v kontextu metody diffserv statická, což přináší výhodu jistoty velikosti kanálu, na druhou stranu zbytečného alokování pásma, které nemusí být využito.

1 Úvod Technologie QoS (Quality of Service) je důležitá pro každou datovou síť, kde je třeba řídit provoz, definovat jednotlivé priority toku paketů a celkově zaručit bezproblémový přenos dat skrze počítačovou síť. Metody implementace QoS do reálného prostředí vyžadují hlubší znalosti této technologie, proto její implementace není ani zdaleka nic běžného. Domácí sítě, nebo sítě malých firem řeší tedy řady problémů spojené s nerozdělováním svého datového provozu. V současné době rychlého rozvoje směrovačů a přepínačů firmy Mikrotik [1], která oslovuje své zákazníky především svou cenou, vysokou spolehlivostí a kvalitní dokumentací se postupně stává QoS implementace stále častější. Důležitou částí všech metod, které zajišťují kvalitu služeb je rozdělení toku paketů do specifických tříd podle předem definovaných pravidel. QoS je tedy soubor technologií, která řeší řadu problémů spojené s doručením paketu od zdroje ke svému cíli. Pro optimální nasazení je třeba dokonale znát architekturu vlastní sítě, přenosové rychlosti a to jak uvnitř sítě tak mimo ni, schopnosti a výkon jednotlivých prvků sítě pro dosažení co největšího výkonu a hlavně zaručení spolehlivost provozu.

Obr. 1: Diagram rozdělení pásma metody Intserv 2.2 Diffserv Metoda Diffsefv nezajišťuje pevnou rezervaci pásma, ale definuje podle informace v hlavičce paketu typ služby, která určuje, jak je dále v síti s paketem zacházeno. Hlavička IPv4 paketu obsahuje pole ToS o velikosti 8 bitů, které se dělí na 6 bitové pole DSCP (Differentiated Services Code Point) a na 2 bitové ECN (Explicit Congestion Notification). Pole DSCP definuje PHB index (Per Hop Behavior), který rozhoduje, jak daný prvek sítě naloží s paketem. Každé zařízení v architektuře sítě, pracující na třetí vrstvě TCP/IP modelu (L3), musí umět nakládat s tímto Diffserv klasifikátorem. [7] Tato metoda je tedy metodou dynamického přidělování šířky pásma, kdy podle zvoleného klasifikátoru je zaručen spolehlivý přenos toku paketů skrze počítačovou síť.

2 QoS QoS lze rozdělit do 3 základních skupin řízení paketového provozu. INTSERV, DIFFSERV a proprietární [2]. 2.1 Intserv Tato metoda je založena na pevné rezervaci pásma, která je vytvořena v okamžiku navázání spojení. Vnáší tak okruhově orientovaný model přenosu do paketově orientovaného. U této technologie není třeba datové toky dělit podle priorit, protože každý definovaný tok má své pevně vyhrazené pásmo. Z definice této metody je patrné plýtvání přenosovým pásmem a pravděpodobnost zahlcení rezervacemi pásma, které může být využito pro jiný datový tok (Obr. 1.).

2.3 Proprietární Některé zařízení nebo náročnější architektury vyžadují jiné zacházení s datovým tokem na každém L3 zařízení. Informace o prioritě daného paketu není tedy předávána skrze celou síť, ale definuje, jak je s daným paketem zacházeno na daném zařízení. Většinou je určeno několik druhů front, od typů s nízkou prioritou až po vysokou a podle druhu služby jsou do těchto front řazeny a následně zpracovávány. Například pro prioritizaci datového toku pro VoIP (Voice over Internet Protocol) komunikaci používá společnost Cisco u

20 – 1

VOL.14, NO.2, APRIL 2012

2012/20 – 1. 3. 2012

svých VoIP terminálů tzv. voice VLAN (Virtual Local Area Network), kdy na druhé vrstvě TCP/IP modelu (L2) je datový rámec zařazen do specifické VLAN, které Cisco přepínače prioritizují před jiným provozem pocházející z jiných VLAN a to na L2 čímž dochází ke zvýšení efektivity přenosu skrze přepínanou část sítě [4]. Některé zařízení využívají i 3 bitového pole „priority“ v hlavičce rámce. Operační systém Mikrotik RouterOS může velmi efektivně dělit paketové toky do tříd na L3, které dále zpracovává. Umožňuje i zpracovat datový tok pocházející ze specifické VLAN a ten dále prioritizovat podle potřeb, je tedy kompatibilní i se zmíněným řešením voice VLAN [1].

3 Mikrotik Mikrotik patří mezi velmi perspektivní společnost, která vyvíjí mimo vlastní hardwarové platformy i operační systém pro směrovače RouterOS a systém pro přepínače SwOS [1]. Tento systém lze nainstalovat na výkonný server postavený na architektuře x86. Další výhodou tohoto řešení je relativně levný upgrade hardware při zachování totožného systému či konfigurace. RouterOS umožňuje číst jakékoliv pole v hlavičce paketu či datového rámce a následně tyto hodnoty upravovat. To se v našem případě týká pole ToS DSCP, který je využíván u metody Diffserv. V drtivé většině produkčních prostředí je vnitřní kapacita počítačová sítě dostatečně předimenzována a prioritizaci paketů není tedy třeba implementovat. Problémem bývá komunikace mezi hraničními směrovači a veřejnou sítí, nebo komunikace mezi privátními sítěmi s úzkým přenosovým pásmem. Tento článek je proto zaměřen na proprietární řešení pomocí značkování paketů na hraničním směrovači a jejich následnému zpracovávání pomocí metod řízení datového toku (Queue). 3.1 Řízení datového toku Queue neboli řízení datového toku slouží v systému RouterOS především k řízení rychlostí, vytváření statistiky o přenesených datech a definovaní priorit jednotlivých paketů. Řízení je definováno ve 2 základních skupinách, pomocí simple queue, která dovoluje implementovat jednoduchá pravidla pro zacházení s pakety a také queue tree (Obr.3), umožňující mnohem rozsáhlejší možnosti řízení, především vytvoření stromu rodičovských pravidel a jejich potomků.

Obr.3: Příklad queue tree Algoritmus řazení datových toků je založen na technologii HTB (Hierarchical Token Bucket), který umožňuje vytvoření uvedeného stromu pravidel a stanovit vztahy mezi nimi. Výchozím bodem neboli nejvyšším rodičem pro tento strom reprezentují 4 základní místa (Obr.2): Global-in: reprezentuje příchozí datový tok na všech rozhraních směrovače Global-out: reprezentuje odchozí datový tok na všech rozhraních směrovače Global-total: součet 2 předchozích : reprezentuje odchozí datový tok na specifickém rozhraní směrovače 3.2 Důležité části konfigurace HTB Z uvedeného příkladu (Obr.3) je patrné, jakým způsobem je strom organizován a jaké části obsahuje. parent: Rodič, nadřazené řídící pravidlo pro vytvoření stromu. limit-at: garantovaná přenosová rychlost priority: Umožňuje nastavení priorit jak pro rodiče tak jejich potomky. V rámci jednoho rodiče můžeme mít řadu potomků, z nichž každý může mít jinou prioritu. Nejvyšší priorita je 1 a nejnižší 8 (výchozí). Potomek s vysokou prioritou bude mít vyšší šanci dosáhnout na rychlost definovanou polem limit-at, než potomek s nižší prioritou.

Obr. 2: Diagram toku paketů [5]

Mimo priorit umožňuje RouterOS volbu typu fronty. Výchozí best effort nazvaný jako bfifo (byte first in first out) a pfifo (packet first in first out), lze nahradit také SFQ (stochastic fair

20 – 2

VOL.14, NO.2, APRIL 2012

2012/20 – 1. 3. 2012

queueing), RED (random early detection), PCQ (per connection queue) a HTB (hierarchical token bucket) [8]. Všechny tyto fronty lze dále konfigurovat podle potřeb sítě a tím ovlivňovat výslednou kvalitu přenosu dat, resp. zefektivnit QoS.

limit na maximální teoretickou hodnotu propustnosti linky, a prioritu 5 (Obr.6).

Obr.5: Značení paketů

3.3 Značení paketů Jak již bylo zmíněno, RouterOS umožňuje číst všechny pole obsažené v hlavičce IPv4 paketu, a následně paket odděleně označovat pro pozdější zpracování (pro řízení toku). Jakékoliv značení provádí operační systém bez zápisu do aktuálního paketu pomocí oddělených interních značek, které jsou platné pouze u daného směrovače.

Obr.6: Řízení toku

Značení paketů je možné pomocí pravidel firewallu, k této funkci slouží položka mangle. Je důležité mít definovány pravidla, podle kterých k danému značení bude docházet. Příkladem může být detekce všech paketů se zdrojovou IP adresou sítě 192.168.0.0/24 a následně jejich značení pomocí položky packet mark s textem „network1”.

Tato konfigurace nenastavuje pevné limity datového přenosu jako při metodě Intserv, ale nastavuje garantovanou šířku pásma pro VoIP. V případě plného vytížení šířky pásma ostatním provozem bude tento provoz omezen na úkor aktuálního využití VoIP přenosu.

Tohoto označení je dále využito v queue tree a danému paketu je přidělena nastavená priorita.

Obdobně postupujeme i pro obrácený směr komunikace a tedy přenos VOIP paketů zpět ze serveru do privátní sítě. Pravidlo bude rovněž umístěno pod stejným rodičem (Obr. 7).

3.4 Příklad implementace Pokud je zadaný požadavek na zajištění kvality služeb pro 5 souběžných VoIP telefonních hovorů, je třeba si definovat garantovaný datový tok. Za předpokladu použití SIP protokolu [3] a kodeku G.711 64 Kbps (Obr. 4), který potřebuje minimální šířku pásma 87.2 Kb/s v jednom směru, je třeba garantovat minimálně 436 Kb/s v jednom směru. kodek

šířka pásma

velikost rámce

rámců

šířka pásma ethernet

G.711 (PCM)

64 kbps

160

1

87.2 kbps

G.723.1A (ACELP)

5.3 kbps

20

1

26.1 kbps

G.723.1A (MP-MLQ)

6.4 kbps

24

1

27.2 kbps

G.726 (ADPCM)

32 kbps

80

1

63.2 kbps

G.728 (LD-CELP)

16 kbps

5

4

78.4 kbps

G.729A (CS-CELP)

8 kbps

10

2

39.2 kbps

AMR (ACELP)

4.75 kbps

12

1

36.0 kbps

AMR (ACELP)

7.4 kbps

19

1

38.8 kbps

AMR (ACELP)

12.2 kbps

31

1

43.6 kbps

Obr.7: Konfigurace opačného směru Díky vytvoření stromu, může být pomocí „packet marking“ označen další druh komunikace a to přístupy na externí SQL server. Zde při značení paketů je možné využít cílové adresy a následné zařazení pod stejného rodiče, s tím, že potomek bude mít nižší prioritu (priorita 7) a šířku pásma limit-at 2000000 (Obr. 8) a (Obr.9). Ostatní komunikace je klasifikována výchozí prioritou 8 na úrovni rodiče (Obr.10).

Obr.4: Potřebná datová šířka používaných VoIP kodeků [6] Toho dosáhneme vhodným značením paketů. Při standartní konfiguraci SIP používá UDP port 5060, který si pomocí pravidel firewallu v poli mangle zapíšeme do pole destination port pomocí řetězce prerouting a takový paket označíme jako VoIP_upload (Obr. 5.). Následně v poli queue a queue tree vytvoříme pravidlo s prioritou 5, a rodičem global-out. Tohoto nového pravidla použijeme jako rodiče pro VoIP datový tok. U jeho potomka nastavíme limit-at na hodnotu 436000 a max-

20 – 3

Obr.8: Výsledná konfigurace

VOL.14, NO.2, APRIL 2012

2012/20 – 1. 3. 2012

Porovnání výstupů a účinnosti implementace QOS je uvedeno v článku [9].

Poděkování Na tomto místě patří poděkování projektu Centrum senzorických, informačních a komunikačních systémů (SIX), reg. č. CZ.1.05/2.1.00/03.0072, který je řešen na Ústavu telekomunikaci, Fakulty elektrotechniky a komunikačních technologií, Vysokého učení technického v Brně. Obr.9: Výsledná konfigurace

Literatura Některé uvedené parametry se přímo netýkají kvality služeb, ale možnosti omezení šířky pásma. Burst-limit, burst-threshold a burst-time slouží k nastavení dočasného navýšení maximální povolené propustnosti. Queue hodnota „default“ ukazuje na použití výchozího typu fronty a tedy pfifo.

[1] Mikrotik. Official MikroTik Documentation. Riga, Latvia.[online] Březen 2012. [cit. 2012-03-10]. Dostupné z WWW: < http://wiki.mikrotik.com/wiki/Main_Page> [2] Xipeng Xiao. Internet QoS: a big picture. IEEE Communications Society. Michigan State Univ., East Lansing, MI. Srpen 2002. s. 8-18. ISSN 0890-8044

[3] IETF: RFC-3261. Session Initiation Protocol. [online], Červenec 2008. [cit. 2012-03-10] Dostupné z WWW: < http://www.ietf.org/rfc/rfc3261.txt> [4] Cisco. Catalyst 2960 Switch Software Configuration Guide. Understanding voice VLAN. [online] 2004. [cit. 201203-10] Dostupné z WWW: [5] Mikrotik. MUM. Mikrotik RouterOS Workshop. QoS Best Practice. [online] 2009. [cit. 2012-03-11] Dostupné z WWW: [6] Newport Networks. VoIP bandwidth Calculation. [online] 2005. [cit. 2012-03-11] Dostupné z WWW: < http://kambing.ui.ac.id/onnopurbo/library/library-ref-eng/refeng-3/physical/voip/52-VoIP-Bandwidth.pdf>

Obr.10: Diagram rozdělení pásma

4 Závěr Pomocí zařízení postaveného na operačním systému RouterOS je možné dostáhnou velmi efektivního řízení toku paketů mezi jednotlivými sítěmi. Mimo klasické metody Intserv a Diffserv článek popisuje využití proprietárního řešení QoS na směrovači Mikrotik. Byly definovány pravidla nutné ke značení paketů a jejich následného zařazení do stromu a stanovení jejich priorit. Pro každý značený datový tok je možné definovat šířku pásma, která při maximálním využití bude garantována. Vytvoření řídícího stromu pravidel umožňuje velmi přehledné a obsáhlé možnosti konfigurace zacházení s paketovým datovým tokem skrze hraniční směrovač. Článek je zakončen ukázkou implementace proprietárního řešení QoS a rozdělní toku do tříd pro VoIP, SQL a ostatní data.

[7] IETF: RFC-3168. The Addition of Explicit Congestion Notification (ECN) to IP. [online], 2001.[cit. 2012-03-11] Dostupné z WWW: < http://www.ietf.org/rfc/rfc3168.txt>

[8] Mikrotik. Official MikroTik Documentation. HTB. Riga, Latvia.[online] Listopad 2011. [cit. 2012-03-11] Dostupné z WWW: [9] Z. Dubnický, M. Hrubec, D. Osička. Průzkum a ověření možností použití QoS na platformě Mikrotik (L2+L3). [online] Červen 2008. [cit. 2012-03-11] Dostupné z WWW:

20 – 4

VOL.14, NO.2, APRIL 2012