Miniseriál o OSPF ukončíme povídáním o problémech v praxi a alternativním routovacím softwaru.
13.10.2008 07:00 | Radim Kolář | přečteno 8696×
Kromě programu OpenOSPFd obsaženého v OpenBSD existují i jiné Open Source implementace protokolu OSPF: XORP a Quagga. S programem Quagga se setkáte i v novějších verzích Solarisu, naopak ostatní komerční Unixy používají z historických důvodů gated.
Program XORP je na konfiguraci poněkud složitější než OpenOSPFd nebo Quagga. Před vlastní konfigurací protokolu OSPF musíme nakonfigurovat rozhraní a forwardovací engine. Obě tyto sekce jsou nakonfigurovány tak, aby po shutdownu XORP ponechaly routing nastavený. Tato vlastnost je velmi užitečná pokud se na router přihlašujete vzdáleně a chce jej restartovat. Bez těchto voleb bychom se po zastavení xorp již na router díky nenastavenému routingu nedostali. Další sekce definuje exportní politiku. V xorp je exportní politika narozdíl od ostatních programů vyžadována a pokud není uvedena, neexportuje se nic. Ostatní programy obvykle pokud není uvedeno jinak exportují přímo připojená rozhraní automaticky.
Další věcí, na kterou bych chtěl upozornit je router-id. V protokolu OSPF je každý router identifikován svým jednoznačným identifikátorem. Tyto identifikátory mohou být sice libovolné, ale musí být v celé síti jednoznačné. Pokud jednoznačné nejsou, vytvoří se routing chybně. Většina programů proto z důvodu minimalizace selhání způsobené lidským faktorem generuje router-id automaticky na základě IP adresy připojených rozhraní. Používají se dvě metodiky: nejmenší nebo největší z IP adres.
interfaces {
restore-original-config-on-shutdown: false
interface bridge0 {
disable: false
default-system-config
}
interface ed0 {
disable: false
default-system-config
}
}
fea {
unicast-forwarding4 {
disable: false
forwarding-entries {
retain-on-startup: false
retain-on-shutdown: true
}
}
}
policy {
policy-statement connected {
term export {
from {
protocol: "connected"
}
}
}
}
protocols {
ospf4 {
router-id: 10.0.0.2
export: "connected"
area 0.0.0.1 {
interface bridge0 {
vif bridge0 {
address 10.0.0.2 {
authentication {
md5 1 {
password: "secret";
}
}
}
}
}
}
}
}
Pravděpodobně nejrozšířenějším opensource softwarem pro OSPF routing je Quagga, který je již dnes běžnou součástí linuxových dister. Quagga se podobně jako Zebra konfiguruje ve dvou souborech: zebra.conf pro konfiguraci rozhraní a ospfd.conf pro konfiguraci OSPF. Nastavení hodnot password a password-encryption souvisí s přístupem na router, ne s hesly pro OSPF, ta se nastavují v sekci interface pomocí ip ospf message-digest-key.
zebra.conf:
! ! Zebra configuration saved from vty ! 2007/09/02 12:06:42 ! hostname zabokuch password 8 pYfD8aRJxbmLM log syslog service password-encryption ! interface eth0 ip address 10.0.0.3/24 multicast ipv6 nd suppress-ra ! interface lo ! ! line vty !
ospfd.conf:
! ! Zebra configuration saved from vty ! 2007/12/06 19:15:50 ! hostname cursa-ospf password 8 iNFXnZeZbIXJ6 log syslog notifications service password-encryption ! ! ! interface bridge0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 secret ! interface eth0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 secret ! interface lo ! interface tap0 ! router ospf log-adjacency-changes network 10.0.0.0/24 area 0.0.0.1 area 0.0.0.1 authentication ! line vty !
Technologie dynamického routování pomocí protokolu OSPF má taky své nedostatky. OSPF protokol, zejména jeho implementace state machine, je kriticky závislá na bug free implementaci příslušných RFC. Aby to nebylo tak jednoduché, tak protokol OSPF byl navržen dost košatě a proto bývá těžké ho implementovat bez chyb. Realita je taková, že téměř každá implementace OSPF obsahuje různé chyby.
Pokud se desynchronizují OSPF routery a každý tak obsahuje rozdílnou mapu sítě, je to dost problém. Routery tento druh desynchronizace nejsou schopny detekovat a nepomůže ani ruční restart postiženého routeru. Pro opravení tohoto stavu je potřeba postupně restartovat všechny routery oblasti (u nás to je area 0.0.0.1), což je dost nemilá událost pokud routery v oblasti počítáte na destíky. Můžete si sice vytvářet více menších oblastí, ale to zase bude mít za následek méně optimální routing.
Implementace v routerech Cisco a Juniper jsou všeobecně pokládány za nejspolehlivější. Jsou dostatečně bugfree, aby zvládly i nasazení v náročných podmínkách, kde se potřebuje maximalizovat síťový uptime. Pokud si je můžete finančně dovolit, lze je jen doporučit. Pokud ovšem máte finance na to, aby byli všude Cisca, budete pravděpodobně také provozovat místo OSPF spolehlivější IS-IS.
O chybovosti implementaci OSPF vestavěné ve Windows nemám k dispozici žádné údaje, za své praxe jsem se ještě nesetkal s nikým kdo by to používal jinak než na testování.
Situace v Open Source implementacích rozhodně není ideální. Nejbugovější je OpenOSPFd, který čas od času spadne na SEGFAULT (jeho spouštění z initu je víceméně pro provoz na routeru nutnost), a poměrně dost často se desynchronizuje. Podrobnější informace o chybách v OpenOSPFd byly v minulém článku. Quagga je na tom lépe -- ta na segfault nepadá a často se nedesynchronizuje.
XORP 1.4 je poměrně kvalitní OSPF implementace (zejména ve spojení s patchemi v CVS). Po zhruba ročním provozu se mi u něj nestalo, že by se desynchronizoval. XORP má ale dva zásadní problémy:
Tak na jakého favorita si vsadíte? Osobně vkládám největší naděje do projektu XORP, tam stačí už jen zlepšit obsluhu různých chybových stavů, což už není tak moc práce. Současnou verzi XORP 1.5 jsem ještě zatím podrobněji netestoval.
Je překvapivé, že žádný Open Source projekt není schopný dodat kvalitní implementaci protokolu OSPF, která by se dala s klidem nasadit do produkce kde si nemůžeme dovolit výpadky. Řekl bych, že je to otázka motivace. Pokud si vyvíjíme routovací software jako svůj koníček, tak si se čtyřdevítkovou dostupností moc velkou hlavu neděláme. Stačí, že je to víceméně funkční a rychlý. Pokud jsme ale na software závisí naše příjmy a například musíme platit zákazníkům za network downtime, tak je naše motivace k vytvoření bugfree routovacího software mnohem vyšší.
Pokud nepočítáme poněkud zastaralý protokol RIP jsou k protokolu OSPF dvě spolehlivější alternativy: BGP a IS-IS. BGP protokol je pro intranet routing poměrně nevhodný. Jeho nevýhodou je náročnější konfigurace, nutnost ruční změny konfigurace při každé změně v topologii sítě a generování méně optimálního routingu, což je dáno remote distant vector algoritmem. Narozdíl od IS-IS existují poměrně spolehlivé open source BGP implementace. Je to dáno především tím, že BGP je mnohem jednoduší protokol než OSPF.
Protokol IS-IS je v současnosti poměrně dost oblíben mezi poskytovateli připojení k internetu a to zejména vzhledem větší provozní spolehlivosti oproti OSPF, které i s implementacemi na Ciscách a Juniperech čas od času vypadne. IS-IS umí Junipery, Cisca a vývojová verze programu Quagga.