České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Komplexní řešení implementace řízení toku dat na linuxovém routeru
Jan Sechovec
Vedoucí práce: Ing. Jiří Smítka
Studijní program: Magisterský Obor: Výpočetní technika Květen 2008
Poděkování Chtěl bych především poděkovat své přítelkyni a snoubence Janě, za podporu při psaní práce (ať již morální, či praktickou při korektuře pravopisu a gramatiky). Dále všem aktivním členům Sdružení Klfree.net, za to, co pro chod sítě ve svém volném čase dělají a tím vůbec tato síť může existovat. Dobrovolná práce v této síti pro mě byla a je velkým přínosem, zejména co se týče síťových technologií a bez ní by ani nevznikla tato práce. Kapele Bolt Thrower děkuji za zpříjemnění chvil při práci.
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Kladně dne 21.5. 2008
.............................. .....
Abstract In my work, I’m dealing with problem about Quality of Service (QoS) and controlling of data flow on a linux router. Furthermore with designing systems, that guarantees desired Quality of Service and implementation of them on GNU/Linux platform. The outcome of this work is particular implementation of such system for network of non-profit organization Klfree.net.
Abstrakt Ve své práci se zabývám jednak obecně problematikou kvality služby (QoS) a řízení toku dat na linuxovém routeru. Dále pak možnostmi pro návrh systémů pro zajištění kvality služby a implementací takového systému v prostředí operačního systému GNU/Linux. Výsledkem práce je konkrétní řešení implementace takového systému v síti Sdružení Klfree.net.
1
Úvod.............................................................................................................. 1
2
Úvod do problematiky a vymezení cílů práce .............................................. 2 2.1
Pojem kvality služby............................................................................. 2
2.2
Prostředí linuxových routerů (směrovačů) ........................................... 2
2.3
Navrhování komplexních systémů pro řízení toku dat ......................... 2
2.4
Vymezení cílů práce a požadavků na navrhovaný systém ................... 3
3
Popis struktury práce ve vztahu k vytyčeným cílům .................................... 4
4
QoS – Quality of service............................................................................... 5 4.1 4.1.1
Datová propustnost ........................................................................... 5
4.1.2
Rychlost odezvy................................................................................ 6
4.1.3
Rozptyl přenosové doby – jitter........................................................ 7
4.1.4
Ztrátovost paketů .............................................................................. 7
4.1.5
Dostupnost služby............................................................................. 7
4.1.6
Příklady požadavků služeb ............................................................... 8
4.2
Nejčastější situace vyžadující použití QoS........................................... 8
4.2.1
Nedostatečná přenosová kapacita linky............................................ 8
4.2.2
Přenosové médium s nevyhovujícím řízením toku dat..................... 9
4.3
Způsoby řízení toku dat ...................................................................... 10
4.3.1
Type of service (TOS) .................................................................... 10
4.3.2
Rezervační protokol RSVP............................................................. 10
4.3.3
DiffServ – differentiated services ................................................... 11
4.3.4
Traffic shaping................................................................................ 11
4.3.5
Prioritizace ...................................................................................... 12
4.3.6
Ostatní metody................................................................................ 12
4.4
5
Požadavky na přenos dat – kvalita služby ............................................ 5
Části sítě a možnosti jak zde realizovat QoS...................................... 12
4.4.1
Vstup do sítě ................................................................................... 12
4.4.2
Tranzitní část sítě ............................................................................ 13
4.4.3
Výstup ze sítě.................................................................................. 14
Metody pro řízení toku dat na Linuxu ........................................................ 15 5.1
Základní principy................................................................................ 15
5.1.1
Řízení toku...................................................................................... 15
5.1.2
Frontové disciplíny (queue disciplines - qdisc) .............................. 16
5.1.3
Třídy (classes)................................................................................. 16
5.1.4
Klasifikátory (filters).......................................................................17
5.1.5
Průchod paketu routerem ................................................................18
5.2 5.2.1
Kompilace jádra ..............................................................................21
5.2.2
Balík iproute2 ..................................................................................21
5.2.3
Podpora v iptables ...........................................................................22
5.2.4
Použití příkazu tc.............................................................................22
5.3
Jednotlivé frontové disciplíny .............................................................23
5.3.1
Pfifo_fast .........................................................................................23
5.3.2
Pfifo a bfifo .....................................................................................23
5.3.3
TBF - Token Bucket Filter ..............................................................24
5.3.4
SFQ - Stochastic Fairness Queueing...............................................25
5.3.5
ESFQ – Extended verze SFQ ..........................................................25
5.3.6
RED – Random Early Detection .....................................................26
5.3.7
Prio ..................................................................................................27
5.3.8
DSMARK........................................................................................28
5.3.9
HTB - Hierarchical Token Bucket ..................................................28
5.4
Klasifikátory........................................................................................30
5.4.1
U32 klasifikátor...............................................................................30
5.4.2
FW – netfilter mark .........................................................................31
5.4.3
ROUTE – Routing decision ............................................................32
5.4.4
TCINDEX – Traffic-Control Index.................................................32
5.5 6
Nastavení systému...............................................................................21
IMQ .....................................................................................................33
Návrh komplexního systému.......................................................................34 6.1
Příklady v praxi používaných řešení ...................................................34
6.1.1
Shaping na úrovni portů ..................................................................34
6.1.2
Shaping na úrovni IP adres..............................................................35
6.1.3
Systém postavený na Differential Services .....................................36
6.2
Návrhy řešení pro jednotlivé části sítě ................................................37
6.2.1
Konkrétní požadavky ......................................................................37
6.2.2
Návrh řešení pro část sítě s připojenými uživateli ..........................38
6.2.3
Návrh řešení pro tranzitní část sítě..................................................38
6.2.4
Návrh řešení pro místo připojení k internetu ..................................39
6.3
Návrh řešení pro síť Klfree.net............................................................39
6.3.1
Specifika sítě Klfree.net.................................................................. 39
6.3.2
Problematika wifi............................................................................ 40
6.3.3
Návrh řešení pro WiFi .................................................................... 41
6.3.4
Řešení v ostatních částech sítě........................................................ 42
6.4 7
Srovnání navrženého řešení s jinými systémy.................................... 42
Implementace.............................................................................................. 44 7.1
Popis Implementace............................................................................ 44
7.1.1
Inicializace systému ........................................................................ 44
7.1.2
Konfigurace basic modulu .............................................................. 45
7.1.3
Konfigurace userap modulu............................................................ 45
7.1.4
Implementace userap modulu ......................................................... 46
7.1.5
Instalace .......................................................................................... 48
7.2
Dokumentace ...................................................................................... 48
7.3
Testování............................................................................................. 48
7.4
Ověření funkce systému...................................................................... 49
8
Závěr a plány do budoucna......................................................................... 51
9
Použitá literatura a odkazy.......................................................................... 53
A.
Seznam použitých zkratek ............................................................................ ii
B.
Sdružení Klfree.net ....................................................................................... ii
C.
Ukázka webového rozhraní routeru s qosem ............................................... iv
D.
Dokumentace – návod ke konfiguraci .......................................................... v
1 Úvod Cílem mé diplomové práce je seznámit čtenáře s problematikou zajištění kvality síťových služeb jako takovou a metodami pro řízení toku dat pro její zajištění v prostředí operačního systému GNU/Linux. Dále pak nastínit návrh takového řešení včetně konkrétní implementace v síti Sdružení Klfree.net.
Motivace práce S operačním systémem Linux jsem se dostal do prvního kontaktu vlastně právě díky připojení do počítačové sítě Sdružení Klfree.net. Psal se rok 2004 a WiFi technologie zažívala velký boom díky na tuto dobu bezkonkurenční rychlosti a ceně za připojení. DSL technologie byly ještě v plenkách a většina lidí využívala drahé a pomalé vytáčené připojení pomocí klasických modemů. Od prvních pokusů s anténou vyrobenou z plechovky od motorového oleje a instalace vlastního routeru pro připojení domácí sítě (PC s procesorem Intel 80486) jsem se postupně dostal až do role správce několika přístupových bodů sítě Sdružení Klfree.net a síťového administrátora, kdy se zabývám především dohledem sítě a přidělováním adresních rozsahů pro jednotlivé body a části sítě. Jako většina podobných sítí začínalo Sdružení Klfree.net s několika WiFi přístupovými body (Node) a propoji mezi nimi realizovanými opět na technologii WiFi. Proto bylo nutné již od prvopočátku řešit problémy spojené jednak s přetíženými spoji, tak i s nepříliš dobrými přenosovými vlastnostmi používaných bezdrátových technologií. Nastaly první experimenty s prioritizací a traffic shapingem (oba tyto pojmy budou v práci vysvětleny) a studium různých materiálů a norem zabývajících se touto problematikou. Poté zkoušení jinde používaných systémů a nakonec i vývoj vlastního systému, na základě předchozích zkušeností. Výsledkem tohoto vývoje je také tato diplomové práce, ve které se jednak pokusím uplatnit již získané zkušenosti a samozřejmě zároveň si je obohatit o další důkladnější studium těch částí problematiky, které byly z nedostatku času, či z jiného důvodu opomíjeny.
1
2 Úvod do problematiky a vymezení cílů práce V této kapitole se postupně od vysvětlení pojmu kvality služby, přes popis prostředí linuxových routerů a popisu návrhu systémů pro řízení toku dat dostanu až ke stanovení cílů této práce.
2.1 Pojem kvality služby Kvalita služby je českým překladem anglického termínu Quality of Service – QoS. Jedná se o obecný termín, označující celý obor zabývající se požadavky na přenos dat a jejich zaručení. V práci bude používáno buď českého termínu kvalita služby, nebo zkratky QoS. Často také když hovoříme o „QoSu“, máme na mysli již konkrétní řešení řízení toku dat, kterým ony požadavky plníme (nebo se alespoň pokoušíme plnit).
2.2 Prostředí linuxových routerů (směrovačů) Jak již vyplývá ze zadání této práce, bude problematika kvality služby řešena především na routerech realizovaných běžnými PC s operačním systémem Linux. Českým ekvivalentem pro router je slovo směrovač. Systémy založené
na
PC
s operačním
systémem
Linux
mohou
být
plnohodnotnou alternativou k jednoúčelovým zařízením, které někdy také bývají označovány jako „hardwarové“ routery, zejména pro sítě s menšími datovými toky. Velkou výhodou linuxových routerů je především větší univerzálnost a možnost upravovat konečné řešení než u routerů, kde jsou tyto funkce pevnou součástí poměrně jednoduchého operačního systému. Pro také mluví cena, která u linuxového routeru může být i několikanásobně nižší než u podobně výkonného jednoúčelového routeru. Univerzálnost ovšem může být brána také jako nevýhoda. Nemáme k dispozici hotové řešení, které stačí pouze nastavit. Naopak, u každé z potřebných vlastností routeru musíme vědět jakým způsobem ji zajistit, jaký musíme nainstalovat software a jak jej nastavit. Zmíněná výhoda v universalitě se rázem stává velkou nevýhodou.
2.3 Navrhování komplexních systémů pro řízení toku dat Pokud budeme mít povědomí o tom, co je to vlastně zajištění kvality služby, jaké jsou požadavky jednotlivých síťových služeb a jakým způsobem fungují na zvolené platformě (PC router s operačním systémem GNU/Linux) jednotlivé metody pro řízení toku dat, můžeme začít navrhovat komplexní systém pro řízení toku dat. 2
A návrh tohoto systému je také cílem mé práce.
2.4 Vymezení cílů práce a požadavků na navrhovaný systém 1) Cílem této práce je analyzovat typické situace pro nasazení QoS. Popsat jednotlivé části sítě a možnosti, jak na nich realizovat QoS. 2) Uvést a popsat jaké jsou nejvíce používané možnosti řízení toku dat pro zajištění QoS, které poskytuje router s operačním systémem Linux. 3) Na základě bodů 1 a 2 navrhnout systém, který bude zjištěné požadavky v bodu 1 řešit pomocí metod uvedených v bodě 2. Konkrétní řešení navrhnout pro síť Klfree.net. 4) Provést implementaci navrženého systému v bodě 3 v síti Klfree.net.
Hlavní požadavek na navrhovaný systém byl již uveden v zadání práce. Je jím zajistit co „nejlepší“ fungovaní funkcí služeb sítě z pohledu většiny uživatelů sítě.
3
3 Popis struktury práce ve vztahu k vytyčeným cílům První kapitola je úvodem s vysvětlením motivace pro napsání této práce. Popisuji zde jak jsem se vůbec dostal k výběru tohoto tématu pro práci. Druhá kapitola se zabývá cíli práce. Je zde vysvětleno několik základních pojmů a popsáno prostředí, pro které je práce určena. Na závěr kapitoly jsou vytyčeny konkrétní cíle práce. Třetí kapitola popisuje strukturu práce - rozdělení a obsah jednotlivých kapitol.
Další členění práce bude respektovat čtyři vytyčené cíle: Ve čtvrté kapitole popisuji kde a z jakého důvodu je potřeba používat QoS a jaké jsou nejrůznější požadavky na QoS uživatelů sítě. Zvýšená pozornost bude věnována bezdrátovým sítím a vysvětleno proč je zde použití QoS nezbytné. Čtvrtá kapitola tak řeší vytyčený cíl 1. Pátá kapitola se věnuje samotné realizaci metod na řízení toku dat prostředky, které jsou k dispozici v operačním systému Linux. Slouží jako seznámení s jednotlivými disciplínami a klasifikátory. Je tedy řešen cíl 2. Šestá kapitola práce řeší možnosti návrhu systému na základě předchozích úvah. Jsou zde popsány způsoby používané v praxi a jejich výhody a nevýhody, analyzovány jednotlivé části sítě postavené na linuxových routerech a nastíněno obecné řešení v těchto částech sítě. Pro prostředí sítě Sdružení Klfree.net je pak navrženo konkrétní řešení (cíl 3). Sedmá kapitola popíše implementaci navrženého řešení v síti Sdružení. Jakým způsobem bylo realizováno a testováno (cíl 4). Osmá kapitola je závěrem práce. Zde je zhodnocení realizaci jednotlivých cílů a přínosu práce. Jsou zde také uvedeny cíle budoucího vývoje implementovaného řešení.
Součástí práce jsou také následující přílohy: Dodatek A – seznam použitých zkratek Dodatek B – informace o Sdružení Klfree.net a síťovém prostředí této sítě Dodatek C – ukázka webového rozhraní routeru, kde je použité řešení z této práce Dodatek D – dokumentace skutečné implementace používané v síti Sdružení Klfree.net
4
4 QoS – Quality of service Tato kapitola má za cíl podrobné seznámení s problematikou kvality služby a různými požadavky aplikací na přenos dat.
4.1 Požadavky na přenos dat – kvalita služby Počítačové sítě a především celosvětová síť Internet prodělaly v poslední době obrovský rozvoj. Hlavně díky nástupu vysokorychlostních připojení se rozšířilo spektrum síťových služeb, které můžeme dnes využívat i z domova. Společnou vlastností síťových služeb je to, že vyžadují přenos dat. Rozdílné jsou ovšem požadavky na různé aspekty kvality tohoto přenosu. Některé služby vyžadují pro správnou funkci určitý garantovaný datový tok (např. přenos video signálu). Datovým tokem rozumíme množství přenesených dat v byte za jednotku času. Jiné služby požadují například rychlou odezvu nebo malý rozptyl odezvy (tzv. jitter). Některé naopak nemají požadavky téměř žádné (například přenos emailových zpráv). Právě uvedenou problematikou se budu zabývat v této kapitole.
4.1.1 Datová propustnost Velké množství služeb má požadavek na určitou datovou propustnost. Tento termín nelze zcela jednoznačně specifikovat, požadavky jsou různého typu. V některých případech – především u přenosů videa/zvuku v reálném čase (real-time), je klíčové zajistit datový tok pokud možno po celou dobu přenosu. Pokud se nám toto nepodaří zajistit, dochází k výpadkům (zasekávání způsobené ztrátou synchronizace, atd.) což výslednou kvalitu přenosu značně degraduje. V závislosti na tom, zda přenášíme pouze hlas či video signál, se potřebná hodnota může pohybovat od desítek kbit/s (přenos hlasu) až po řádově několik Mbit/s (málo komprimované video). U přenosu hovoru sice požadavky přenosové rychlosti pro jeden hovor bývají malé, ale je potřeba počítat s tím, že může být v jednom okamžiku uskutečněno velké množství hovorů a tím potřebná přenosová rychlost řádově větší. O přenosu hlasu prostřednictvím internetu mluvíme jako o „IP telefonii“, často se také používá anglická zkratka VoIP (Voice over IP). Jiným případem jsou datové přenosy, kde sice nevyžadujeme samotnou stabilitu přenosu jako u přenosu hlasu či obrazu, ale je pro nás omezující doba za kterou přenos 5
proběhne. Například při síťovém zálohování dat může být pro nás klíčové, aby tento proces proběhl v omezeném čase. Zálohovaný systém může být v průběhu zálohy nedostupný pro běžnou práci, je tedy potřeba dobu pro zálohování minimalizovat a načasovat na hodinu co nejmenšího použití systému. Pro běžného domácího uživatele je také důležité, aby nemusel na stažení souborů příliš dlouho čekat. Čekající uživatelé nebývají spokojeni se svým připojením. Většinou je také při volbě poskytovatele připojení k internetu brán největší ohled na hodnotu „rychlosti připojení“. Zde je nutné zmínit také dost opomíjenou hodnotu agregace. Často se totiž nejedná o garantovanou rychlost připojení, ale o rychlost maximální a právě hodnota agregace udává kolik dalších uživatelů sdílí tuto rychlost. Reálná rychlost může tak být i několikanásobně nižší než maximální.
4.1.2 Rychlost odezvy Kromě přenosové rychlosti je velice častým požadavkem rychlá a stabilní odezva neboli přenosová doba, kterou paket cestuje sítí od zdroje k cíli (také ji označujeme jako zpoždění (latenci)). Vyžadována je především již zmíněnými real-time aplikacemi, kterých je velice široké spektrum. V dnešní době je asi nejvýznamější přenos hlasu – internetová telefonie. Kromě požadavku na datový tok (řešeno v předchozí sekci) je pro telefonování prostřednictvím počítačové sítě nutné, aby přenos těchto dat proběhl co nejrychleji – s co nejkratší odezvou. Narůstající odezva se negativně projevuje na kvalitě spojení – přenos hovoru je opožděný. Mimo přenosu hlasu umožňují dnešní připojení k internetu také přenos videa (velice oblíbená je video telefonie prostřednictvím programu Skype). I v tomto případě musíme přenášet data s co nejmenší přenosovou dobou. Platí zde podobně jako u hlasu, že při dlouhých odezvách je přenos video signálu opožděný – může také docházet k vypršení časových limitů a rozpadu spojení. Dalším příkladem může být vzdálený přístup na jiný počítač/zařízení. Ať již v textové formě (například za pomoci protokolu ssh či telnet) či grafické (vzdálená plocha systému Windows, či multiplatformní protokol VNC). Při pomalé odezvě je práce s takovými službami obtížná a v extrémním případě až nemožná. Pokud jsou tyto protokoly používány pro vzdálenou administraci routerů na sítí, je žádoucí, aby je bylo možné použít při jakýchkoli podmínkách – i při jinak velmi přetížené lince. Nelze také zapomenout na méně profesionální použití - počítačové hry hrané po síti. Především u akčních her je nutné, aby se akce hráče přenášely co nejrychleji na 6
herní server a naopak odezva serveru zpět ke hráči. Hráči na „pomalých linkách“ bývají značně znevýhodněni oproti těm, jejichž odezvy jsou krátké. Kritické pro tuto oblast bývá překročení limitu pro odezvu (time-out) při které dochází například ke ztrátě určitých informací, opětovnému navazování spojení, či úplnému rozpadnutí spojení, kdy je hráč odpojen ze hry. V hráčské komunitě jsou problémy, ke kterým dojde díky pomalé odezvě, označovány slangovým výrazem „lag“.
4.1.3 Rozptyl přenosové doby – jitter Při přenosu dat může také rozptyl přenosových dob (angl. jitter) velice negativně ovlivnit kvalitu především opět real-timových služeb. Při internetové telefonii se projevuje různým zasekáváním hovoru, což vede až k úplnému zkomolení, kdy není hovoru téměř rozumět. Z tohoto důvodu je velký rozptyl pro telefonii ještě více problematický, než stabilně horší doba odezvy (hovor je sice se zpožděním ale je mu dobře rozumět).
4.1.4 Ztrátovost paketů Velice důležitým faktorem je také ztrátovost paketů při síťovém přenosu. Většina již dříve zmíněných služeb vyžaduje, aby ztrátovost přenášených dat byla co nejmenší. V okamžiku, kdy není z nějakého důvodu paket doručen, dochází k opětovnému poslání (retransmisi), což velmi negativně ovlivňuje až na výjimky většinu přenosů dat. Ztrátovost paketů bývá způsobena především poruchami sítě nebo značným přetížením spoje, kdy již nepostačují fronty pro odesílání paketů a další pakety jsou zahazovány.
4.1.5 Dostupnost služby Trochu jiným požadavkem než všechny předchozí je požadavek na dostupnost služby. Nejedná se o požadavek na vlastnosti samotného přenosu, ale na zajištění chodu služby specifikovaných parametrů. Dobrou dostupnost služby lze zajistit zejména zálohováním a předcházením chybám na všech úrovních. Příkladem může být použití záložních zdrojů pro případ výpadku napájení, nebo možnosti využití záložních spojů při výpadku spoje hlavního. Dostupnost služby bývá hlavně předmětem smlouvy mezi zákazníkem a poskytovatelem připojení. Poskytovatel garantuje například maximální dobu výpadku
7
služby, nebo maximální dobu reakce na vzniklý problém. Bývají také stanoveny sankce pro případ porušení těchto závazků.
4.1.6 Příklady požadavků služeb V následující tabulce uvádím shrnutí podavků některých z nejpoužívanějších služeb.
Název služby
Požadavky
IP telefonie (VoIP)
co nejmenší latence na přenášená data
Streamovaná hudba či video
garantovaná propustnost linky a nízký jitter
Počítačové hry hrané po síti
nízká latence
Interaktivní služby
nízká latence
Zobrazení www stránek
rozumná latence, rozumná propustnost, tak aby negativně neovlivnily uživatele
P2P sítě pro sdílení dat
z pohledu uživatele co největší propustnost, pohledy správců sítě bývají různé
Kritické systémy
garantování vysoké dostupnosti a odolnosti proti chybám (přenos videa při lékařských operacích, zajištění přenosu kamerového systému, zabezpečovacího či ovládacího systému budov a jiné. Nízká latence a dostupnost za jakýchkoli podmínek i při velké zátěži sítě.
Vzdálená administrace
Tabulka 1 – požadavky služeb
4.2 Nejčastější situace vyžadující použití QoS V této části proberu dvě základní modelové situace, ve kterých je vyžadována aplikace nějakého systému řízení toku dat pro zajištění potřebné kvality služby.
4.2.1 Nedostatečná přenosová kapacita linky Přenosová kapacita linky je vždy nějakým způsobem omezená. Kapacitu jednak omezují technické možnosti daného přenosového média (příkladem může být běžná telefonní linka - při použití přenosového protokolu V92 dosáhneme maximální přenosové rychlosti 56kbit/s; různé typy ethernetového rozhraní poskytují rychlosti 10,100,1000Mbit/s,...). Druhým velice častým limitujícím faktorem jsou pak smluvní vztahy (přípojku do internetu si pořizujeme o určité kapacitě, za kterou platíme poskytovateli připojení). 8
Dokud přenášíme méně než je tato kapacita, přenos probíhá v pořádku. Pakety odcházejí se zpožděním daným pouze použitou technologií. Problémy ale nastávají v okamžiku, kdy chceme přenášet více než umožňuje dostupná kapacita. Přípojkou 1Mbps nepoteče více než 1Mbit/s, protože si tuto rychlost platíme a poskytovatel omezuje propustnost právě na tuto hodnotu. Následkem větších požadavků na přenos než je dostupná kapacita dochází k zahlcení linky. Projevuje se nejprve nárůstem latence na přenášených paketech (toto se negativně projeví právě na telefonii, hrách, interaktivních službách) a při větším zahlcení již může docházet i ke ztrátě paketů. Způsobeno je to tím, že paket který není možné odeslat okamžitě, je za běžných podmínek zařazen do fronty a čekáním na odeslání narůstá latence. Paket který se ani do fronty nevejde (fronty nebývají nekonečné) je ztracen. Řešení této situace jsou obecně dvě. Buď zvětšit propustnost linky (např. nahradíme stávající 10Mbit prvky 100Mbitovými - jednoduché, ale většinou dosti drahé řešení), nebo lépe hospodařit se stávající kapacitou linky tak, abychom co nejlépe uspokojili naše požadavky. Lépe hospodařit znamená v našem případě samozřejmě aplikovat nějakou sofistikovanější metodu pro odesílání paketů.
4.2.2 Přenosové médium s nevyhovujícím řízením toku dat Kromě obecně nedostatečné přenosové kapacity se vyskytují i problémy spojené s vlastním přenosovým médiem. Zde se budu zabývat především technologií založenou na standardu 802.11a/b/g čili WiFi. Bezdrátové připojení prostřednictvím WiFi používá protokol CSMA/CA (Carrier-sense, multiple-access, collision avoidance) pro předcházení kolizím. Jeho součástí je možnost rezervace vysílání pomocí RTS/CTS protokolu, ale tato metoda nebývá příliš často používána (selhává zejména při rušení z cizího vysílače). Pro připojení koncových uživatelů se nejčastěji používá topologie point to multipoint – k centrálnímu vysílacímu přístupovému bodu je připojeno několik klientů (někdy i několik desítek). Podle návrhu je WiFi určena především pro použití uvnitř budov či na krátké vzdálenosti (indoor) [1]. Při použití na větší vzdálenosti za pomoci směrových antén pak nastávají problémy s provozem díky tomu, že jednotliví klienti vzájemně neslyší své vysílání. Dochází tak ke kolizím při současném vysílání více klientů a bez nasazení nějakého způsobu řízení přenosu k častým problémům. Při zátěži narůstá doba odezvy 9
způsobená retransmisemi a může též docházet ke ztrátovosti paketů (což většinou postihuje uživatele s horším signálem). Přínosem bývá zejména omezení toku dat od klientů směrem k přístupovému bodu.
4.3 Způsoby řízení toku dat V této sekci obecně popíši nejdůležitější metody používané pro řízení toku dat.
4.3.1 Type of service (TOS) Již samotná hlavička IP paketu obsahuje podporu pro zajištění základních požadavků služeb. Cílem osmibitového pole v hlavičce paketu je informovat o tom jaké jsou požadavky služby, která přenáší data. Používány jsou ale jen 3 bity, každý z nich určuje vlastnost – požadavek na nízkou odezvu, požadavek na velkou kapacitu a požadavek na velkou spolehlivost [2]. Při použití výchozího nastavení sítě na linuxovém routeru je právě tento příznak klíčový pro prioritu odeslání paketů. Pakety s nastaveným příznakem požadavku nízké odezvy jsou odesílány jako první, následují pakety s požadavkem na velkou propustnost a spolehlivost a úplně na závěr jsou odeslány pakety bez nastavených příznaků [4]. Pokud ToS příznaky nenastavujeme při vstupu paketu do kontrolované části sítě, je zde velké riziko zneužití ze strany aplikací, kde například programy pro P2P sdílení můžou nastavovat ToS příznaky tak, aby jejich data byla co nejvíce prioritizována.
4.3.2 Rezervační protokol RSVP Jedním z dalších komplexních systémů pro zajištění kvality služeb je rezervační systém založený na protokolu RSVP (Resource ReSerVation Protocol). Jeho rozšíření a podpora jsou ale malé, proto zde uvedu pouze myšlenku tohoto systému. Při požadavku na zajištění kvality služby posílá pomocí protokolu RSVP aplikace požadavek routeru, který pokud je mu možné vyhovět, rezervuje určitou datovou kapacitu pro tento přenos. Router, který přijímá žádost musí komunikovat s ostatními v síti tak, aby byla zajištěna rezervace na všech routerech, kudy paket při přenosu sítí půjde. Důvodem, proč tento systém nebyl nikdy moc rozšířen je jeho velká náročnost při rozsáhlé síti a nutnost, aby aplikace používaly specializovaný rezervační protokol.
10
4.3.3 DiffServ – differentiated services Nástupce myšlenky ToS. Tentokrát je používáno celkem 6 bitů v hlavičce IP paketu pro nastavení typu přenášených dat [2]. V závislosti na tomto poli pak je s paketem při průchodu sítí zacházeno. Platí zde stejné nebezpečí jako u systému používajícího ToS. Je nutné buď důvěřovat tomu, jak mají pakety nastavené pole DSCP v hlavičce již od aplikací, které je posílají, nebo toto pole na základě vyhodnocení paketu routerem přeznačit. Při dalším přenosu sítí toto pole již zpravidla nebývá měněno a routery ho používají k rozhodování o typu dat a prioritě. Tento systém je v dnešní době podporován u velkého množství jednoúčelových hardwarových routerů. Experimentální implementace existuje i pro linuxový router [3]. Výhodou tohoto systému je dobrá škálovatelnost. Analýza a značení paketů probíhá pouze při vstupu paketu do kontrolované sítě.
4.3.4 Traffic shaping Volně přeloženo do češtiny by tento pojem znamenal „tvarování provozu“, proto je spíše používán samotný anglický výraz. O traffic shapingu mluvíme vždy v souvislosti s metodami založenými na limitování průtoku dat. Problém kvality služby při přetížení přenosové kapacity řešíme vyčleněním určité části kapacity pro jednotlivé služby. Požadované služby pak mají zajištěnou dobrou kvalitu na úkor ostatních. Je tedy nutné rozpoznat které pakety patří kterým službám, aby tento systém byl efektivní. Postupuje se obecně dvěma cestami – již zmíněným vyčleněním služeb, u kterých nám záleží na dobré kvalitě služby, nebo opačným způsobem, kdy vyčleníme do omezeného pásma naopak ty služby, u kterých chceme omezit maximální datový tok (zejména služby založené na P2P sdílení). Lze použít i obou způsobů zároveň. V tomto případě zbytek nezařazených paketů může využít kapacitu, která nám zůstane po odečtení vyčleněných částí od celkové dostupné kapacity. Velice často se v názvech jednotlivých disciplín objevuje anglický název bucket – „kyblík“. Bucket zde vyjadřuje princip, že v případě překročení jeho kapacity dochází k přeplnění – data jsou zahazována.
11
4.3.5 Prioritizace Další množina metod pro řízení toku dat využívá rozmanité prioritizační algoritmy. Není zde brána v úvahu využitá přenosová rychlost, ale měníme pouze pořadí odesílaných paketů podle nějakých pravidel (scheduling). Prioritizace je oproti traffic shapingu podstatně jednodušší metoda. Rozlišujeme zde dva základní principy. Jednak klasické použití prioritních front, kdy pakety, které považujeme za více prioritní jsou odesílány dříve. Tato metoda je schopná zajistit pouze kvalitu služby pro nejvíce prioritizované pakety. Kvalita služby všech méně prioritizovaných skupin pak závisí na využití dostupné kapacity více prioritizovanými pakety (můžeme využít pouze to co nám zbývá). Druhou skupinou jsou pak algoritmy, které se snaží o zajištění jisté spravedlivosti odesílání. Na základě pravidel rozdělíme pakety do skupinek a pořadí odesílání volíme tak, abychom odesílali z těchto skupin rovným dílem. Při této metodě však nemáme již žádnou možnost zajistit pro vybrané služby požadovanou kvalitu služby. Při přetížení dochází i k rovnoměrnému přetížení všech služeb, což je ne vždy akceptovatelné. Proto při použití této metody ji často kombinujeme s nějakou formou traffic shapingu pro zajištění kvality služby požadovaným aplikacím.
4.3.6 Ostatní metody Kromě uvedených hlavních metod se setkáváme i se speciálními, které nejde jednoduše zařadit do některé kategorie. Jednotlivé příklady uvedu v části zaměřené na podporu disciplín pro řízení toku dat na linuxovém routeru.
4.4 Části sítě a možnosti jak zde realizovat QoS Síť, kterou tvoří linuxové routery, můžeme rozdělit z pohledu zajištění kvality služby na tři základní části. Vstup do sítě (místo připojení koncových zařízení), tranzitní část a výstup ze sítě (propoj do jiné sítě, přístup k serverům které poskytují služby apod.).
4.4.1 Vstup do sítě Toto místo (v žargonu poskytovatelů připojení označované jako tzv. „poslední míle“) má několik základních specifik:
12
-
jsou zde připojena zařízení, která většinou nemáme jakožto správci sítě pod kontrolou,
-
připojení je zde často realizováno způsobem P2M (point to multipoint),
-
bývá zde často použita technologie, kterou není možné jednoduše nahradit,
-
bývá zde často použita technologie, která je co nejlevnější na klientské straně.
Především poslední dva uvedené body předurčují, že se v tomto případě bude jednat o problematické místo – levná technologie bývá synonymem pro nedostatečnou kapacitu. Zejména realizace poslední míle na WiFi je zdrojem problémů a nezbytně vyžaduje nasazení nějakého způsobu řízení toku dat. V opačném případě často dochází k zahlcení sítě a silné degradaci kvality služeb. Další věcí, která ovlivňuje způsob zajištění kvality služeb, je také „politika“ vůči uživatelům sítě. Pokud jsme v síti komerčního ISP, tak právě zde většinou probíhá omezení rychlosti na úroveň odpovídající zaplacené službě, případně další prioritizace či shaping dle smlouvy se zákazníkem. Můžeme zde například zajišťovat prioritizaci paketů pro IP telefonii, případně dalších požadavků zákazníka. Také se stává, že ISP pouze omezí rychlost a případná prioritizace je pouze na připojeném zákazníkovi (typické pro menší ISP). Lze se setkat i s variantou, kdy na této úrovni žádné řízení toku dat neprobíhá. Omezování pak probíhá například centrálně až v místě výstupu ze sítě. V nekomerčních sítích bývá politika různá. Podobně jako u komerčních sítí mohou být zajišťovány požadavky na kvalitu služby přímo zde či až na výstupu ze sítě. Omezování rychlosti zde probíhá především z důvodu zajištění rovnocenného připojení a co nejlepší kvality služeb pro všechna připojená zařízení.
4.4.2 Tranzitní část sítě Zajišťuje přenos paketů mezi jednotlivými routery od zdroje směrem k cíli: -
zde máme plnou kontrolu nad přenášenými daty,
-
spoje mezi routery jsou vesměs realizovány jako P2P (point to point),
-
použitá technologie jde často jednoduše nahradit v případě, že nepostačuje,
-
páteřní spoje je žádoucí udržovat dostatečně dimenzované. Tuto část sítě máme tedy plně pod kontrolou a bývá jednodušší problémy
s nedostatečnou kapacitou řešit náhradou technologie. Jsou zde používány převážně jednodušší metody pro řízení toku dat. Důvodem je jednak zmíněný fakt, že zde bývá snaha používat dostatečně dimenzovanou technologii a zároveň se stoupající rozsáhlostí 13
sítě bývá problematické (zejména z důvodu velké výpočetní zátěže při velkých datových tocích) aplikovat nějaký složitější systém. Vhodnými metodami jsou například rozhodování pomocí IP adresy či nasazení systému na bázi DSCP.
4.4.3 Výstup ze sítě Výstup ze sítě je nejčastěji místem, kde je privátní síť připojena do globální sítě Internet. Zde je opět potenciální kritický bod z pohledu zajištění kvality služby. Ne vždy postačuje kapacita přípojky k internetu požadavkům uživatelů. Při méně rozsáhlých sítích je možné použít komplexní systém pro omezování jednotlivých uživatelů (zejména u komerčních ISP). U rozlehlých sítí je toto již dosti komplikované (při síti s tisíci aktivních zařízení a datovými toky v řádu stovek Megabit je již takřka nemožné pokoušet se řídit tok veškerých dat v síti centrálně). Většinou je zde naopak snaha data co nejrychleji odesílat, aby bylo dosaženo co největší propustnosti. Při použití metody DSCP uvnitř sítě je nutné na výstupu ze sítě provádět značení příchozích paketů. Toto není zcela triviální. Je potřeba značkovat pakety přicházející jako odpověď z vnější sítě. Například při požadavku na zobrazení stránky z webového serveru – data přicházejí směrem dovnitř do sítě a je potřeba tyto pakety „spárovat“ s odchozími daty téhož uživatele.
14
5 Metody pro řízení toku dat na Linuxu Cílem této kapitoly je popsat možnosti pro řízení toku dat v operačním systému Linux. Budou popsány součásti systému, které slouží pro řízení toku dat a nástroje pro jeho nastavení a uvedeny jednotlivé frontové disciplíny a klasifikátory, které jsou nejčastěji používány.
5.1 Základní principy Velice důležitým principem, kterého si musíme být vždy vědomi je fakt, že na běžně používaných technologiích v IP sítích jsme plnohodnotně schopni řídit vždy pouze odchozí tok dat (tzv. egress shaping). Čili pokud používáme pro přenos dvojbodový spoj a ovládáme pouze jednu stranu spoje, tak ve většině případů nemáme přímou kontrolu nad tím, co přijímáme.
5.1.1 Řízení toku Pokud je na druhé straně spoje zařízení, které máme také pod kontrolou, tak samozřejmě můžeme řídit provoz v obou směrech. Ale ne vždy je tomu tak. Například na routeru, který je připojen dále do internetu, tak v drtivé většině případů druhou stranu spoje realizuje ISP, takže nemáme žádnou možnost ovlivnit to, co nám pošle. Naštěstí díky vlastnostem TCP spojení jsme schopni řídit příchozí tok zprostředkovaně. TCP protokol automaticky snižuje rychlost odesílaných dat v případě, že nedostane včas potvrzení o přijetí [15]. Toho se využívá tak, že uměle snížíme další tok již přijatých paketů. Vysílač automaticky sníží rychlost odesílání a v důsledku nám tím poklesne i samotná rychlost přijímaných dat na rozhraní, které jinak nedokážeme přímo regulovat. Mluvíme zde o tzv. policingu. Bohužel, toto nefunguje u protokolů využívajících nepotvrzovaných spojení (např. UDP, ICMP). Zde nemusí existovat zpětná vazba na průchodnost paketů, je pouze věcí aplikace, aby nějaký systém potvrzování implementovala - obecně nic takového být nemusí. Proto jsou tyto protokoly často zneužívány k zahlcování sítě (tzv. flood). Útočník v tomto případě odesílá velké množství paketů a pokud má oběť k dispozici nižší přenosovou kapacitu než útočník, může dojít k úplnému zahlcení linky oběti. Často toto bývá kámen úrazu u bezdrátových technologií – WiFi, kde například i jeden z připojených klientů může svým vysíláním zcela ochromit přenos všech ostatních 15
(velmi často způsobeno zavirovanými PC a jejich pokusy o hromadné rozesílání emailů).
5.1.2 Frontové disciplíny (queue disciplines - qdisc) Vlastní řízení toku dat je realizováno pomocí frontových disciplín (angl. Queue disciplines, zkratka qdisc). Disciplína se navazuje na příslušné rozhraní, kterým odchází data, a řídí jakým způsobem budou data odeslána. Případně je možné i více disciplín vzájemně vnořovat (bude vysvětleno dále). Každá disciplína je v rámci svého zařízení identifikována pomocí 32bitového unikátního označení (handle), které se zapisuje ve formě dvou 16bitových čísel X:Y. Číslo X označujeme jako major number, číslo Y pak jako minor. Pro disciplíny je vždy minor number 0. Můžeme tak mít maximálně 216 disciplín na jednom zařízení. Na úrovni zdrojového kódu jsou frontové disciplíny realizované funkcemi: enqueue, dequeue, requeue, drop, init, reset, destroy a dump. Nejdůležitějšími jsou funkce enqueue a dequeue. Enqueue slouží pro zařazení paketu do disciplíny, dequeue naopak k jeho vyjmutí pro odeslání. Requeue je funkce pro případ, že by nebylo možno paket odeslat a bylo nutné ho zařadit zpět na místo odkud byl odebrán. Drop slouží pro zahození paketu (je využíváno disciplínami jako např. RED). Init, reset a destroy mají za úkol počáteční inicializaci disciplíny (init), její vynulování do původního stravu (reset) a její odstranění (destroy). Dump slouží k výpisu diagnostických informací. [4,5].
5.1.3 Třídy (classes) Třídy tvoří systém, který umožňuje pro různé služby uplatňovat různé metody řízení toku dat. Frontové disciplíny, které podporují třídy označujeme jako classful (např. HTB, prio). Disciplíny, které třídy nepodporují pak označujeme jako classless. Tradičně frontová disciplína s podporou tříd obsahuje několik podtříd a klasifikátor, který rozhoduje, do jaké třídy se má paket zařadit. Tyto třídy pak mají buď na sebe navázanou novou frontovou disciplínu, nebo další podtřídy a klasifikátor opět pro určení jak rozřazovat pakety. Třídy jsou označovány stejně jako frontové disciplíny pomocí 32bitového handle rozděleného na major a minor number. Pro potomky tříd platí, že mají vždy stejné major number jako jejich rodič.
16
Samotnému fyzickému zařízení je přiřazena kořenová frontová disciplína, kterou označujeme jako root qdisc. Veškeré zařazovaní (enqueue) a odřazování - odesílání (dequeue) probíhá pouze přes tuto disciplínu. Není možné přímo odeslat paket z nějaké třídy či frontové disciplíny uvnitř hierarchického stromu. Vždy je potřeba, aby proběhla postupná klasifikace směrem k listům stromu a poté naopak postupné zpětné odřazování paketů až do kořenové frontové disciplíny. Úkolem tříd je ovšem nejen třídit pakety či obsahovat frontové disciplíny, ale zároveň na úrovni tříd provádíme i shaping či jiné operace. Použití závisí na frontové disciplíně, která třídu používá - např. u HTB lze stanovit, jak velké datové toky mají třídy umožnit. Na úrovni zdrojového kódu jsou definovány následující funkce pro třídy: graft, get, put, change, delete, walk, tcf_chain, bind_tcf, unbind_tcf a dump_class. Graft slouží pro navázání frontové disciplíny na třídu, get vrací interní id a informace o třídě daného handle, change mění parametry uložené pro danou třídu, delete vymaže třídu, walk je využívána pro iteraci přes všechny třídy, tcf_chain vrací ukazatel na seznam klasifikátorů (filterů), které jsou navázány na třídu, bind_tcf slouží k navázání konkrétního pravidla filteru na třídu, unbind_tcf k odebrání pravidla filteru a konečně dump_class k výpisu diagnostických dat [5].
5.1.4 Klasifikátory (filters) K tomu, abychom mohli přiřadit pakety do tříd slouží klasifikátory. Klasifikátor je vždy navázaný buď na určitou třídu, nebo přímo na frontovou disciplínu a zpracovává pakety, které se do ní dostanou. Úspěšně klasifikované pakety jsou zařazeny do dalších tříd. Zde opět může být další klasifikátor, takže je tímto způsobem možné provádět klasifikaci na více úrovních. K dispozici je několik různě komplexních klasifikátorů, lze testovat vybrané informace v hlavičce paketu, kontrolovat příznak nastavený při průchodu iptables (mark), nebo dokonce i prohledávat samotný obsah paketu a snažit se takto rozpoznat jaká služba tento paket využívá. Na jednu třídu lze navázat několik klasifikátorů s různým nastavení priority s jakou se budou vyhodnocovat. V rámci klasifikátoru se pak definují pravidla, která určují kam zařadit pakety, které vyhovují zadaným podmínkám. Funkce definované na úrovni zdrojového kódu klasifikátorů jsou: classify, init, destroy, get, put, change, delete, walk a dump. Funkce classify slouží, jak název 17
napovídá, k otestování paketu klasifikátorem. Návratovou hodnotou může být buď struktura, která obsahuje třídu do které má být paket zařazen, nebo konstanta specifikující, že paket nebyl nikam zařazen. Init má na starost inicializaci klasifikátoru, kdy jsou nastaveny jeho parametry. Destroy – odstranění klasifikátoru – je volána funkce unbind_tcf na třídu ke které je klasifikátor navázaný. Get – podobně jako u tříd, vrací interní identifikátor klasifikátoru. Change mění nastavení daného klasifikátoru, delete slouží k odstranění pravidla = elementu ze seznamu pravidel klasifikátoru.Walk je určena pro iteraci přes všechny klasifikátory zejména pro získání diagnostických dat. Dump vrací diagnostická data o klasifikátoru a případně některých jeho pravidlech [5].
5.1.5 Průchod paketu routerem Po přijetí ethernetového paketu, který odpovídá MAC adrese síťového zařízení, (případně se jedná o broadcast na síťové úrovni) je paket nejčastěji pomocí DMA nakopírován do paměti a je voláno network RX softirq. Pokud procesor zpracuje toto přerušení, je řízení předáno packet handleru pro příslušný protokol. V případě IPv4 se jedná o IPv4 packet handler. S paketem je nejprve proveden test na kontrolní součet. Pokud je chybný, je paket zahozen a vracíme obsluhu systému. V opačném případě dochází k volání preroutingové části netfilteru. V tomto bloku (viz diagram na obrázku 1) prochází paket celkem čtyřmi různými procedurami. Nejprve prochází přes conntrack, což je systém pro evidenci již založených spojení. Používán je zejména při překladu adres (NAT) či při stavovém firewallu, kdy rozhodujeme podle toho v jakém stavu je dané spojení. Pokud se jedná o známé spojení, neprovádí se další procedury. V opačném případě přicházejí ke slovu pravidla uvedená v mangle a nat tabulkách iptables. Zde může dojít k označení (MARK) paketu v mangle tabulce, puštění paketu do IMQ zařízení (viz sekce o IMQ) - opět v mangle, či změně cílové adresy (DNAT) v nat tabulce. Další osud paketu závisí na tom, zda je paket určen přímo pro router, nebo pro jiný stroj. Pokud je určen pro router samotný, jsou zpracována pravidla INPUT řetězců tabulek mangle a filter v iptables a paket je předán lokálnímu procesu. Pokud je cílová adresa odlišná od adresy routeru, je paket předáván dál (za předpokladu povoleného předávání paketů - ip_forwarding). Paket prochází řetězci pravidel FORWARD tabulek mangle a filter iptables.
18
Další možností vstupu paketu do tohoto cyklu, je paket vygenerovaný samotným routerem. Takový paket prochází opět přes conntrack a dále přes OUTPUT řetězec v tabulkách mangle, nat a filter. Společně jsou na závěr zpracovávány jak odchozí, tak předávané pakety. Aplikovány jsou POSTROUTING řetězce v tabulkách mangle a nat. Také v tomto kroku je možné využít IMQ zařízení. Jako poslední paket prochází přes egress qdisc – frontovou disciplínu příslušného výstupního zařízení. Diagram - obrázek 1 na následující straně přehledně demonstruje celý průchod jednotlivými bloky[6].
19
Obrázek 1 – průchod paketu routerem
20
5.2 Nastavení systému Možnosti pro řízení toku jsou přímo v jádru (kernelu) Linuxu. Pokud využíváme jádro obsažené v distribuci, je potřeba zkontrolovat, zda obsahuje podporu pro metody, které budeme používat. Pokud ne, je nutná kompilace vlastního jádra s příslušnou podporou.
5.2.1 Kompilace jádra Zvolenou verzi linuxového jádra můžeme stáhnout na internetové stránce www.kernel.org, případně využít zdrojový kód jádra používaný na zvolené distribuci Linuxu (lze nainstalovat například na distribuci Debian pomocí služby apt). Zdrojový kód jádra, který takto získáme, již sám o sobě obsahuje dobrou podporu pro řízení toku dat. Standardní součástí jsou často používané frontové disciplíny a klasifikátory. Samozřejmě zdrojový kód jádra nemůže obsahovat úplně vše. Některé metody (např. podpora pro
IMQ zařízení) zde nejsou v současné době
zahrnuty. V tomto případě je potřeba získat příslušný „aktualizační kód“ – (patch) a kompilovat až upravené jádro. Při konfiguraci jádra prostřednictví metody make menuconfig najdeme nastavení funkcí pro řízení toku dat v sekci: Networking/ Networking options / QoS and/or fair queuing / (platné pro jádro 2.6.22). Zde máme možnost vybrat, které QoS metody a klasifikátory budou součást jádra, které budou zkompilovány jako moduly jádra a které nebudou k dispozici. Pokud jsme upravili zdrojový kód jádra o IMQ zařízení, je potřeba navíc povolit podporu těchto zařízení ( Device Drivers / Network device support / IMQ support ), zvolit způsob připojení těchto zařízení s ohledem na překlad adres (zda do IMQ zařízení půjdou pakety s již přeloženými adresami či nikoli) a povolit vazbu na iptables (Networking / Networking options / Network packet filtering framework (Netfilter)/IP Netfilter configuration/IMQ target support).
5.2.2 Balík iproute2 Instalační balík iproute2 (někdy označovaný pouze iproute) obsahuje velké množství praktických nástrojů pro práci se sítí na Linuxu. Především se jedná o nástroj „tc“ (odvozeno od traffic controller), pomocí kterého se nastavuje drtivá většina řízení toku dat na Linuxu.
21
Zdrojový kód balíku je ke stažení na internetu, případně opět můžeme využít jednoduchou automatickou instalaci již zkompilovaných nástrojů (Debian,Ubuntu – apt, Gentoo - emerge). Pro některé metody – např ESFQ (viz příslušná sekce) je nutné i tento balík kompilovat z upraveného zdrojového kódu pomocí příslušného patche.
5.2.3 Podpora v iptables Kromě čistého ovládání příkazem tc máme možnost využít široké prostředky, které nám poskytuje netfilter (iptables) prostřednictvím označování paketů speciálními značkami (mark) v mangle tabulce iptables. V závislosti na tom, jakou má paket značku máme potom při klasifikaci možnost rozhodnout, co s takovým paketem uděláme.
5.2.4 Použití příkazu tc Tc je program, který komunikuje se službami jádra, a umožňuje vytváření a nastavování metod pro řízení toku dat (frontové disciplíny, třídy, klasifikátory).
Základní syntaxe je následující:
tc [ OPTIONS ] OBJECT { COMMAND | help }
OBJECT := { qdisc | class | filter }
Objektem je zde tedy buď frontová disciplína, třída, nebo klasifikátor. COMMAND se používá nejčastěji jeden z následujících: add
přidá frontovou disciplínu, třídu, klasifikátor nebo pravidlo klasifikátoru. Vždy je nutné uvést rodiče – buď ve formě handle, nebo root – přímé připojení na zařízení.
remove
odstraní frontovou disciplínu definovanou opět buď přes handle, nebo kořenovou (root). Zároveň se odstraní i všechny třídy a klasifikátory na tuto disciplínu navázané (rekurzivně i všechny další frontové disciplíny, třídy a klasifikátory, které jsou navázány dál na tyto třídy.
change
modifikuje již existující frontové disciplíny, třídy, klasifikátory, za předpokladu, že tuto změnu umožňují.
replace
provede náhradu existující frontové disciplíny, třídy nebo klasifikátoru. Pokud nahrazovaná entita neexistuje, je nově vytvořena [7].
22
5.3 Jednotlivé frontové disciplíny V této části podrobněji popíši v současné době nejčastěji používané frontové disciplíny.
5.3.1 Pfifo_fast Pfifo_fast je výchozí disciplína používaná linuxovým jádrem v případě, že není uživatelem definována žádná jiná disciplína. Jak název napovídá jedná se o frontu, takže odesílání funguje tak, že paket který prvně přijde, ten také první odejde (first in, first out). Nemáme však pouze jednu frontu, ale fronty celkem tři se snižující se prioritou. Fronta 0 má při odesílání přednost před frontou 1 a fronta 1 před frontou 2. Pakety jsou zařazeny do příslušné fronty dle příznaků ToS (type of service) v hlavičce paketu. Přiřazení jednotlivých ToS lze pro fronty měnit. Standardně do nejvíce prioritizované fronty jsou zařazovány pakety s typem "minimum_delay". Už tedy tato jednoduchá disciplína zajišťuje prioritizaci paketů. Problémem ale je, že často nejsou příznaky ToS v síti nijak nastavovány, takže závisí pouze na aplikaci, jaký příznak při odesílání paketu použije. Aplikace může celkem snadno zneužít prioritní frontu této disciplíny pro zvýšení propustnosti paketů na úkor ostatních. Velikost fronty v paketech je dána nastavením rozhraní. Lze jí změnit například příkazem ifconfig eth0 txqueuelen 100 (nastaví rozhraní eth0 délku fronty 100) [7].
5.3.2 Pfifo a bfifo Ještě jednodušší než pfifo_fast jsou tyto dvě disciplíny. Oproti pfifo_fast používají pouze jednu frontu bez rozlišení příznaku ToS. Zpracovaní tak probíhá pouze s minimální výpočetní náročnosti. Dalším rozdílem je to, že u těchto disciplín můžeme přímo nastavit velikost používané fronty (u pfifo v počtu paketů, u bfifo v počtu bytů). Obě disciplíny také podporují výstup statistik o počtu bytů a paketů, které přes ně prošly. Často se používají u složitějších disciplín jakožto koncové poddisciplíny tříd. Tímto způsobem je používá například frontová disciplína HTB jako výchozí disciplíny pro třídy, které tvoří listy hierarchické struktury. Syntaxe přiřazení těchto frontových disciplín je: tc qdisc ... add pfifo [ limit packets ] tc qdisc ... add bfifo [ limit bytes ]
23
Pokud není uveden parametr limit, je pro pfifo použita hodnota txqueuelen specifikovaná pro použité rozhraní. Pro bfifo je pak tato hodnota vynásobena navíc hodnotou MTU (maximum transfer unit – velikost největšího možného odesílaného paketu v bytech) [7].
5.3.3 TBF - Token Bucket Filter Disciplína, která umožňuje odesílat data určenou rychlostí. Metodu si lze představit tak, že máme kbelík (bucket = buffer), který plníme zadanou rychlostí speciálními "lístky" (tokeny). Paket, aby mohl být odeslán, potřebuje tento lístek. Nastávají zde tři typické situace: 1) Data, která mají být odesílána přicházejí se stejnou rychlostí jako tokeny. V tomto případě se tedy odesílají bez zpoždění. 2) Data přicházejí pomaleji a hromadí se nám tak tokeny. V případě nárůstu toku dat je možné čerpat nahromaděné tokeny a odesílat data rychleji než je běžná rychlost. 3) Data přicházejí rychleji. Po vyčerpání tokenů narůstá zpoždění odesílaných dat, a po naplnění fronty pak dochází k zahazování paketů. TBF tedy umožňuje odesílání paketů danou rychlostí s možností krátkodobého nárůstu rychlosti (burst). Tuto hodnotu můžeme nastavit parametrem tak, aby nedocházelo k příliš velkým burstům při rychlém vyprázdnění plného bucketu tokenů. Parametry: limit or latency slouží k nastavení velikosti bufferu pro odesílání dat. Buď hodnotou limit (počet byte bufferu), nebo latency – což je maximální čas, který může paket čekat ve frontě. burst
velikost bucketu pro tokeny v bytech. Určuje tak zároveň maximum tokenů, které mohou být dostupné v bucketu. Pro větší přenosové rychlosti je nutné, aby byla tato hodnota dostatečně velká, jinak hrozí situace, že se bude přeplňovat bucket (a tím budeme ztrácet tokeny) rychleji než budeme zvládat odesílat data.
mpu
Minimum Packet Unit. Minimální velikost kterou vždy odebereme z bucketu pro paket. Započítává overhead protokolů, kdy i paket s nulovou velikostí dat bude díky hlavičkám pro ethernet minimálně 64B velký.
24
rate
nastavení rychlosti na kterou limitujeme odesílání (= generování tokenů).
peakrate
maximální rychlost vyprazdňování bucketu, pokud chceme zabránit velkým skokům.
mtu/minburst
nastavení bucketu pro rychlé vyprazdňování. Běžně nastavené na MTU hodnotu rozhraní. Větší hodnota umožňuje i přes nastavenou peakrate propouštět pakety o něco rychleji [7].
5.3.4 SFQ - Stochastic Fairness Queueing Disciplína používaná pro spravedlivé rozdělení linky. Nepoužívá shaping, ale pouze řídí pořadí odesílání dat (prioritizace). Snažíme se tak rozdělit dostupnou kapacitu mezi všechny aktuální spojení a zabránit situaci, kdy jedno spojení využívá celou kapacitu linky. Pojem spojení (flow) sfq chápe tak, že při zařazení paketu do této frontové disciplíny je provedeno hašovaní podle hodnoty vzniklé složením zdrojové adresy, cílové adresy a zdrojového portu. Pokud protokol nepoužívá hodnotu portu, použije se místo ní číslo protokolu. SFQ vytváří se malé fronty pro jednotlivé hašovací klíče, které tím odpovídají jednotlivým spojením. Odřazování paketů z disciplíny (dequeue) pak probíhá pomocí round robin algoritmu nad těmito frontami. Tento systém si ale bohužel neporadí se situací, kdy nějaký program pro přenos využívá velké množství otevřených spojení na různé IP adresy (zejména P2P sítě). Uživatel, který pro přenos využije 100 spojení, je 100krát zvýhodněn před někým, kdo přenáší data pouze jedním spojením (např. klasický ftp přenos). Parametry: perturb
doba v sekundách mezi přepočítáním hašovací tabulky. Při velkém počtu spojení se jich mnoho hašuje se stejným klíčem. Aby tato situace netrvala dlouho, zavádí se „promíchání“, které tabulku přeorganizuje. Výchozí hodnota je 0 (není prováděno). Při použití se doporučuje hodnota 10s.
quantum maximální počet bytů, které jsou při dequeue odeslány. Doporučená a výchozí hodnota odpovídá MTU rozhraní [7].
5.3.5 ESFQ – Extended verze SFQ Rozšířená verze SFQ se snaží řešit problém se znevýhodňováním aplikací využívajících velké množství spojení tak, že se pro hašování nepoužívá složení zdrojové 25
adresy, cílové adresy a zdrojového portu spojení, ale nabízí volbu tohoto kritéria, například hašování pouze podle zdrojové či cílové IP adresy. Spravedlnost je v tomto případě zajišťována na úrovni IP adres, čímž nejsou zvýhodněny aplikace používající více spojení. Zůstává zde však problém s tím, že uživatelé používající více adres jsou zvýhodnění nad těmi, co jich mají málo. ESFQ není standardní součástí zdrojového kódu jádra, je tedy nutno aplikovat příslušné patche pro jádro a balík iproute a provést vlastní kompilaci. Parametry: Kromě parametru perturb a quantum jako u SFQ, zde můžeme ještě nastavit: Limit, depth, divisor – parametry pro určení velikosti hašovací tabulky Hash - metoda pro určení hašování. K dispozici jsou: classic – originální metoda používaná u SFQ. dsc, src,
fwmark – hašování podle zdrojové, cílové IP adresy, nebo podle
iptables mark ctorigdst, ctorigsrc, ctrepldst,ctreplsrc – hašovaní pomocí adres braných z conntrack tabulky – používá se při NATu. ctnatchg - "Conntrack NAT change" – hašování pokud zároveň používáme i DNAT (destination NAT) pro příchozí spojení [8].
5.3.6 RED – Random Early Detection RED je speciální disciplína využívající zpomalovací vlastnosti TCP spojení. Hlavní myšlenkou je zde zabránit špatnému chování front při přeplnění. V okamžiku přeplnění fronty dochází k zahazovaní všech paketů, které se již do fronty nevejdou. Není žádná kontrola nad tím, co zahodíme, a co ne. RED toto řeší tak, že k zahazovaní nedochází až při přeplnění fronty, ale průběžně s rostoucí pravděpodobností již při částečném zaplnění fronty. Aplikace (postavené na TCP) tak pružněji reagují na nedoručení některých paketů snížením rychlosti odesílání. Kromě zahazování, je možné pakety pouze označovat (příznakem overlimit). Bohužel, tento systém selhává pro aplikace, které využívají jiných protokolů (především UDP) a nemají implementovaný potvrzovací systém, který reaguje na špatnou odezvu snížením rychlosti. Přesto však je RED dobrou volbou pro použití zejména na páteřní síti. Jednoduchý princip vyžaduje pouze minimální výpočetní čas. Parametry:
26
min
průměrná velikost fronty, při které začne docházet k zahazování nebo označování paketů. průměrná velikost fronty, při které je pravděpodobnost pro zahození či
max
označení maximální. probability maximální pravděpodobnost pro zahození (označení). Nastavuje se desetinným číslem od 0 do 1 doporučená hodnota je 1-2% (0.01 – 0.02). limit
celková velikost fronty. Pokud dojde k její naplnění jsou další pakety zahazovány.
burst
doporučená hodnota = (min+min+max)/(3*avpkt) . Ovlivňuje závislost aplikace min a max podle skutečné velikosti fronty a tím jak rychle dojde k zahazování (značení) paketů.
avpkt
velikost průměrného paketu použitá pro vnitřní kalkulace – doporučená hodnota 1000B
bandwidth
hodnota použitá pro kalkulaci průměrné velikosti fronty – měla by být nastavena na rychlost používaného rozhraní. volba, zda rovnou zahodíme pakety (drop), či je pouze označíme (mark)
ecn
[7].
5.3.7 Prio Prio je disciplína, která je postavena na principu tříd. Narozdíl od všech předchozích uvedených disciplín, které třídy nepodporují (označujeme jako classless), prio umožňuje vytvoření libovolného počtu tříd pro prioritní fronty. Při odesílání paketů se nejprve prohlédne fronta s největší prioritou a potom postupně další méně prioritizované. Základní rozdíl oproti pfifo_fast je v tom, že počet front u prio není nijak omezen (pfifo_fast používá pouze 3) a také do těchto front můžeme zařadit cokoli co potřebujeme dle zvoleného klasifikátoru (pfifo_fast rozlišuje pouze podle ToS příznaku). Příklad hierarchického sytému tříd a několika navázaných disciplín demonstruje obrázek 2.
27
1:0 kořenová disciplína (root qdisc) | 1:1 třída navázaná přímo na root qdisc
1:10 1:11 1:12 třídy (class) – potomci třídy 1:1 11:0
dále nerozvětvená frontová disciplína (qdisc)
10:0 12:0 další frontové disciplíny (qdisc) / \ / \ 10:1 10:2 12:1 12:2 třídy – navázané na disciplíny 10 a 12
Obrázek 2 – hierarchický systém tříd
V tomto příkladě tedy root třída 1:0 (automaticky vytvořená kořenovou frontovou disciplínou) obsahuje potomka 1:1, který se dále dělí na 3 podtřídy 1:10, 1:11 a 1:12. Na tyto podtřídy jsou navázány nové frontové disciplíny (10:0, 11:0 a 12:0). Dvě z nich se obsahují dělení na další podtřídy (10:1, 10:2, 12:1, 12:2) [4]. Pro zařazení paketů do příslušných tříd využijeme vhodné klasifikátory.
5.3.8 DSMARK Jednoduchá disciplína, která neprovádí vlastně nic jiného, než že převádí hodnotu pole DSCP hlavičky paketu na interní proměnnou tc_index a naopak může také nastavovat na základě umístění ve třídě hodnotu DSCP paketu při dequeue operaci. Proměnná tc_index se dále využívá pro klasifikaci paketů. Třídy definujeme s parametrem mask a value, podle kterých je při odřazení nastaveno pole DSCP v hlavičce paketu. Parametry: indices - počet položek v tabulce mask/value = maximální počet tříd, které můžeme vytvořit (hodnota musí být mocninou 2)
5.3.9 HTB - Hierarchical Token Bucket Frontová disciplína HTB zajišťuje traffic shaping na úrovni rozdělení kapacity pro jednotlivé třídy. Disciplína vznikla na základě starší CBQ (Class Based Queueing), často se používá zejména pro jednodušší a více intuitivní nastavení než je tomu u CBQ.
28
Základním parametrem každé třídy HTB je hodnota označovaná jako rate, která udává jakou rychlostí mají být odesílány data této třídy. Třídy tvoří stromovou strukturu, kdy vždy jedna třída může mít několik potomků. Pokud dosáhne tok uvnitř libovolné třídy hodnoty rate, tak má navíc možnosti si „vypůjčit“ od třídy nadřazené. Pokud je tok v této třídě také na hodnotě rate, může si opět vypůjčit od své rodičovské třídy atd. Takto se lze dostat až ke třídě kořenové – zde si již není kde půjčovat, takže hodnotu rate přesáhnout nelze, data musí čekat ve frontě na odeslání. Někdy ovšem požadujeme, aby byla rychlost třídy omezena na určitou hodnotu, bez možnosti dostat více. K tomu slouží parametr ceil (strop), který určuje celkové maximum dat, které třídou může protékat - HTB neumožní odesílat pakety dané třídy rychleji než je takto nastaveno. Toho lze využít například pro omezení daného uživatele na rychlost, kterou si zaplatí. Následující příklad demonstruje použití HTB. Mějme k dispozici linku o kapacitě 1Mbit/s. Používáme www server, poštovní server a ftp server. Našim cílem je zajistit jednotlivým serverům co nejlepší podmínky pro chod. Rozhraní přiřadíme HTB frontovou disciplínu a nejprve nadefinujeme mateřskou třídu o celkové dostupné kapacitě. Obě proměnné rate i ceil v tomto případě nastavíme na 1Mbit. Dále vytvoříme 3 podtřídy pro data jednotlivých serverů. Ceil všech tří bude opět 1Mbit - zajistíme tak, že v době, kdy nebude některý ze serverů aktivní, budou zbývající moci využít veškerou dostupnou kapacitu linky. Rate pro jednotlivé třídy nastavíme například 300kbit pro www server, 200kbit pro poštovní server, a 500kbit pro ftp server. V případě, že všechny 3 severy budou současně odesílat data, kapacita linky se rozdělí v tomto poměru rate. Pokud některý ze serverů nebude využívat celého svého pásma, tak se jeho část použije, a rozdělí mezí ostatní. Linka se tak využívá optimálně. Samozřejmě nemusíme dělit kapacitu pouze podle služeb. HTB poskytuje téměř neomezené možnosti pro rozdělení linky dle našich potřeb. Pokud jsme například ISP, můžeme dělit linku mezi naše klienty podle toho, jakou službu nám platí. Velice snadno lze nastavit často prodávané "sdílené linky", kdy několik (i desítky) zákazníků se dělí o smluvně danou kapacitu principem agregace. Sdílená rychlost je dělena mezi ty, co zrovna přenáší data. Parametry frontové disciplíny: default - třída do které se zařadí pakety, které se nepovedlo klasifikovat Parametry tříd: 29
prio
při odřazování jsou brána nejprve třídy s nižším prio
rate
„garantovaná“ rychlost dané třídy
ceil
maximum pro třídu, které nikdy nemůže překročit
burst hodnota v bytech pro odesílání paketů při krátkodobém překročení rychlosti rate cburst hodnota v bytech pro odesílání paketů, které mohou být odeslány maximální možnou rychlostí, kterou rozhraní umožňuje [9].
5.4 Klasifikátory Z předchozího výkladu máme tedy povědomí o základních frontových disciplínách a třídách, které některé z nich používají. Zbývá tedy uvést jak pakety do jednotlivých tříd rozdělit.
5.4.1 U32 klasifikátor U32 je jedním z nejčastěji používaných klasifikátorů (universal 32bit comparisons with hashing), který umožňuje podle informací v hlavičce paket zařadit do definované třídy. Při běžném použití porovnáváme nejčastěji zdrojovou nebo cílovou IP adresu paketu, případně u protokolů TCP nebo UDP pak hodnotu zdrojového nebo cílového portu. Samozřejmě můžeme porovnávat cokoli co hlavička paketu obsahuje. Jak již bylo naznačeno dříve, U32 využívá seznamu pravidel obsahujících podmínky pro úspěšnou klasifikaci (podobně jako třeba iptables pravidla). Je možné mít více těchto seznamů (při přidání pravidla zvolit do kterého seznamu bude přiřazeno) na základě identifikátoru – označován opět jako handle. Handle je tentokrát tvořeno třemi částmi – X:Y:Z, kde X identifikuje hašovací tabulku, Y „bucket“ uvnitř této tabulky a Z je umístění v rámci samotného seznamu pravidel. Rozlišení hašovacích tabulek a bucketu je spjato s možností hašování nad danou částí hlavičky (většinou se jedná o zdrojovou či cílovou IP adresu). Tímto způsobem je možné rychle rozřazovat další testovaní pravidel do jednotlivých seznamů a tím značně urychlit vyhodnocování. Pokud nepoužijeme tohoto způsobu, probíhá vyhodnocení sekvenčně, což při velkém množství pravidel a velkých datových tocích může být zdrojem problémů. Pokud si ale vystačíme s relativně malým množstvím pravidel, nemusíme si s ručním nastavením handle a hašovaním příliš lámat hlavu. U32 pokud není explicitně
30
uvedeno, tak hodnotu handle generuje automaticky (vytváří sekvenční seznam pravidel, které jsou postupně vyhodnocovány). Syntaxe přiřazení u32 klasifikátoru: tc filter add dev IF [ protocol PROTO ][ (preference|priority) PRIO ][ parent CLASS ] protocol – protokol, ke kterému se klasifikátor vztahuje (v našem případě vždy IP) priority – priorita vyhodnocení seznamu pravidel – 0 největší parent – handle třídy, na kterou se má klasifikátor navázat
Syntaxe vytvoření pravidla: tc filter add ... match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET] u32/u16/u8 – určuje kolika bitové porovnávání chceme provádět pattern – testovaná hodnota mask – vymaskování bitů, které chceme testovat at OFFSET – kolikátý byte od začátku hlavičky porovnávat at nexthdr+OFFSET – offset od začátku hlavičky dalšího protokolu (např. TCP nebo UDP) [7, 10].
5.4.2 FW – netfilter mark Další silnou zbraní při klasifikaci paketů je „fw“ klasifikátor, který využívá označování paketů pomocí „netfilter mark“ v iptables. Možnost klasifikace se nám tak plně přesouvá do režie iptables. Zde existuje velké množství efektivních nástrojů pro třídění paketů. Opět velice jednoduše můžeme testovat údaje obsažené v hlavičce paketu, nebo také i přímo v samotných datech. Dobrým příkladem využití iptables je L7 filter. Jedná se o modul do iptables, který je schopen podle obsahu paketu (nikoli pouze hlavičky, ale analýzou dat dle shody na definované regulární výrazy) rozpoznat nejčastěji používané protokoly. Toto se používá zejména na detekci P2P protokolů pro sdílení dat, které je jinak obtížné klasifikovat na základě údajů v hlavičce (portu) [11]. Nevýhodou je výpočetní náročnost testování, která tento systém dělá při velkých datových tocích nepoužitelným.
31
Příklad přiřazení pravidla fw klasifikátoru: tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1 - pravidlo, které pakety s fw-mark 6 zařadí do třídy 1:1
5.4.3 ROUTE – Routing decision Jinou možností klasifikace je rozřazovaní na základě parametru Realm, při vytváření routovacích pravidel. V pravidle využívajícím route klasifikátor jednoduše uvedeme, do jaké třídy pakety kterého realmu zařadit. Klasifikaci podle routovacích pravidel využíváme v situacích, kdy routujeme pakety na základě nějakých podmínek. Často se jedná o zdrojovou adresu – v tomto případě routování označujeme jako „source routing“. Příkladem použití source routingu a klasifikace podle routovacích pravidel je situace, kdy současné využíváme více přípojek do internetu. Na úrovni routovacích pravidel určujeme, kterou z cest budou pakety odeslány, a v závislosti na tom jak budou pakety klasifikovány pro QoS. Příklad použití klasifikátoru route: ip route add 192.168.10.0/24 via 192.168.10.1 dev eth1 realm 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 route to 10 classid 1:10 -
první příkaz vytvoří pravidlo pro routování rozsahu 192.168.10.0/24 s Realmem 10
-
druhý příkaz pakety, které měly Realm 10 zařadí do třídy 1:10
5.4.4 TCINDEX – Traffic-Control Index Poslední klasifikátor, který uvedu, provádí zařazování na základě předchozího označení ve frontové disciplíně DSMARK. Při zařazení paketu do této disciplíny jsou převedeny hodnoty DSCP do proměnných v paměti a je možné na jejich základě provést klasifikaci do tříd [12]. Tato klasifikace se používá na páteřních routerech, kde se určuje řízení toku dat na základě již dřívějšího nastavení DSCP paketu při vstupu paketu do sítě.
32
5.5 IMQ Speciální metodou pro řízení toku dat je použití IMQ (The Intermediate queueing device). Je to jedna z možností jak řídit příchozí datový tok. Trik spočívá ve vytvoření speciálního zařízení (realizovaného přes modul jádra), do kterého můžeme přes mangle tabulku iptables "poslat" data. IMQ zařízení se chová jako klasické fyzické zařízení (eth0 apod.) a máme možnost mu přiřadit některou z frontových disciplín. Nejčastější využití spočívá v jednoduché aplikaci, kdy do jednoho IMQ zařízení posíláme všechny příchozí pakety z některého fyzického rozhraní a pomocí shapingu průchod těchto paketů omezujeme (provádíme policing). Využíváme tak již dříve zmíněné vlastnosti TCP spojení, kdy při vypršení časových limitů pro potvrzení o doručení paketu, dochází ke snížení rychlosti odesílání dat. Samozřejmě máme možnost pomocí IMQ realizovat i složitější mechanizmy. Pomocí pravidel v iptables můžeme rozhodnout, které pakety pošleme do určitého IMQ zařízení [13].
33
6 Návrh komplexního systému V této kapitole nejprve uvedu několik používaných systémů pro řízení toku dat. Dále shrnu požadavky a možné řešení pro jednotlivé části sítě tvořené linuxovými routery. Na závěr kapitoly pak navrhnu konkrétní řešení pro síť Klfree.net.
6.1 Příklady v praxi používaných řešení Nejčastěji se používají dva systémy traffic shapingu – rozlišující pakety podle portů nebo podle IP adres. V této sekci oba způsoby podrobně popíši a uvedu vždy i návrh realizace na linuxovém routeru. Jako třetí možnost řešení uvedu použití Diferential Services.
6.1.1 Shaping na úrovni portů Prvním popsaným systémem bude využití klasifikace paketů v závislosti na použitém portu. Pakety s cílovým/zdrojovým portem odpovídající určité službě jsou zařazeny do zvláštních tříd o zadané přenosové rychlosti.
Způsob realizace na linuxovém routeru Použijeme HTB frontovou disciplínu. Vytvoříme hierarchický systém tříd, kdy kořenová třída bude mít nastavenou rate/ceil dle použité přenosové technologie. Dceřiné třídy pak budou určeny pro jednotlivé síťové služby (například www, pop3, voip, ssh). Dále vytvoříme default třídu, která bude sloužit pro pakety, které nebyly úspěšně klasifikovány. Rate/ceil pro třídy volíme dle preferencí. Především kapacita pro VoIP by měla být dostatečná pro odhadované maximum současně vedených hovorů. Klasifikaci můžeme provádět prostřednictvím u32 klasifikátoru nebo kombinací pravidel v iptables a fwmark klasifikátoru. Záleží pouze na tom, co je pro nás výhodnější implementovat. Například pokud dynamicky sestavujeme pravidla firewallu v iptables, je výhodnější využít u32 klasifikátor, aby se předešlo případným kolizím při vytváření a rušení pravidel v iptables.
Výhody a nevýhody tohoto řešení Výhodou je bezesporu jednoduchost. Takto navržený systém může běžet na všech routerech v síti, bez nutnosti složité konfigurace. Jako jediným parametr pro
34
nastavení postačuje přenosová rychlost použitého spoje. Ostatní parametry (rate/ceil podtříd) mohou být odvozeny od celkové přenosové rychlosti. Nevýhod je několik. Především snadné obelstění tohoto systému ze strany uživatele sítě. Zejména programy pro P2P sdílení dat umožňují nastavení portu pro komunikaci. Jednoduché nastavení těchto programů tak, aby používaly porty běžně používané jinými službami, vede k zařazení paketu do jinak omezené třídy. Dalším problémem je špatné chování na bezdrátových technologiích WiFi. Pokud si mohou třídy půjčovat až do celkové teoretické kapacity linky, často se stává, že vysílání jednoho z klientů tímto způsobem zcela zahltí celý přístupový bod. Shaping zde selhává, protože dochází ke ztrátě paketů od klientů s horším signálem již na nižší síťové úrovni – při bezdrátovém přenosu.
Nasazení v praxi Řízení toku dat na tomto principu je využíváno především v komunitních sítích pražského czfree. Často bývá kombinováno s centrálním omezováním dle IP adresy (viz následující sekce) v bodě připojení do internetu. Tímto se docílí jednak dobré kvality služby pro komunikaci uvnitř sítě, a zároveň dobré dělby přípojky do internetu pro jednotlivé uživatele. Právě přípojka do internetu bývá v tomto případě často „úzkým hrdlem“.
6.1.2 Shaping na úrovni IP adres Tento systém je podobný předchozímu uvedenému s tím, že klasifikace je postavena na IP adresách. Do tříd tak budou zařazeny pakety vždy od určitého uživatele sítě.
Způsob realizace na linuxovém routeru I v tomto případě HTB frontová disciplína. Kořenová třída má race/ceil dle rychlosti technologie a podtřídy mají rate/ceil dle poskytovaných služeb uživatelům sítě. Také máme možnost vytvořit podtřídy společné pro několik uživatelů a tímto způsobem definovat agregaci připojení. Uživatelské třídy vytvořené jako potomci této společné agregační třídy budou moci využívat kapacitu až do úrovně ceil agregační třídy. Na úrovni uživatelských tříd můžeme dále provádět shaping dle portů, a tím zajistit lepší kvalitu služby pro tyto uživatele.
35
Výhody a nevýhody tohoto řešení Takto definované řešení je vhodné zejména na koncové body sítě. Buď pro místo, kde jsou připojeni uživatelé, nebo naopak pro místo, kde pakety opouštějí námi regulovanou síť (přípojka do internetu). Problémem je ale nasazení na páteřní spoje mezi routery, kde bychom museli klasifikovat všechny potenciální uživatele, jejichž pakety přes tento router mohou procházet. Toto může být velice komplikované především při použití dynamického routování, kdy přes spoj mohou v případě výpadku procházet i data z odlehlých částí sítě, která běžně routujeme zcela jinými cestami.
Nasazení v praxi Tento způsob využívají často různé firmy působící jako lokální ISP. Zákazníkům limitují rychlost připojení buď přímo v bodě připojení, nebo naopak až na výstupu ze sítě – vnitřní komunikace v rámci sítě nebývá častá, nebo je speciálně ošetřena. Při absenci QoS na páteřních spojích je nutné, aby byly dostatečně dimenzované a nedocházelo na nich k zahlcení. Často bývá prevencí proti přetěžování páteřní sítě tzv. FUP – Fair User Policy, kdy v případě překročení datového limitu uživatele za jednotku času (nejčastěji měsíc) dojde k jeho omezení na nižší rychlost. Uživatelé jsou pak nuceni k tomu, aby regulovali množství přenesených dat a vyvarovali se snížení přenosové rychlosti na nepříjemnou úroveň. Jelikož je omezení ve formě FUP v dnešní době velmi nepopulární, většina velkých poskytovatelů internetu od něj ustupuje – zřejmě je jejich infrastruktura páteřní sítě na dostatečné úrovni na to, aby si to mohli dovolit.
6.1.3 Systém postavený na Differential Services Defferential Services je komplexní systém pro síť. Rozlišené je zde chování při vstupu paketu do sítě a při průchodu sítí.
Použité frontové disciplíny a klasifikátory Při vstupu paketu do sítě je nutné paket náležitě označkovat. Většinou totiž nelze důvěřovat tomu, že bude správně označen uživatelským zařízením. To, jakým způsobem provést značení je velmi rozmanité. Označeny mohou být pakety podle portu, případně použít i přímo analýzu dat pro důslednější rozpoznání typu služby. V tomto případě například značením přes L7 filter v iptables, a aplikací požadovaného shapingu (může být i zcela nezávislý na značkování pro DSCP). 36
Uvnitř sítě na spojích mezi routery pak používáme DSMARK frontovou disciplínu a tcindex klasifikátor pro rozřazení paketů do jednotlivých tříd. To, jakým způsobem dále pracujeme s třídami může být opět velice variabilní. Příkladem může být vytvoření HTB struktury tříd s různě definovanými rate parametry.
Výhody a nevýhody tohoto řešení Výhodou je podpora pro DSCP u hardwarových routerů (např. fy. Cisco [14]). Je tedy možné mít heterogenní síť složenou nejen z routerů na bázi PC s Linuxem, ale vhodně zařazovat i tyto HW routery tam, kde je to výhodné. Nevýhodou je fakt, že se jedná již o poněkud složitější systém pro konfiguraci, a pro správnou funkci ho musí používat všechny routery v síti. Pro páteřní spoje lze využít i značně jednodušší techniky na bázi SFQ či RED, které plní podobnou úlohu bez nutnosti důsledného označování paketů.
Nasazení v praxi DSCP se experimentálně používá především na některých internetových páteřních sítích [3]. Bohužel informace o těchto pokusech jsou nyní již poněkud zastaralé a nepodařilo se mi nalézt novější příklad efektivního použití.
6.2 Návrhy řešení pro jednotlivé části sítě Po uvedení používaných řešení v této části shrnu požadavky na navrhovaný systém, které vyplynuly z předchozích analýz. Na jejich základě pak navrhnu obecné řešení pro jednotlivé části sítě.
6.2.1 Konkrétní požadavky Základním požadavkem je zajistit kvalitu některých preferovaných služeb. Jedná se zejména o rychlou odezvu pro systémové služby – konkrétně ssh protokol, telnet protokol, DNS protokol a protokoly používané pro dynamické routování (ospf). Dále je prioritou dobrá funkce IP telefonie na bázi SIP protokolu. Jelikož se bude tento systém používat především v nekomerční síti, tak druhým hlavním požadavkem je zajistit v síti co možná největší rovnost uživatelů. V komerční síti by bylo toto jednodušší, zde platí, co si kdo zaplatí, to se mu snažíme zajistit. Navrhovaný systém by také měl být použitelný pro bezdrátové připojení uživatelů. Čili bránit zahlcení sítě některým z klientů. 37
6.2.2 Návrh řešení pro část sítě s připojenými uživateli Z požadavků uvedených v předchozí sekci vyplývá, že potřebujeme jednak vyčlenit a zajistit kvalitu služby pro některé služby a zároveň zajišťovat rovnost uživatelů. Toho můžeme zajistit například tak, že provedeme nejprve klasifikaci dle portu těchto protokolů. Pakety požadovaných služeb budou zařazeny do vlastních tříd, u kterých určíme kolik z kapacity linky jim bude přiděleno. Dalším stupněm klasifikace pak bude zařazení zbylých paketů do tříd pro jednotlivé uživatele. Na této úrovni můžeme omezovat rychlost každého z nich + nastavit vhodnou agregaci dostupné kapacity. Z hlediska třetího požadavku – připojení přes WiFi je toto výhodné, protože máme možnost nastavit maxima (ceil) jednotlivým třídám, a tak zabránit nežádoucímu přetížení přístupového bodu. Není příliš vhodné zavádět velké množství prioritizovaných služeb. Při definovaní klasifikačních pravidel pomocí kombinace protokol/port hrozí zneužití ze strany uživatelů. Při detekci služby podle obsahu paketu může být problémem velká výpočetní náročnost. Samotná realizace může být provedena přes HTB frontovou disciplínu s použitím SFQ pro jednotlivé třídy. V rámci třídy tak bude probíhat prioritizace zaměřená na rovnost všech spojení.
6.2.3 Návrh řešení pro tranzitní část sítě Zde se nacházíme uvnitř kontrolované části sítě, kde pakety procházejí spoji mezi jednotlivými routery. Pokud použijeme technologii s dostatečnou rezervou v kapacitě spoje, tak samozřejmě není potřeba používat žádnou techniku QoS. Zajímá nás tedy opačný případ, kdy se mezi routery vyskytne spoj, na kterém dochází k zahlcení. V praxi tato situace může nastat například i při poruše primárního spoje a přepnutím na spoj záložní, který zpravidla nebývá dimenzovaný na plnou kapacitu. Velice dobré výsledky zde poskytuje jednoduché nasazení frontové disciplíny ESFQ s hašováním pomocí zdrojové či cílové IP adresy. Je ovšem dobré, stejně jako v místě připojení uživatelů, vyčlenit opět některé síťové služby do speciálních tříd tak, aby nedocházelo při velkém zahlcení k jejich špatné funkci. Například vypršení časových limitů pro DNS dotazy se může projevit chybami všech služeb, používajících tyto jmenné služby. Velká odezva pro ssh protokol může znemožnit vzdálenou správu routerů postižených nějakým problémem. 38
Realizaci provedeme prostřednictvím HTB frontové disciplíny. Do vlastních tříd budou klasifikovány systémové služby. Pro řízení uvnitř těchto tříd použijeme SFQ disciplín. Neklasifikovaná data budou zařazena do jedné společné třídy a na tu pak navázána ESFQ disciplína. Použití zdrojové nebo cílové IP adresy pro hašování záleží na směru, kterým obvykle potečou rozhraním data. Pro směr k uživateli volíme cílovou IP adresu (spojení uživatelů ji budou mít stejnou pro daného uživatele). Pro směr od uživatele pak zdrojovou (opět shodná pro všechna spojení uživatele). Pokud budeme vycházet z předpokladu, že dimenzujeme páteřní síť tak, aby k přetížení nedocházelo na mnoha místech a často, je nasazení značkování na bázi Differential Services zbytečně komplikované řešení.
6.2.4 Návrh řešení pro místo připojení k internetu Obecně se nemusí jednat pouze o připojení k internetu, ale o jakékoli místo propojení, kde odchází pakety ze sítě pod naší kontrolou. Zde může také v mnoha případech docházet k zahlcení. Nejvíce připadají v úvahu frontové disciplíny RED či opět ESFQ. Podobně jako v ostatních částech sítě je dobré vyčlenit systémové třídy pro zajištění administrace a funkce základních síťových protokolů. Zda použít RED či ESFQ, nemusí být zcela jednoznačné. ESFQ zajišťuje lepší spravedlnost při rozdělování kapacity linky, RED má lepší chování při odesílání paketů – zpomalování je plynulejší. Obě metody nejsou příliš výpočetně náročné a zvládají i velké datové toky. Výsledná volba je tedy spíše experimentální záležitostí, kde se porovná nasazení obou metod v praxi. Při menší síti zde můžeme také aplikovat HTB a klasifikaci provádět podle IP adres podobně, jako v místě připojení uživatelů. Pro efektivnější použití je vhodné hašovat klasifikační pravidla podle části IP adresy.
6.3 Návrh řešení pro síť Klfree.net V této sekci navrhnu již konkrétní řešení pro použití v síti Klfree.net. Narozdíl od předchozích spíše obecných návrhů budu vycházet ze specifické situace v této síti.
6.3.1 Specifika sítě Klfree.net S postupem času (a s nárůstem finančních zdrojů) zůstaly jako víceméně jediným problematickým místem v siti Sdružení Klfree.net koncové bezdrátové
39
přístupové body. Páteřní spoje se při nedostatečné kapacitě nahrazují lepšími technologiemi (viz část o místech pro nasazení QoSu). Konektivitu do internetu je možné objednat o požadované kapacitě. Nicméně koncové WiFi vysílače tímto způsobem vylepšovat nelze (z důvodu použité technologie a omezeného množství vysílacích kanálů), takže především pro ně musím navrhnout vhodné řešení. Pro ostatní části sítě budou postačovat jednoduché systémy.
6.3.2 Problematika WiFi Na většině přístupových bodů Sdružení je v pásmu 2,4GHz používána technologie 802.11b. Jedná se o starší technologii s maximální přenosovou rychlostí 11Mbit (novější standard 802.11g nabízí až 54Mbit) [1]. Důvody pro použití tohoto standardu jsou dva. Jednak velké množství členů bylo připojeno v době, kdy zařízení pro 802.11g nebyly na trhu ještě vůbec dostupné, či byly velice drahé. Nutit tyto členy, kterým vše dobře funguje k nákupu nového zařízení by nebylo snadné. Druhým důvodem je fakt, že provoz přístupového bodu na bázi 802.11g je náchylnější k problémům s rušením. Což zejména v Kladně jako takovém, kde používá WiFi velké množství různých subjektů, je velice palčivý problém. Kromě zařízení v pásmu 2.4GHz se používají i přístupové body v pásmu 5.4GHz (802.11a). Zde je snaha tuto technologii používat pouze pro připojení větších domovních sítí v panelových domech. S větším počtem klientů se stává provoz problematičtější, tato zařízení jsou více náchylná na rušení a špatně fungují při horším signálu. Navrhování vhodného QoS systému pro WiFi není jednoduché. Obecně při překročení určité úrovně zatížení dochází k nárůstu odezvy. Bez regulace maximální propustnosti je běžné, že se odezvy pohybují v řádu 500-1000ms. S těmito hodnotami je téměř nemožné provozovat telefonii, hrát internetové hry, či prostřednictví ssh protokolu vzdáleně administrovat nějaký systém. Je proto naprosto nezbytné omezit rychlost tak, aby se odezvy pohybovaly ještě v rozumných hodnotách. Praxí ověřené vhodné hodnoty jsou pro průměrnou odezvu okolo 50ms a pro maximální do 100ms. S omezením rychlosti je ovšem spojeno dost problémů. Jednak je WiFi halfduplexní technologie, čili zařízení nemůže současně vysílat a přijímat. Pokud tedy chceme omezit rychlost linky, musíme toto omezení nějak rozdělit mezi upload (provoz směrem od klientů) a download (provoz směrem ke klientům).
40
Maximální přenosové rychlosti se při použití 802.11b pohybují okolo 5Mbit/s. Pokud chceme ale stanovit pevné omezení pro rychlost, tak můžeme použít například jen 3Mbit pro download a 2Mbit pro upload. Preferovaný je většinou download. Jednak kvůli zájmům uživatelů, tak také z technického hlediska. Upload je více problémový díky kolizím při současném vysílání klientských zařízení. Stanovení přesných hodnot je věcí experimentální. Záleží na rušení, vzdálenosti a hlavně počtu připojených klientů. V praxi, když uživatel sám stahuje na přístupovém bodě, může při ideálním signálu dosáhnout i rychlosti kolem uváděných 5Mbit/s. Jenže pokud je uživatelů více, už toto ve většině případů neplatí. Lze považovat za úspěch, když se podaří zajistit rozumné odezvy při celkovém reálném vytížení kolem 4Mbitu (2.5Mbit download, 1.5Mbit upload).
6.3.3 Návrh řešení pro WiFi Z předchozího tedy vyplývá, že budeme potřebovat omezit zařízení jako celek a zároveň uvnitř vytvářet nějakou další strukturu omezení. K tomuto účelu samozřejmě poslouží HTB frontová disciplína, kde rate/ceil kořenové třídy nastavíme právě na požadovanou rychlost v tomto směru. Pro řízení uploadu použijeme IMQ zařízení, do kterého budou svedeny všechny příchozí pakety z tohoto zařízení a řízení toku provedeme pomocí HTB stejně jako pro download. Dále v souladu s obecným návrhem oddělíme systémové protokoly do speciálních tříd, aby byla zaručena jejich dobrá kvalita. Jedná se především o protokoly DNS, ssh, telnet, a pakety používané pro dynamické routování ospf. Je také žádoucí vyčlenit ICMP pakety pro lepší diagnostiku problémů. Dále už zbývá jen přenos připojených členů. Zde je účelné každému přiřadit vlastní třídu. Jelikož třídy HTB poskytují statistiky, kolik dat přes ně prošlo, můžeme snadno každému členu počítat, kolik přenesl dat. Na základě toho pak aplikovat systém, který označím jako dynamický FUP. Jeho cílem je v závislosti na aktuálně přenášených datech provést omezení rychlosti. Důvod byl již zmíněn dříve v souvislosti s shapingem podle portu. Je rizikové dlouhodobě umožnit uživateli používat velké procento z maximální kapacity. Projevuje se zde velmi negativní skutečnost, že ostatní uživatelé pak již nedokáží přenášet dostatečné množství dat na to, aby byl ten, který využívá většinu přenosové kapacity, nějak omezen. Jejich přenosy jsou díky velkým odezvám a ztrátovosti paketů zabrzděny mechanizmem TCP protokolu a z pohledu HTB, které dohlíží nad třídami, tito uživatelé téměř nic nepřenášejí. Mohou tedy půjčovat svou 41
kapacitu uživateli, který naopak přenáší hodně dat a celý systém se stane velice neefektivním. Budeme tedy brát součet přenesených dat pro všechny IP adresy člena (tudíž ti, co jich mají více, nejsou nijak zvýhodněni) a při dosažení určitého množství dat za poslední hodinu mu postupně omezovat rychlost dle nastavení. Ve výsledku tedy bude platit, že bude mít každý člen dynamicky definované maximum a větší rychlosti nebude moci dosáhnout ani v případě, že linka není vytížena na maximum. Je to sice tvrdé omezení, které brání efektivnějšímu využití kapacity, ale dá se tak předejít mnoha problémům a zároveň zachovat dostatečnou rychlost připojení pro každého. Množství omezení závisí na daném přístupovém bodě. Tam, kde jsou členové k sobě vzájemně ohleduplní (zejména sami omezují rychlost stahování) vše funguje lépe a není potřeba tolik systémově omezovat. V jiných případech je přísné omezení bohužel jediná možnost jak dosáhnout rozumné kvality služeb pro všechny připojené.
6.3.4 Řešení v ostatních částech sítě Tam, kde nejsou přímo připojeni uživatelé a kapacita linky je dostačující, použiji řešení na bázi kombinace HTB s ESFQ. Opět budeme mít možnost nastavit celkové maximum pro propustnost linky a vyčlenit důležité síťové protokoly do speciálních tříd. Samotná uživatelská data však již nebudeme dál členit do tříd, ale bude stačit použít na tuto třídu jako celek ESFQ, které bude zajišťovat rovnoměrné rozložení toku dat mezi jednotlivé IP adresy. Hranici sítě směrem do internetu není potřeba ve Sdružení aktuálně nijak řešit. Gigabitová přípojka do NIXu je vytížená ve večerních špičkách na cca 20% kapacity, zahraniční konektivita je zajišťována sdružením NFX a nakupována podle aktuální potřeby (v současné době 450Mbps). V případě potřeby je zde možné nasadit jednoduchý systém na bázi RED frontové disciplíny, kde stanovíme pouze dostupnou kapacitu celkové linky.
6.4 Srovnání navrženého řešení s jinými systémy Navržené řešení komplexněji řeší koncové připojení uživatelů s ohledem na možnost připojení přes WiFi. Jelikož byl dříve nasazen systém traffic shapingu převzatý z czfree (založený na klasifikaci dle portů) mohu poměrně dobře porovnat tyto dva systémy. Špatné chování systému využívajícího klasifikaci dle portů bylo i jedním 42
z hlavních důvodů návrhu systému nového. Praktické zkušenosti potvrdily, že preventivní omezení rychlostí jednotlivých členů má velký přínos a zabraňuje přetížení přístupového bodu. Srovnání se systémem využívajícím čistě klasifikaci dle IP adres není příliš možné. Toto řešení lze použít pouze tam, kde máme daný počet zákazníků a u každého specifikovanou hodnotu omezení. Pokud nepoužijeme agregaci, tak je nutné mít k dispozici dostatečnou přenosovou kapacitu k zajištění garantovaných rychlostí uživatelům. Navržený systém je oproti tomu určen pro prostředí, kde se snažíme co nejefektivněji rozdělit veškerou dostupnou kapacitu mezi uživatele sítě. Poslední srovnání se systémem na bázi Differential services bylo již víceméně zmíněno dříve. Navržený systém je v tomto směru jednodušší – nevyžaduje označování paketů při vstupu do sítě. Při průchodu paketu sítí tak může docházet k více problémům při krátkodobém přetížení sítě, a tak k potenciální horší kvalitě služby. Pokud ovšem budujeme páteřní síť dostatečně robustní a dimenzovanou, tak těmto problémům dostatečně předcházíme a jednodušší řešení by mělo zcela postačovat.
43
7 Implementace V této poslední kapitole popíši samotnou implementaci navrženého systému tak, jak je používán v síti Klfree.net.
7.1 Popis Implementace Systém je implementován skupinou skriptů napsaných, až na několik výjimek, v programovacím jazyce Perl. Navržen je modulárně tak, aby ho bylo snadné rozšířit v případě jiných budoucích požadavků.
7.1.1 Inicializace systému O inicializaci a zavedení základních pravidel se stará skript setup-qos. Parametry jsou <start | stop | restart> [seznam rozhraní]. Skript při spuštění načítá společnou konfiguraci ze souboru /etc/default/qos, kde je mimo jiné uvedena cesta k adresáři, ve kterém jsou umístěny konfigurační soubory pro jednotlivá rozhraní. Tyto konfigurační soubory jsou pojmenovány vždy qos-
. Při parametru start skript načte konfiguraci pro zadané rozhraní z příslušného konfiguračního souboru a přiřadí rozhraní HTB root disciplínu. Dále jsou vyčleněny pakety systémových síťových služeb (pravidly u32 klasifikátoru - klasifikace dle portu a protokolu - ssh, dns apod.) a těmto přiřazeny zvláštní třídy tak, aby měly zajištěny i při vytížené lince dostatečnou přenosovou kapacitu. Parametry rate/ceil těchto tříd jsou buďto pevně dané, nebo spočteny z nastavené celkové přenosové rychlostí rozhraní. Zbývající pakety jsou svedeny do jedné třídy. Dle volby modulu v konfiguraci se poté spustí příslušný řídící skript.
V současné době jsou k dispozici 2 následující moduly:
basic - aplikuje pouze ESFQ disciplínu na třídu jako celek. Procházející pakety se odesílají cca rovnoměrně v závislosti na cílové či zdrojové IP adrese (lze nastavit konfiguračním parametrem). Jednoduchým způsobem se tak zajistí lepší rozložení provozu mezi jednotlivé IP adresy. Používá se zejména pro páteřní spoje, kde je potřeba zajistit jistou rovnováhu provozu.
44
userap - modul určený pro použití na koncových klientských přístupových bodech. Při startu tohoto skriptu je spuštěn démon, který provede inicializaci a v pravidelných intervalech provádí aktualizace systému.
V případě, že je v konfiguračním souboru uveden parametr queues= je zároveň při inicializaci tohoto zařízení vytvořeno příslušné IMQ, do kterého jsou v iptables přivedena příchozí data. Skript tedy zajistí: nahrání modulu jádra imq, nastavení link up na tomto imq, přidání pravidel -j IMQ do iptables a spuštění další instance skriptu setup-qos start pro toto imq zařízení. Při volbě parametru stop je smazána kořenová frontová disciplína nad tímto zařízením a pokud je spuštěn démon modulu userap, tak je informován o tom, že nad tímto zařízením nemají být prováděny aktualizace. Volba restart provede po sobě činnost jako při parametrech stop a start. Pokud při spuštění inicializačního skriptu neuvedeme žádné zařízení, je zvolená operace provedena na všechny zařízení pro něž existuje konfigurační soubor.
7.1.2 Konfigurace basic modulu Základními parametry jsou: type=basic
- aktivuje modul basic
speed=2000 - nastaví celkové maximum odchozích dat pro toto zařízení hash=dst
- src nebo dst
Parametr "hash" určuje, zda se pro hašování použije zdrojová (src) nebo cílová (dst) IP adresa. Výchozí hodnotou je "dst" pro "normální" výstupní zařízení a "src", pokud jde o IMQ (řízení vstupu).
7.1.3 Konfigurace userap modulu Základními parametry jsou: type=userap
- aktivuje modul userap
speed=2000
- nastaví maximum odchozích dat pro toto zařízení
queues=imqX
- určení zařízení pro omezení uploadu
ping=1
- povolení pingání a penalizace
descr="popiseke"
- nastavení popisku na www routeru.
45
Dále lze definovat parametry specifikující detailní chování shapingu (uvedené hodnoty slouží jen jako příklad použití):
limit1=15000000
- množství přenesených dat pro aplikaci penalty1
limit2=75000000
- hranice pro penalty2
penalty0=80
- výchozí podíl z celkové kapacity zařízení v procentech
penalty1=50
- omezení rate/ceil v procentech při dosažení limit1 dat
penalty2=30
- omezení rate/ceil v procentech při dosažení limit2 dat
nopingpenalt=50
- omezení při neodpovídání na ping
Další možnosti konfigurace jsou uvedeny v návodu pro konfiguraci – dodatku D.
7.1.4 Implementace userap modulu Modul se sestává ze zaváděcího skriptu, 3 nezávislých skriptů (userapd, is_updater.pl, pinger.pl) a 4 knihovních modulů (UserapCommon.pm, UserapHtml.pm, UserapParser.pm, UserapTcTools.pm). Zaváděcí skript je velice jednoduchý, jeho víceméně jediným účelem je spuštění skriptu démona (userapd) na pozadí. Knihovna UserapCommon.pm obsahuje společné proměnné, které využívají jiné funkce a má na starost načtení informací ze souboru /etc/default/qos. UserapParser.pm obsahuje funkce pro ukládání a načítání datových souborů na disk. Knihovna
UserapTcTools.pm
-
funkce
pro
manipulaci
s třídami
a
filtry
prostřednictvím příkazu tc. Poslední UserapHtml.pm - funkce pro generování html výstupu statistik. Useapd tvoří jádro systému a spouští jednotlivé operace. Hlavní cyklus lze stručně popsat takto: 1) Načteme statistiky stávajících tříd o tom, kolik dat uživatelé přenesli (funkce UserapTcTools::parseTcStatus) a přidáme aktuální hodnoty do struktury, ve které je uložena historie. 2) Spustíme na pozadí skript pro aktualizaci IP adres členů (is_updater.pl) a chvilku počkáme. Spuštění na pozadí je nutné z důvodu, že skript stahuje informace z www serveru prostřednictvím aplikace wget, která se za některých podmínek může zaseknout. Tím, že spustíme tento skript na pozadí, zabráníme celkovému zaseknutí systému.
46
3) Pokud nastaly nějaké změny IP adres členů, provedeme celkovou inicializaci tříd. Jinak zkontrolujeme změny v nutnosti omezení jednotlivých členů podle přenesených dat a pokud nějaké jsou, tak je provedeme. Po aplikaci všech změn uložíme informace o aktuálním stavu do souboru na disk. 4) Vygenerujeme html stránku, ve které jsou informace o aktuálních omezeních a množství stažených dat členů. 5) Spustíme proces pinger.pl, který kontroluje odezvy IP adres členů a v případě problémů, či žádné reakce na ping, provede automatické omezení. 6) Uspíme skript na dobu definovanou v konfiguračním souboru. 7) Opakujeme celý cyklus znovu od bodu 1.
Samostatný skript is_updater.pl slouží ke stažení informací o uživatelských IP adresách z informačního systému Klfree.net. Zde jsou data uložena v SQL databázi a export generuje dle požadovaného adresního prostoru výstup v xml formátu. Součástí dotazu je také časová známka poslední aktualizaci. Pokud v informačním systému nedošlo ke změnám, je stažen pouze soubor obsahující tuto časovou známku. Ušetří se tak poměrně náročný dotaz do databáze. Pokud obsahuje nově stažený soubor platná data, je porovnán se starým a změny se aplikují pouze pokud se liší. Poslední ze skriptů – pinger.pl má na starost testování dob odezev na IP adresy členů. Tato procedura z důvodu snížení síťové zátěže probíhá tak, že nejprve je proveden test pomocí dvou malých paketů pro zjištění, které z IP adres členů reagují na ping (ICMP paket ping request). Pro každého člena je vybráno pouze jedna IP adresa pro další důkladnější měření odezvy. Toto měření se sestává z poslání 20 ICMP ping request paketů – tentokrát jsou pakety posílány o velikosti 1200 B. Při horším signálu totiž mohou malé pakety procházet bez problémů, ale pro větší může již docházet ke ztrátovosti. Na základě výsledků je vygenerován jednak textový soubor s výsledky (pro možnost dalšího zpracování) a také html soubor pro snadný přehled na www serveru routeru. Také jsou vytvořeny soubory pro nastavení automatického omezení členů, kteří buďto vůbec neodpovídají na ping (ač jejich zařízení na úrovni arp protokolu komunikuje), nebo mají špatnou odezvu na ping (preventivní omezení pro předcházení problémů na celém přístupovém bodě).
47
7.1.5 Instalace Instalační balík je k dispozici na serveru goldheart.klfree.net. Pro aktuální verzi je to: http://goldheart.klfree.net/~skudlik/qos/klfree_qos-2.2.3.tar.bz2. Je také obsažen na CD přiloženém k mé práci.
O instalaci se stará jednoduchý skript, který nakopíruje soubory na potřebné místo. Tento způsob je použit, protože v současné době distribuce klfree debian, pro kterou je instalace určena nepodporuje žádný balíčkovací systém. Protože je tato distribuce navržena pro routery s malým diskovým prostorem (místo pevných disků se používají paměťové karty Compact Flash), je nutné šetřit a zahrnout do distribuce pouze nejnutnější nástroje. Po instalaci je potřeba manuálně spustit inicializační skript setup-qos s parametrem start.
7.2 Dokumentace Po celou dobu vývoje je zpracovávána online dokumentace uložená ve Twiki Sdružení. Jedná se o systém podobný online encyklopedii Wikipedia, který je určený pro spolupráci více autorů (tzv. Groupware). Výhodou tohoto řešení je možnost doplňovat nové poznatky jakýmkoli registrovaným uživatelem Twiki. Dokumentace je také uvedena v dodatku D této práce.
7.3 Testování V prvopočátcích vývoje bylo testováno chování systému na routeru, který nebyl používaný pro běžný provoz. Zde jsem testoval především správné chování jednotlivých frontových disciplín a klasifikátorů. Další testování po dobu vývoje bylo prováděno již experimentálním použitím v reálném provozu. Síť Sdružení Klfree.net je pro tento způsob ideálním místem. Připojení členové Sdružení se tak stali dobrovolnými testery správného chování QoSu. Nová verze je vždy nejprve nasazena na několik routerů v síti. Skripty se ladí nejdříve na úrovni informačních hlášek, které při běhu vypisují, následně pozorováním výsledků statistik na www rozhraní routeru. Důležitá je i zpětná vazba ze strany připojených členů, kteří případné problémy většinou rychle hlásí.
48
Mezi nejdůležitější signály pro testování patří jednak množství přenesených dat jednotlivými členy, grafy celkových přenášených dat přes jednotlivá rozraní routeru a doba odezvy na ping z centrálního monitorovacího serveru. Pro tvorbu grafů přenesených dat byl použit systém hotsanic, pro monitorování doby odezev monitorovací systém smokeping. Dále je prováděno nepřetržité monitorování sítě prostřednictvím aplikace nagios. Ta také automaticky v případě problémů emailem upozorňuje příslušné správce. Nově jsou také zaznamenávány doby odezev přímo na jednotlivé členy speciálním modulem pro systém hotsanic. Po úspěšném otestování v malém měřítku je pak tato verze rozšiřována na ostatní routery sítě. Při velkých změnách je k dispozici distribuční skript, kterým lze rozkopírovat nové soubory na všechny routery v síti, jinak je věcí místních správců Nodů, zda si novou verzi nainstalují na svoje routery, či zůstanou u staré. Při vydání nové verze distribuce klfree-debian se také snažím, aby v ní byla začleněna nejnovější stabilní verze skriptů pro QoS.
7.4 Ověření funkce systému Pro ověření správné funkce dynamického omezování rychlosti jsem provedl pokusné měření. Systém byl nastaven na 2400kbit/s pro download a 1200kbit/s pro upload. Penalizace pro omezení pak 50,45 a 30%. Nejdříve jsem provedl test pro download. Cyklicky jsem přenášel velký testovací soubor z routeru. Systém po inicializaci neměl načteny informace o IP adresách členů, proto umožňoval využít veškerou nastavenou kapacitu (300kB/s = 2400kbit/s). Po aktualizaci z databáze informačního systém bylo správně zavedeno omezení na 50% z dostupné kapacity. Omezení je na grafu vidět v čase 20:50. Při další aktualizaci v čase 20:55 pak došlo k dalšímu omezení na 45% díky tomu, že byl překročeno nastavení limit1 pro přenesená data. V čase 21:00 došlo následně i k překročení hodnoty limit2 a bylo zavedeno omezení na 30%, které zůstalo aktivní až do konce testu downloadu. Jako druhý byl proveden test uploadu. Nyní jsem přenášel data naopak z testovací stanice na router. Stejně jako při předchozím testu systém nejprve neměl načteny informace z informačního systému, proto umožňoval přenos plnou nastavenou rychlostí (150kB/s = 1200kbit/s). V čase 21:22 byla provedena aktualizace a jelikož už byla překročena hodnota limit2, došlo rovnou k omezení na 30%.
49
Výsledky jsou vidět v grafu na obrázku 3. Zelenou barvou je vyznačen download, červenou upload.
Obrázek 3 – graf funkce dynamického omezení rychlosti
50
8 Závěr a plány do budoucna V práci jsem úspěšně naplnil všechny čtyři vytyčené cíle. Provedl jsem analýzu situací pro nasazení metod řízení toku dat pro zajištění požadované kvality služby, uvedl nejvíce používané možnosti, jaké jsou k dispozici na systému s operačním systému Linux a navrhl a implementoval řešení pro prostředí sítě Sdružení Klfree.net. Výsledkem je systém, který je v současné době provozován na více než stovce linuxových routerů v síti Sdružení Klfree.net a dále používán i v několika podobných sdruženích. Jako největší přínos se v praxi ukázalo omezování WiFi vysílačů. Hlavně tam, kde jsou připojeni členové, kteří přenášejí hodně dat, je naprosto nezbytné, aby byl správně nastavený QoS. Jeho byť krátkodobá nefunkčnost (například z důvodu změny nastavení sítě na routeru) bývá velice rychle hlášena některým ze členů, který si stěžuje na „špatné připojení“. Často je potřeba dlouhodobější nastavování parametrů pro hodnoty omezování. Po nalezení vhodných hodnot pro maximální rychlosti na rozhraní obvykle systém funguje ke spokojenosti připojených členů. Samozřejmě se najdou i výjimky. Zejména nepochopení ze strany jednotlivců co byli zvyklí na velké rychlosti na úkor ostatních připojených. Omezení rychlosti připojení může být v některých případech až zdrojem velmi silných osobních emocí a antipatií jednak mezi samotnými připojenými členy, tak i vůči správci, který tato omezení zavedl. Přitom se často v těchto případech jedná o členy, kterých se toto omezení víceméně nijak nedotkne, cítí se ukřivděni jen kvůli faktu, že je někdo či něco z nějakého důvodu omezil. Do budoucích verzí plánuji zejména otestování více dynamického chování při omezování uživatelů. Stávající systém hlavně v nočních hodinách, kdy není příliš aktivních lidí, omezuje členy podle pevně zadaných hodnot. Toto bych chtěl změnit tak, aby úroveň omezení závisela na počtu právě aktivních členů (aktivní jsou ti, co za poslední měřené období přenesli nějaké stanovené nadlimitní množství dat). Takto upravený systém by měl být více uvolněný v nočních hodinách, naopak více restriktivní ve večerní špičce, kdy je zátěž sítě největší. Pro podporu této věci bylo již zavedeno testovaní dob odezev na členy, které se bude podílet na výpočtu pro dynamické omezení. V případě, že systém zjistí přetížení celého přístupového bodu, zavede tvrdší politiku. 51
Druhou věcí, kterou bych rád pokusně implementoval je využití Differential Services pro shaping páteřní sítě. Sice očekávám, že výsledný efekt nebude příliš výrazný, ale alespoň bude možnost v praxi porovnat obě možné varianty.
52
9 Použitá literatura a odkazy [1]
– IEEE 802.11 http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[2]
– http://rfc.net/rfc791.txt - IP protokol – RFC 791
[3]
– http://qos.ittc.ku.edu/ - Information and Telecommunication Technology Center (ITTC) The University of Kansas - IP QoS Page
[4]
– http://lartc.org/howto/ - Linux Advanced Routing And Traffic Control Howto
[5]
– http://qos.ittc.ku.edu/howto/node3.html - QoS Support in Linux - Saravanan Radhakrishnan
[6]
– http://ftp.gnumonks.org/pub/doc/packet-journey-2.4.html- zpracování paketu routerem
[7]
– manuálové stránky balíku iproute2
[8]
– http://fatooh.org/esfq-2.6/current/README - ESFQ for Linux 2.6
[9]
– http://luxik.cdi.cz/~devik/qos/htb/ - HTB home - Martin Devera
[10] – http://b42.cz/notes/u32_classifier/ - anonymní stránky neznámého uživatele, poskytující však výbornou dokumentaci k u32 klasifikátoru. [11] – http://l7-filter.sourceforge.net/ - l7 filter [12] – http://diffserv.sourceforge.net/ - Differential Services on Linux [13] – http://www.linuximq.net/ Linux IMQ [14] – http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html cisco implementace QoS [15] – http://rfc.net/rfc813.txt - Window and acknowledgement strategy in TCP - David D. Clark [16] – https://twiki.klfree.net/twiki/bin/view/SpravaSite/KlfreeDebianQoS - twiki dokumentace Klfree debian QoS.
53
Dodatky A. Seznam použitých zkratek CSMA/CA – Carrier-sense, multiple-access, collision avoidance – zabránění kolizí detekcí vysílání DNS
– Domain Name System – protokol pro převod doménových jmen na IP adresy a opačně.
DSCP
– Differentiated Services Code Point – pole v hlavičce IP paketu
ESFQ
– Extended Stochastic Fairness Queueing – frontová disciplína
HTB
– Hierarchic Token Bucket – frontová disciplína
ICMP
– Internet Control Message Protocol – protokol pro převážně diagnostické a kontrolní síťové účely
IMQ
– Intermediate Queueing Device – speciální zařízení pro řízení toku dat
ISP
– Internet Service Provider – poskytovatel připojení k internetu
MTU
– Maximum Transfer Unit – maximální velikost paketu
NFX
– Neutral Czfree Exchange – sdružení komunitních sítí.
NIX
– Neutral Internet eXchange – sdružení pro peering českých ISP
OSPF
– Open Shortest Path First – protokol pro dynamické routování v síti
P2P
– Point to Point – bod x bod – přímá komunikace mezi dvěma účastníky
P2M
– Point to Multipoint – jedna centrální stanice komunikuje s ostatními
QoS
– Quality of Service – kvalita služby
RED
– Random Early Detection – frontová disciplína
RSVP
– Resource reservation protocol – rezervace prostředků pro kvalitu služby
RTS/CTS
– Request to Send / Clear to Send – požadavek/potvrzení možnosti vysílání
SFQ
– Stochastic Fairness Queueing – frontová disciplína
SIP
– Session Initiation Protocol – protokol používaná internetovou telefonií
TBF
– Token Bucket Filter – frontová disciplína
TCP
– Transmission Control Protocol – protokol pro datový přenos
ToS
– Type of Service – druh služby – pole v hlavičce IP paketu
UDP
– User Datagram Protocol – protokol pro datagramový přenos
VNC
– Virtual Network Computing – grafický vzdálený přístup na PC
VoIP
– Voice over IP – přenos telefonního hovoru přes internet
WiFi
– Wireless Fidelity – označení bezdrátových zařízení
B. Sdružení Klfree.net Sdružení Klfree.net (dále jen Sdružení) je komunitní síť působící v Kladně a jeho okolí. Jedná se o neziskovou organizaci – občanské sdružení - sdružující lidi se zájmem o počítače, počítačové sítě, radiovou a jinou techniku či digitální a online komunikaci. Sdružení provozuje a buduje privátní datovou síť především vlastními silami - tato síť je propojena s mnoha dalšími neveřejnými sítěmi a mimo jiné je i součástí sítě internet. Sdružení je dále členem NFX z.s.p.o. (Neutral Czfree Exchange, zájmové sdružení právnických osob) – což je sdružení, jehož cílem je propojení členských sítí za účelem širokopásmové komunikace a vzájemných toků dat uživatelů těchto sítí. Dalšími cíli je připojení do peeringového centra NIX.cz, provoz propojovacího centra NFX pro vzájemnou komunikaci účastníků členských sítí, podpora využívání intranetu, internetu, VoIP a dalších informačních technologií, spolupráce se subjekty, které sledují slučitelné cíle a další spolupráce členských sdružení. Jelikož je Sdružení jednou z největších podobných sítí v České republice (v době psaní této práce počet připojených členů přesahuje 4 tisíce), značně stoupla složitost a komplexnost nasazených síťových technologií. Jednou z nich je právě QoS, jehož správná funkčnost je jednou ze základních podmínek pro celkovou funkčnost sítě.
Síťové prostředí Sdružení Stručný popis topologie sítě Sdružení a použitých technologií považuji za důležité pro následné vymezení cílů této práce. V současné době je síť připojena z centrálního bodu - Node v Kladně do peeringového centra Sitel Telehouse v Praze 10. Propoj je realizovaný pomocí pronajatého optického vlákna, které při použitých konvertorech umožňuje teoretickou přenosovou rychlost až 1Gbit/s. Z centrálního přístupového bodu v Kladně vede několik desítek páteřních spojů na další Node sítě. Spoje jsou jednak kabelové - prostřednictvím převěsů vedených mezi střechami sousedních domů v sídlištích. Zde jsou použita převážně optická vlákna. Je samozřejmě snahou o co největší rozšíření této technologie, protože poskytuje největší přenosové rychlosti. Bohužel ne vždy je možné vést tímto způsobem kabeláž, proto je zde nasazeno také velké množství spojů bezdrátových. Instalovány jsou optické bezdrátové spoje (FSO) od renomovaných firem (MRV, Laserbit) s propustností převážně 100Mbit/s. Dále rádiové spoje v pásmech regulovaných Generální licencí ii
10GHz, 5GHz a také několik spojů na zakoupených licencovaných pásmech (11 a 18 GHz) od firmy Ceragon. Další distribuce je realizovaná propoji mezi jednotlivými Node. Pro zajištění dostatečné robustnosti sítě je použito dynamické routování (česky „směrování“) OSPF a výstavba záložních spojů, které jsou automaticky využity při výpadku některého z primárních spojů či celého Node. Převážná většina Nodů je osazena klasickými PC s operačním systémem Linux – využíváme vlastní distribuce – Klfree debian. Uživatelé sítě – členové sdružení – jsou připojeni jednak přímo prostřednictvím rozhraní Ethernet na některý z páteřních routerů nebo pomocí bezdrátového připojení v pásmu 2.4GHz či 5GHz na vysílač Node. Právě tato poslední skupina je z pohledu QoS nejdůležitější. Bezdrátové připojení neposkytuje ve většině případů dostatečnou přenosovou kapacitu pro uspokojení všech požadavků uživatelů.
iii
C. Ukázka webového rozhraní routeru s qosem
Obrázek 4 – webové rozhraní routeru – stránka statistik uživatelů
Obrázek 5 – webové rozhraní router – stránka s informacemi o odezvách členů
iv
D. Dokumentace – návod ke konfiguraci V tomto dodatku přímo cituji návod ke konfiguraci tak jak je uveden ve Twiki Sdružení Klfree.net. [16]. V originálním textu není používána diakritika.
Úvod: V současné chvíli je na síti několik verzí distribuci a s tím i několik verzí shaperu (občas i nezávisle na distribuci). Následující návod se vztahuje k verzi 2.2.2+
Co se vlastně děje při průchodu paketu přes router? V první fázi jsou odděleny "servisní" protokoly podle portu. Je detekováno - ssh, dns, ping. Ty mají vlastní pásmo vyčleněné kapacity. O osudu ostatního trafficu rozhoduje použitý modul (script, který nastaví jak se má se zbytkem zacházet).
Konfigurační soubory pro qos se nacházejí v adresáři /etc/qos
Traffic shaping se aktivuje pro daný interface na routeru konfiguračním souborem qosdevx (devx = jméno zařízeni, pro které je určen).
V současné chvíli jsou k dispozici 2 moduly.
basic Aplikuje (E)SFQ queue disciplínu. Procházející pakety se odesílají cca rovnoměrně v závislosti na cílové IP adrese. Jednoduchým způsobem se tak zajistí lepší rozložení trafficu mezi jednotlivé členy. Vhodné zejména pro peer spoje.
userap Shapovací systém vyvíjený zejména pro použití na koncových klientských AP. Nepoužívá již nijak iptables. Vše je řešeno pouze v rámci tc toolu.
Z centrálního serveru si pak stáhne seznam IP adres jednotlivých členu na rozsahu daného zařízení. Každému členovi je vytvořeno vlastní pásmo, kterým prochází pakety ze všech jeho IP. Žádny typ trafficu není preferován. Tzn. člen má k dispozici určitou omezenou kapacitu a jak si ji využije je čistě na něm.
v
Na pozadí běží perlový skript, který každých 10 minut zjišťuje, kolik každý člen přenesl dat. Na základě nastavených limitů pak provádí omezení pásma člena. Míra jak bude člen omezen se nastavuje v konfiguráku.
ban_ip Tento soubor je používán i ve staré verzi shapingu. Jedná se o jednoduchá zabanování IP adresy přesunutím trafficu do omezeného pásma. Omezení se provede zapsáním IP adresy do soubor /etc/qos/ban_ip
Všechny IP adresy v tomto souboru jsou svedeny do jediného pásma. Tudíž při zabanování více lidí se děli dohromady o tuto omezenou rychlost (128kbit).
Omezeni je provedeno pouze na zařízeních kde je aktivovan shaping. JINDE NENI SAMOZREJME NIC OMEZENO!!!!!
modul basic základní možnosti konfigurace type=basic aktivuje modul basic speed=2000 nastaví celkové maximum pro toto zařízení = (pouze jedním směrem, typicky download) hash=dst nastaví stranu, podle které se traffic pseudonáhodně rozděluje (viz níže)
Speed je hlavním parametrem pro tento modul. Nastavuje celkovou rychlost odchozího trafficu skrz daný interface.
"hash" [od verze Klfree-Debian 2.1.0] určuje, která ze stran spoje se použije pro "rovnoměrné" rozdělení trafficu. Pro rozdělení se používá queue disciplína ESFQ, která uspořádá požadavky do front podle zdrojového (src) nebo cílového (dst) IP a z front pak vybírá systémem round-robin.
Parametr "hash" má standardně hodnotu "dst", když jde o "normální" výstupní zařízení a "src", pokud jde o IMQ (řízení vstupu). Pro traffic mezi stanicemi na vnitřní síti je
vi
lhostejné podle kterého konce se distribuuje, pro traffic mezi Klfree a Internetem by se melo rozdělovat podle adresy v Klfree (odpovídá to politice "každému členu stejně")
modul userap Tento modul shaperu funguje tak, ze každému uživateli na daném zařízení počítá jeho celkový traffic a podle toho jej omezuje. Omezení je trojstupňové (bez_omezeni, limit1, limit2).
Nastaveni probíhá pres konfiguraky v adresáři /etc/qos/
Soubory jsou ve tvaru qos-device (qos-wlan0, qos-eth0,...)
Možnost pingání na členy (pouze verze 2.2.2+) Pingání se aktivuje přidáním ping=1 do konfiguráku qosu pro dané rozhraní.
Systém funguje tak, že zkusí „opingat“ nejprve VŠECHNY IP adresy člena malými pakety. Pokud některá z nim reaguje, tak se vybere první živá. Následně jsou opingáni všichni členové se živými IP adresami.
Penalizace za žádnou IP co by reagovala na ping - nastavení nopingpenalty=X . Omezí člena na X% rychlosti.
Penalizace za špatnou odezvu - zatím bez možnosti nastavení - vypočítává se automaticky podle stupně prohřešku.
Pinger.Pl - Podrobněji popsané jak se vypočítá penalizace na zaklade prohřešku
Základní možnosti konfigurace type=userap aktivuje modul userap speed=2000 nastaví celkové maximum pro toto zařízení (pouze jedním směrem, typicky download) queues=imq1 určení zařízení pro omezení uploadu descr="klienti na kLfREE-hrad" nastavení popisku, co se zobrazuje na www routeru. ping=1 povolení pingání a penalizace vii
Další možnosti konfigurace Dále jde definovat další parametry specifikující chování shaperu. (Jejich list je možné získat např. vypsáním souboru /etc/qos/default-qos
rate=128 - nastavuje garantovanou rychlost pro uživatele bez omezeni (kbit/s) limit1=15000000 - množství přenesených dat userem pro zařazení do limitu1 limit2=75000000 - stejné jako u limit1 penalty0=80 - omezení při nulovém průtoku = zabránění tomu aby někdo měl k dispozici celou kapacitu linky. penalty1=50 - omezení rate/ceil na 50% z celku penalty2=30 (30% po dosažení limit2) nopingpenalty=50 - omezení na 50% běžné hodnoty při nemožnosti ping
Manuální změny omezení určitého uživatele v procentech vytvořit soubor ve /var/state/qos/ s názvem penalty* (* = cokoli aby to dávalo smysl) uvnitř souboru řádek ID [důvod omezeni] (kde ID je členské číslo clena, perc procenta kolik dostane z původní hodnoty, důvod se zobrazí na webu
Přidáni subnetu pro shapování - verze 2.1.4 a novější použití subnets v manual deaktivuje automatické načítání dle routovaných rozsahů. Pokud není subnets uvedeno, vše funguje automaticky. - verze 2.1.2-2.1.3 automaticky se načítá seznam uživatelů pro všechny aktuálně routované rozsahy pro dané zařízení. - verze starší než 2.1.2: polo-automaticke rozpoznávání rozsahu - shaper zjišťuje IP členů POUZE NA ROZSAHU, KTERY JE VAZANY NA ROZHRANI v routeru. Jiné rozsahy je potřeba definovat manuálně.
viii
K manuální definici rozsahu slouží adresář /etc/qos/scripts/userap_files/manual (u starých verzí /etc/qos/manual). Zde vytvořené soubory subnets-devX obsahují seznam rozsahu, na kterých si shaper z ISka zjistí členy!
Příklad: Na zařízení ath1 (sektor) je přímo rozsah 10.102.26.64/26, ve kterém mají přímo členové IP adresy. Dále je zde peer rozsah 10.102.26.200/29, který slouží pro komunikaci s dalším routerem (router2) připojeným na tento sektor. Přes tento peer je routován rozsah 10.102.24.128/25 (klientský rozsah na routeru2).
V souboru /etc/qos/manual/subnets-ath1 (případně i ..-imq1 když se limituje upload nejlépe udělat jako link) bude: 10.102.24.128/25
Pokud by jsme toto chtěli nadefinovat manuálně na shaperu verze 2.1.4+, tak tam bude: 10.102.24.128/25 10.102.26.64/26 (=je potřeba uvést všechny rozsahy, na kterých má shaper hledat členy - i včetně rozsahu přímo sektoru).
Limitování uploadu Aby bylo shapování všesměru efektivní, je nutné shapovat i upload. K tomu je potřeba provést několik kroku. mít nahozené imqX rozhraní /etc/qos/qos-wlan0: queues=imq0 /etc/qos/qos-imq0: iface=wlan0
Tím říkáte, že zařízení imq0 (pro řízení vstupních dat) se používá pro skutečnou síťovou kartu wlan0. Poté běžným způsobem vytvoříte konfigurační soubor pro zařízení imq0 (jak bylo popsáno výše).
Skripty zajistí: nahrání modulu imq ix
nastavení link up na imq přidání pravidel -j IMQ do iptables spuštění setup-qos start imq0
Není nutné přidávat zařízení imq do /etc/network/interfaces, ani přidávat pravidla do /etc/network/iptables.local !
Pocet imq zařízení lze specifikovat v /etc/default/qos pomocí proměnné QUEUES=X (default 5)
Upgrade QoSu - testing verze (nejsou soucasti distribuce) kde se najde? 2.2.2: http://goldheart.klfree.net/~skudlik/qos/klfree_qos-2.2.2.tar.bz2 2.2.1: http://goldheart.klfree.net/~skudlik/qos/klfree_qos-2.2.1.tar.bz2 2.2.0: http://goldheart.klfree.net/~skudlik/qos/klfree_qos-2.2.0.tar.bz2
Postup instalace testing verze 2.2.X co všecko zkopírovat: v této verzi jsem připravil testovací instalátor..
ukončete Configure Script - příkazová řádka NEsvítí bíle vložte postupně tyto příkazy: setup-qos stop cd /var/tmp wget http://goldheart.klfree.net/~skudlik/qos/klfree_qos-2.2.3.tar.bz2 tar xjf ./klfree_qos-2.2.3.tar.bz2 cd ./qosinstall ./install.pl dal podle pokynu instalátora otevřete konfiguraci a upravte vše potřebné, restartujte qos (setup-qos restart)
Upozorněni pro verzi 2.1.1 a vyšší POZOR! tato verze má již (doufejme) spravené automatické nahazování IMQ zařízení. Proto je při přechodu na ni nezbytně nutné zrušit veškeré nahazování manuální
x
(/etc/network/interfaces - zrušení vytváření imq zařízení, /etc/network/iptables.local zrušit pravidla pro imq v iptables.
Původní návod pro tyto staré verze JE NUTNE PRO POUZITI IMQ DEFINOVAT QUEUES!!! příklad:
qos-wlan1 speed=2800 type=userap queues=imq1
qos-imq1 speed=1400 type=userap iface=wlan1
Známé problémy Může se vyskytnout stará verze wgetu, která má bohužel jinou syntaxi (klfree-debian s 2.4.X
jádrem)
pro
správnou
funkci
je
potřeba
upravit
soubor
/etc/qos/scripts/userap_files/is_updater --- najít řádek s wget a zrušit parametr --nocheck-certificate ... tahle verze wgetu funguje bez něj .. naopak s tímhle parametrem hlásí syntax error ...
xi
