Routovací software BIRD a naše síť

BIRD Internet Routing Daemon je open-source routovací daemon implementující routovací protokoly BGP, OSPF a RIP. Je určený pro UNIXové systémy, jedná se o alternativu k běžně používanému daemonu Quagga. Je výsledkem českých vývojářů kolem Ondřeje Filipa, současného ředitele organizace CZ.NIC (správce národní domény .cz).

BIRD podporuje více routovacích tabulek, které mohou získávat cesty z různých protokolů od různých sousedů, podle určitých pravidel tyto cesty filtrovat, předávat do dalších tabulek a nakonec synchronizovat s routovací tabulkou jádra operačního systému.

To bylo ve zkratce, teď znovu od začátku trochu pomaleji.

Budeme předpokládat použití protokolů BGP a OSPF (s jednou oblastí). Na jednom routeru je typicky jedna instance OSPF, která si vyměňuje zprávy se všemi sousedy, přijímá od nich oznámení o změnách a sám jim oznamuje zjištěné změny. Na hraničním routeru (na hranici s jiným autonomním systémem - nebo více AS) bude navíc jedna nebo více instancí BGP - co jeden sousední router, to extra BGP spojení (existuje i alternativa v podobě route serverů, to zde nebudeme rozvádět).

U každé instance protokolu pak můžete říct, s jakou routovací tabulkou má pracovat. To znamená, že do této tabulky se zapisují cesty zjištěné přes tuto instanci protokolu a také se cesty z této tabulky oznamují sousedům, se kterými komunikujeme přes tuto instanci.

To ještě není zajímavé. Lepší to je, když si začnou routovací tabulky předávat data mezi sebou. A pomocí filtrovacích pravidel (export, import) lze říct, které cesty se mohou předávat ze které tabulky do které tabulky. Výsledek je, že jedna tabulka pracuje s OSPF (a v ní tedy vidíme všechny cesty uvnitř autonomního systému), druhá s BGP (v ní vidíme sítě sousedních autonomních systémů) a třetí, která se synchronizuje s routovací tabulkou jádra operačního systému. A nyní tedy pomocí pravidel řekneme, které cesty zjištěné z OSPF se mohou dostat to jádra, které do BGP, které se mohou dostat z BGP do OSPF a naopak a které se nesmí dostat nikam dál atd.

Konfigurace BIRDu

Možnosti konfigurace BIRDu jsou neomezené, vše myslitelné v něm lze (snad) udělat. Na počátku jsme s tím však měli mnoho problémů, starostí a bolavých hlav. Dokumentace je sice kompletní, co se týče referenční příručky všech možných nastavení a příkazů, ale chyběly nám nějaké praktické příklady ze života. A tak jsme na mnoho věcí museli přijít na základě mnoha pokusů a omylů. Chyba nakonec byla vždy mezi klávesnicí a myší, ale občas to bylo dost těžké zjistit. Postupně jsme se však probojovali k dokonalé konfiguraci routerů (aspoň máme ten pocit).

Ve virtualizačním prostředí jsme si vytvořili několik virtuálních serverů, na nichž jsme si nasimulovali celou naši budoucí síť. Některé servery zde dělaly naše routery, dále jsme měli několik "cizích" routerů, reprezentující routery v jiných autonomích systémech, a nakonec pár koncových serverů a pracovních stanic. Vše jsme nakonfigurovali a postupně zkoušeli všechny možné poruchy (umřel router, spadla linka, odmlčel se sousední AS aj.) a postupným laděním jsme dosáhli toho, že výpadek jakékoliv jedné trasy nebo jakéhokoliv jednoho routeru funkčnost celé sítě neovlivnil.

Když se něco porouchá, tak samozřejmě ke krátkému výpadku dojde. Routery musí problém rozpoznat, najít a propočítat nové cesty, oznámit změny sousedům, celá síť musí "konvergovat" do nového funkčního stavu. Může to trvat několik sekund nebo desítek sekund, záleží také na konfiguraci.

Jedno z našich hlavních rozhodnutí bylo, že budeme mít 2 hlavní BGP routery, z nichž jeden bude master a druhý záložní (slave). Je to dané tím, že jsme také nechtěli, aby se dovnitř sítě dostávaly cesty zjištěné přes BGP (protože pak by musel každý interní router evidovat a pracovat se stovkami tisíc cest). My naopak v rámci OSPF vypočítáváme cesty pouze uvnitř sítě a hlavní routery pak přes OSPF oznamují výchozí routu. Master ji oznamuje s lepší metrikou, takže je všemi preferovaný. Teprve když se něco směrem k němu porouchá, upřednostní se výchozí cesta oznamovaná záložním hlavním routerem.

