Maximální metrika OSPF: jak odradit tranzit přes pobočku bez jejího odstranění

Dvě kanceláře jsou propojeny přes pobočku, která má nést vlastní provoz a jen velmi málo jiného. Pobočka potřebuje trasy do obou lokalit a ani jedna lokalita by ji neměla preferovat jako cestu mezi nimi. Odstranění pobočky z topologie by vyřešilo problém tranzitu a porušilo požadavek, protože pobočka stále musí dosáhnout na obě lokality a obě lokality stále musí dosáhnout na pobočku.

Chcete preferenci vyjádřenou v routovacím protokolu, která ponechá pobočku plně dostupnou a udělá z ní špatnou volbu pro cokoli, co přes ni prochází. Projděte problém v pořadí, v jakém ho vidí routery.

Začněte cestou, které se chcete vyhnout

Nakreslete topologii tak, jak ji vidí protokol, ne jak ji vidí diagram. Která rozhraní tvoří sousedství, která jsou ve stejné oblasti a která z těchto sousedství by nesla provoz mezi dvěma kancelářemi, kdyby byla pobočka preferovaná? To jsou tři oddělené otázky a diagram na žádnou z nich spolehlivě neodpovídá.

Pak najděte alternativní cestu. Pokud jediná trasa mezi kancelářemi vede přes pobočku, žádná metrika z ní provoz nedostane, protože provoz nemá kam jít. Redundance není detailem tohoto návrhu; je to předpoklad. Druhá cesta, která existuje jen na papíře, se nepočítá.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Tyto tři pohledy odpovídají na různé otázky: kdo je soused, která rozhraní se účastní a s jakou cenou a kterou cestu zařízení právě volí. Nasazení tunelu přidává čtvrtou: čára v diagramu není důkazem, že přes ni vzniklo sousedství, a vzniklé sousedství není důkazem, že předávání jde stejnou cestou. Právě v tunelech se tato mezera ukazuje nejčastěji.

Co maximální metrika inzeruje

RFC 6987 popisuje router, který inzeruje své ne-stub odkazy s maximální metrikou odkazu, definovanou jako 0xffff. Router stále popisuje sebe i své odkazy; jen je oceňuje na horním konci rozsahu, takže každý jiný router spočítá cestu přes něj jako drahou.

Jde o změnu router-LSA, ne o odstranění topologie. Rozdíl je důležitý: vyčištění router-LSA stahuje samotnou informaci o topologii, což může stáhnout i vztahy potřebné k dosažení routeru a prefixů za ním. Ponechání inzerce a zvýšení její ceny tyto vztahy zachová. V tom je celý rozdíl mezi touto technikou a odstraněním.

Mechanismus RFC 6987 také nemá nic společného s typy oblastí ani s volbou určeného routeru. Stub oblast blokuje kategorii inzerci stavu odkazu na hranici oblasti a stub router oceňuje své vlastní odkazy. Podobná slova, nesouvisející stroj.

Proč dostupnost přežije a tranzit ne

Ostatní routery stále mají trasu k připojeným prefixům pobočky, protože je pobočka stále inzeruje a odkazy stále existují. Mění se celková cena každé cesty, která přes pobočku prochází cestou jinam. Prefixy se nehýbou; mění se jen cena přechodu přes router.

Pro provoz, jehož zdrojem nebo cílem je sama pobočka, je drahý odkaz stále na jediné rozumné cestě, takže se používá. Pro provoz mezi dvěma kancelářemi nyní alternativní cesta vyhrává cenou a pobočka vypadává z rozhodování o předávání, aniž by zmizela z topologie. Dva směry, dvě různé odpovědi a obě jsou tím mechanismem v akci.

To je chování, které je třeba ověřit, ne předpokládat. Podívejte se na router-LSA, který pobočka generuje, pak na cestu, kterou jiný router volí pro cíl za pobočkou a pro cíl v druhé kanceláři. Obě odpovědi by se měly lišit, a pokud se neliší, změna metriky nedosahuje rozhodnutí, o kterém si myslíte.

Problém poslední cesty

Tentýž RFC výslovně uvádí, že technika použití nezakazuje. Když alternativní cesta selže, routery se vrátí na drahou cestu přes pobočku, protože je stále platnou cestou a protokol preferuje drahou trasu před žádnou.

Zda je tento návrat přijatelný, je otázka politiky, na kterou musíte odpovědět před nasazením. Pobočka na malém vzestupném spoji, která najednou nese provoz mezi kancelářemi, může být horší než výpadek a může být přesně to, co chcete během servisního okna. Obě odpovědi jsou legitimní; mlčení ne.

Pokud je požadavkem striktní zákaz, ne preference, samotný návrh metriky ho nedosáhne. Potřebujete vynucení předávání, které odpovídá záměru, plus definované chování pro případ, kdy provoz stejně dorazí. Inzerovat cestu jako použitelnou a pak provoz zahodit vytváří černou díru, kterou je těžší diagnostikovat než smyčku routování.

U OSPFv3 RFC probírá R-bit jako jiný způsob vyloučení účasti na tranzitu. Nepředpokládejte, že dědí stejné chování poslední cesty jako technika maximální metriky, a nekopírujte nastavení mezi oběma rodinami adres, jako by šlo o stejnou funkci.

Dokažte to za normálních i selhaných podmínek

Testujte dvakrát: jednou s oběma dostupnými cestami a jednou s odstraněnou preferovanou cestou. První test ukazuje, že preference funguje, a druhý ukazuje, co síť dělá, když preferenci nelze dodržet. Vynechání druhého testu nechává důležitou polovinu neprozkoumanou.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Pohled do databáze ukazuje inzerovanou metriku, vyhledání trasy ukazuje zvolený další hop a trace ukazuje, kam pakety skutečně šly. Když se tyto tři shodují, máte ověřený návrh, a ne konfiguraci, která vypadá správně.

Pak obnovte preferovanou cestu a potvrďte, že se pobočka vrací k přenášení pouze vlastního provozu. Krok obnovení patří k testu, ne k úklidu, protože návrh, který funguje jen do příští změny, není návrh. Zapište oba výsledky, včetně návratu, protože druhý je odpověď, kterou bude někdo potřebovat ve tři hodiny ráno.