Alternativní software

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.

XORP

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";
                            }
                        }
                    }
                }
            }
        }
    }
}

Quagga

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
!

OSPF a problémy

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.

Bugovost implementací OSPF

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:

1. pokud za běhu systému odeberete interface na kterém běží OSPF tak to už nerozchodí a pokud ho restartujete tak ho chybějící interface vyvede z míry tak, že pro jistotu nejde vůbec.
2. obsluha chyb není příliš optimální. Na většinu neočekávaných network io chyb routovacá proces pro daný protokol reaguje assert ukončením. To je nemilá záležitost zejmnéna protože hlavní proces rtmgr neumí takto ukončený routovací proces znovu nastartovat bez kompletního restartu XORPu. Problémem je také jak tento stav automaticky detekovat abychom v tomto případě restartovali XORP automaticky. Já jsem si byl nucen za tímto účelem napsat packet sniffer, který restartuje XORP pokud zdetekuje neocházející OSPF packety. Toto řešení mohu doporučit.

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.

Open Source nefunguje?

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šší.

Alternativy k OSPF

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.