Konfigurace OSPF

protocol ospf MyOSPF {
  table ospftable;
  rfc1583compat yes;
  export all;
  import all;
  area 0.0.0.0 {
    interface "eth1" {
      cost 11;
      hello 15;
      priority 100;
      retransmit 7;
      authentication simple;
      password "aaa";		
    };
  };
}

To je ukázka jednoduché konfigurace OSPF. Exportní a importní filtry nejsou nastaveny, všichni si uvnitř sítě vyměňují všechno. Ale cesty končí v routovací tabulce "ospftable", tedy nelezou přímo do jádra. K tomu existuje propojení této a hlavní tabulky, do jádra se z OSPF propagují pouze naše podsítě a nic jiného.

protocol pipe ospfPipe {
  table ospftable;
  peer table master;
  export filter WEDOS_accept;
  import none;
}

Konfigurace BGP

U BGP byla docela věda rozchodit MD5 autentizaci. S peeringovými partnery si totiž musíte domluvit heslo, kterým se budou vaše routery vzájemně prokazovat, aby nedošlo k připojení záškodníka, který by posílal nesmyslné cesty. Jádro Linuxu musí podporovat "TCP MD5", tedy podepisování TCP paketů na úrovni jádra. To podporuje Linux až od verze 2.6.21 (zřejmě). Takže jsme se nejprve museli poprat s nasazením novějšího jádra.

Následuje příklad konfigurace jednoho BGP spojení v NIXu na našem hlavním routeru:

protocol bgp Alien {
  local as 65000;
  neighbor 192.168.1.21 as 5588;
  hold time 60;
  table bgptable;
  export filter WEDOS_all_accept;
  import filter {
    if net ~ 192.168.100.0/24 then accept;
    reject;
  };
  password "r1a1";
} 

Zde lze vidět několik zásadních věcí:

• Je nutné filtrovat cesty, které oznamujete sousedovi, nesmí vám proklouznout nic jiného než jeden nebo více souhrnných prefixů vašeho AS, nesmíte omylem oznamovat své podsítě nebo cesty získané od jiných BGP spojů. Kdybyste to nedělali, peeringoví partneři by vás zabili.
• Naopak musíte zavést preventivní opatření pro případ, kdy by některý z partnerů měl chybně nastavený svůj router a oznamoval něco co nemá. Proto je lepší explicitně vyjmenovat podsítě, které od něj akceptujete, a ostatní odmítat. Toto se netýká BGP spojení s tranzitním operátorem, od něj musíte akceptovat všechno.

Dále je nutné propojení tabulky "bgptable" s jádrem - směrem zleva doprava se smí dostávat jen cesty přijaté (a nikoliv cesty odesílané) a opačným směrem se nesmí dostat nic (protože to co je v tabulce jádra pochází také z OSPF a to se do BGP dostat nesmí).

protocol pipe bgpPipe {
  table bgptable;
  peer table master;
  export filter WEDOS_reject;
  import none;
}

Soutěž pro vás (bez výhry)

Ještě zde pár věcí a některých dalších fíglů chybí, třeba jak plníme BGP tabulku našimi prefixy, to prozradíme třeba jindy. Anebo to zkuste vymyslet. Soutěžní otázky:

• Jak zajistíme, že se náš prefix přestane přes BGP oznamovat v případě, že spadne spojení mezi naším hlavním routerem v Praze a sítí v datacentru, tudíž peeringový partneři začnou posílat data přes náš záložní hlavní router?
• Jak zajistíme, že se při odpojení síťového rozhraní v NIXu přestane dovnitř sítě propagovat výchozí cesta, tudíž celá síť začne používat záložní hlavní router?
• Jak zajistíme, že hlavní router master oznamuje přes OSPF dovnitř sítě lepší výchozí cestu než záložní router?
• Jak zajistíme, že peeringoví partneři přes BGP upřednostňují cestu k nám oznamovanou z master hlavního routeru a nikoliv od záložního?

Očekáváme vaše tipy v diskuzi. Správný tipující nevyhraje nic.