Routovací protokoly
Routovací protokoly by se daly rozdělit na interní a externí. Mezi ty interní patří často používané OSPF nebo méně častěji používaný RIP. Existují i komerční alternativy v ciscovském IGRP nebo EIGRP. Tento článek se bude věnovat pouze OSPF, protože má široké uplatnění jak při použití v menším měřítku jako jsou třeba komunitní sítě, tak i při použití ve větším měřítku jako je síť nějakého ISP o stovkách routerů.
Nejdůležitější vlastnost každého routovacího protokolu je přeposílání routovacích pravidel, tzv. rout, do okolí svým sousedům. Ti zase přeposílají svoje routy dalším a přidají k tomu i routy, které již dostali. Pokud se všichni domluví, měla by komunikace začít fungovat a všechny routery by měly mít informace o tom jak komunikovat s okolím.
Abychom měli porovnání OSPF s Protokolem RIP ať už v kterékoli jeho verzi, tak bychom si měli říct, že v jeho případě si všechny routery mezi sebou posílají celou routovací tabulku a navzájem si ji doplňují. Je to jednoduchý protokol, který nevyžaduje mnoho konfigurace a funguje relativně spolehlivě. Možná zatěžuje více síť, ale není nějak náročný na výpočetní výkon. RIP počítá hodnotu cestu a tedy i její prioritu z počtu skoků. To může být dostatečné, když jsou všechny routery připojené stejnou rychlostí na každém rozhraní, ale nedostatečné, pokud je linka s menším počtem skoků pomalejší než linka s větším počtem skoků.
Zde přichází na řadu OSPF, které řeší řadu nedostatků spojené s RIP a zároveň dává dnes asi nejpoužívanější řešení pro lokální a metropolitní sítě. OSPF posílá zprávy do okolí pouze při nějaké změně a posílá pouze tuto změnu. Routery si pak informaci rozdistribuují. Tato data se posílají tzv. multicastem a k nim se ještě přidává tzv. HELLO paket, který oznamuje okolí, že je cesta stále živá.
Komunikace mezi routery může vypadat třeba takto:
laura2 ~ # tcpdump -i ath0 ip[9] == 89
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
17:47:58.384657 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:47:59.170053 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:48:08.383454 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:48:09.170542 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Pokud přidáme novou adresu, router během pár vteřin oznámí okolí novou routu, případně i další informace:
laura2 ~ # tcpdump -i ath0 ip[9] == 89
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
17:49:48.373461 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:49:49.175419 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:49:50.081847 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Update, length: 64
17:49:51.083105 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Ack, length: 44
17:49:58.372398 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:49:59.175858 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:50:08.371374 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:50:09.080528 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Update, length: 64
17:50:09.182338 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:50:10.081164 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Ack, length: 44
17:50:11.080889 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Update, length: 64
17:50:11.082402 IP 10.1.0.2 > 10.1.0.1: OSPFv2, LS-Ack, length: 44
17:50:18.370405 IP 10.1.0.2 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48
17:50:19.182875 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, LS-Update, length: 64
17:50:19.183250 IP 10.1.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello, length: 48 Pomocí paketu Hello OSPF oznamuje, že linka žije. LS-Update odesílá informace o změně v topologii sítě. Jako reakce je mu odeslán paket LS-Ack.
Hello pakety mají svoji důležitost u dalšího parametru a ten se nazývá dead-interval. Udává se ve vteřinách a říká, že pokud do této doby nepřijde Hello paket, je linka označena za mrtvou. U nezatížených sítí stačí nechat výchozí hodnoty odesílání Hello paketů a dead intervalu, ale pokud se začnou ztrácet pakety v důsledku zatížení linky, Hello pakety mohou být zahozeny a linka je časem prohlášena za mrtvou, i když tomu ve skutečnosti tak není. Zatím jsem podobný problém neřešil, ale některé komunitní sítě o velkém množství členů ano. Jedním z řešení může být řazení OSPF paketů na začátek fronty, druhým může být změna dead-intervalu na vyšší hodnotu a častější posílání Hello paketů.
OSPF umí také rozdělovat provoz do více cest najednou. Používá se k tomu modul multipath v jádře a musíme s ním mít zkompilovanou i Quaggu (viz. níže). OSPF pak bude posílat jednotlivá spojení podle zatížení linky. Informace o rozdělování zátěže mezi dvě a více linek můžeme najít na lartc.org.
Poslední co si k teorii řekneme jsou tzv. Area. Ty slouží k rozdělení routovacích pravidel do větších celků. Díky tomu pak nemusí každý router obsahovat každou routu, která se v síti nachází, ale pouze se tam přesměruje rozsah, který se nachází v určité area. OSPF funguje podobně jako silnice. Když někam jedete autem bez mapy, tak víte přibližně jakým směrem se vydat, ale cedule u křižovatek mohou vaši cestu ovlivnit. Pokud to jsou inteligentní cedule, které mají přehled o kolonách a celkové propustnosti cest na celé zemi, mohou vás nasměrovat tou nejefektivnější cestou. Následováním těchto cedulí se tak dostanete do cíle nejdříve. OSPF funguje podobně. Nejlépe to ukáže následující obrázek:
Na něm vidíme bublinky představující jednotlivé area. Hlavní router nás připojuje do internetu a je společně s dalšími dvěma routery umístěn v páteřní area 0. Hraniční routery představují hranici mezi dalšími Area, ve kterých se nachází určitý rozsah adres. Díky tomuto rozdělení, tak může mít hraniční router vlevo v routovací tabulce pouze informaci o tom, že hraniční router vpravo routuje určitý rozsah a nemusí vypisovat všechny routy, které se uvnitř schovávají. Pokud odstraníme propojení mezi hraničními routery, tak jediné co se bude distribuovat mezi jednotlivými Area, bude defaultní routa a o komunikaci mezi jednotlivými Area se bude starat hlavní router.
Quagga
Dynamické routování řeší v Linuxu konfiguračně přívětivý balík aplikací a daemonů s názvem Quagga. Ačkoli podporuje různé routovací protokoly, budeme se zabývat pouze OSPF. Quagga by se dala rozdělit na dvě části. Jedna se stará o komunikaci s jádrem a umísťuje získané routy do routovací tabulky v jádře a druhá komunikuje s okolím. První část nazýváme Zebra a její routy jsou v routovací tabulce označeny takto:
laura2 ~ # ip r
xxx.xxx.150.220/30 dev eth4 proto kernel scope link src xxx.xxx.150.222
10.0.0.32/29 via 10.0.0.2 dev ath2 proto zebra metric 160
10.0.0.40/29 dev ath3 proto kernel scope link src 10.0.0.41 Na prvním řádku vidíme routu, která patří naší veřejné adrese a umístil ji tam kernel (proto kernel). Druhý řádek je obhospodařován zebrou (proto zebra) a o její zapsání i zmizení se stará právě daemon zebra. Třetí řádek je routa patřící jednomu z lokálních rozhraní a víceméně je její původ stejný jako u prvního řádku.
Nebudeme dále chodit kolem horké kaše a začneme s konfigurací. Ukážeme si příklad z jednoho stroje, který by se mohl umístit například na konec sítě.
misha ~ # cat /etc/quagga/ospfd.conf
hostname misha
!
interface lo
!!!
interface eth0
description Local
ip ospf cost 10
ip ospf priority 1
interface ath0
description Internet
ip ospf cost 100
ip ospf priority 1
!
router ospf
ospf router-id 10.1.1.254
redistribute connected metric-type 1
redistribute static metric-type 1
!
network 10.1.0.8/29 area 0.0.0.3
network 10.1.1.0/24 area 0.0.0.3
network 10.1.3.0/24 area 0.0.0.3
!
area 0.0.0.3 range 10.1.0.0/16
!
log syslog Konfigurace ospfd se nachází v souboru /etc/quagga/ospfd.conf. Na prvním řádku nastavíme hostname našeho stroje. Další řádky definují jednotlivá rozhraní, na která se mají odesílat Hello pakety a také nastavíme cost a priority. Z cost se vypočítává cena linky a běžně se počítá pomocí 1000/[rychlost linky v mbps], ale jinak je číslo zcela na vás. Čím menší cost, tím lepší vyhlídky na to, že paket poputuje právě tudy. Priority se nebudeme zabývat. Stačí když nastavíme hodnotu jedna.
Máme-li nastavená rozhraní, můžeme přejít ke konfiguraci routeru. Nejdůležitější hodnotou v celém konfiguračním souboru je router-id. To musí mít každý router jiné, jinak se bude routování chovat velmi nepředvídatelně. Doporučuje se zvolit router-id např. podle IP adresy nějakého rozhraní. Další dva řádky se starají o redistribuci lokálních rout do OSPF. Connected jsou routy, které vytvořil kernel například z přidělené adresy k rozhraní podle masky podsítě. Static jsou routy, které vytvoříme ručně. Metric-type označuje způsob, jak se má nakládat s routami při výpočtu ceny cesty. Prozatím nám postačí, že typ 1 má menší cenu než typ 2, proto bychom ho měli používat na connected routy. Pomocí network řekneme, kterým směrem se mají posílat Hello pakety a označíme Areu, ve které se definované podsítě nacházejí. Nakonec již jen definujeme jednotlivá Area, jejich ID a rozsah, a řekneme ospfd, že má logovat do syslogu.
Tímto bychom měli nastavené jednoduché dynamické routování, na kterém budeme stavět v jednom z příštích dílů.
Router OS
Router OS se nastavuje o něco jednodušeji, resp. stačí napsal pár příkazů do shellu a Mikrotik routuje. Nastavení je podobné, tak si ho ukážeme:
routing ospf set redistribute-connected=as-type-1 redistribute-static=as-type-2 router-id=10.1.0.2
/routing ospf area
add area-id=0.0.0.0 name=backbone type=default
add area-id=0.0.0.3 name=101 type=default
/routing ospf network
add area=101 network=10.1.0.0/29
add area=101 network=10.1.0.8/29
add area=101 network=10.1.1.0/24
add area=101 network=10.1.2.0/24 Nastavení kolem routování se v ROS nachází v podmenu routing a pokud nás bude zajímat ještě další menu, a to OSPF. Nejprve nastavíme metric-type pro connected a static routy a rovnou přidáme i router-id. Poté se přesuneme do podmenu area a umístíme naše Area. Pak stačí přejít do podmenu network a přidat sítě, kterým se mají posílat Hello pakety. Pokud vše proběhlo v pořádku, rozjede se nám dynamické routování, jak má.
Spolupráce s Quaggou a jiné problémy
ROS býval před lety velmi citlivý na verze Quaggy, ale tyto problémy se i přes jejich špatnou zjistitelnost podařilo vyřešit. Na síti používáme ROS 3.10 a výš, se kterým nebyly za poslední rok žádné problémy. Nicméně rané verze ROS 3.x se velmi bránily fungujícímu předávání Hello paketů. Než začnete nastavovat jakýkoli ROS, tak použijte aktuální stable verzi a vyresetujte nastavení. Tím se vyhnete neočekávatelným jevům, které půjdou jen těžko vyřešit bez restartu konfigurace.
Další problémy mohou dělat některé bridgovací krabičky jako například RDAA-81 nebo CA-8, které se chovají velmi divně v kombinaci s RouterBoardy a ROS. Často se stává, že na několik vteřin přestanou posílat data, ale WiFi spojení drží. Taktéž se problémy projevovaly u klientů o dva routery dále, ač nikdo jiný je neměl. Také mám podezření, že tyto krabičky propouštějí multicast, jenom když je dobrá konstalace hvězd. Často se stávalo, že Hello pakety přes ně vůbec nedorazily i přes to, že na jiných spojích vše fungovalo, jak má.
Závěr
Než dnešní díl ukončím, musím se zmínit ještě o jedné výhodě, která je pro správu sítě rozhodně důležitá. Tou je fakt, že administrátor nemusí ručně nastavovat každou routu do každého routeru, ale stačí jen vytvořit konfigurační soubor a ten pak s malými úpravami nahrát na jednotlivé routery. V případě ROS je to ještě jednodušší a s malým cvikem je nahození nového routeru doslova hračkou.
Příště se ještě jednou vrátíme k OSPF a zkusíme si jeho další možnosti. Také se podíváme na Zebru a zabezpečíme si komunikaci OSPF.
ČLÁNKY DO MAILU