Z trasy RIP na CE do vzdáleného VRF: kde dochází k exportu
Prefix RIPv2 z CE se do vzdáleného VRF dostane až po třech samostatných rozhodnutích: naučit se ho, vybrat ho ve VRF a exportovat ho podle odpovídající politiky.
Aktualizace RIPv2 dorazí na okraj poskytovatele, spadne do směrovací tabulky VRF a tam se zastaví, pokud ji něco výslovně neexportuje. Tři rozhodnutí probíhají postupně a každé může prefix odmítnout z vlastního důvodu. Právě čtení těchto věcí jako jedné události je důvod, proč lidé hledají špatnou krabici, když se vzdálené lokalitě nedaří dosáhnout sítě, kterou CE jasně inzeruje. Sledujte trasu přes PE a posloupnost se stane zřejmou.
Co PE s aktualizací RIP dělá
PE přijme aktualizaci na rozhraní VRF, ověří, že zdroj je povolený soused, a nainstaluje prefix do směrovací tabulky VRF s počtem skoků odvozeným z inzerce. Tato tabulka je běžná směrovací tabulka s vlastními administrativními vzdálenostmi a vlastní volbou nejlepší cesty. Pokud CE inzeruje stejný prefix dvakrát s různými metrikami, v tabulce přežije jen lepší z nich. Nic v tomto kroku nezahrnuje páteřní síť poskytovatele.
Prefix nyní existuje uvnitř směrovacího kontextu jednoho zákazníka, což je velmi daleko od dosažitelnosti kdekoli jinde.
Export je akt politiky, ne důsledek protokolu
Aby trasa opustila VRF, musí být redistribuována do procesu MP-BGP, který přenáší VPN trasy, a potřebuje rozšířenou komunitu typu route target, která určuje, která vzdálená VRF ji smí importovat. Architektura v RFC 4364 drží tyto výměny oddělené od protokolu CE-PE právě z tohoto důvodu. Použití RIP na okraji neříká nic o tom, co má projít sítí poskytovatele.
Sepište exportní smlouvu dřív, než cokoli nakonfigurujete: zákaznické prefixy, které musí být dostupné na dálku, trasy, které musí zůstat lokální, a případné výchozí, specifičtější trasy nebo výjimky pro sdílené služby. Porovnejte tuto smlouvu se skutečným VRF, nikoli s podobně pojmenovaným, které patří jinému zákazníkovi.
Strana importu je druhá politika s vlastními route targety a odpovídající export s neodpovídajícím importem vytvoří prefix, který existuje v páteřní síti a neobjeví se v žádné vzdálené tabulce.
Redistribuce a explicitní vznik se chovají odlišně
Redistribuce bere trasy, které už v tabulce VRF existují, a kopíruje je do BGP, filtrované mapou tras. Mapa rozhoduje, které prefixy jsou způsobilé a jaké atributy nesou, a metriku je nutné nastavit explicitně, protože počet skoků RIP nemá jako metrika BGP žádný význam. Vše, co necháte nenastavené, se zdědí způsobem, který obvykle překvapí člověka, jenž konfiguraci čte o šest měsíců později.
Vzájemná redistribuce je místem tichých škod. Prefix exportovaný do BGP se může vrátit přes druhý redistribuční bod a bez značek nebo filtrů trasa osciluje, zatímco obě tabulky v každém okamžiku vypadají věrohodně. Filtrujte podle značek uplatněných na okraji, místo abyste spoléhali, že topologie zabrání zpáteční cestě.
Explicitní vznik vypadá uklizeněji a není bezpodmínečný. Deklarace sítě obvykle vyžaduje odpovídající trasu ve směrovací tabulce, než prefix vznikne, takže inzerce zmizí v okamžiku, kdy ji CE přestane inzerovat. To je často chování, které chcete, a není to totéž jako statická trasa, která zůstává nakonfigurovaná navždy. Ověřte skutečné pravidlo platformy, místo abyste předpokládali kterékoli z obou chování.
Ať tak či onak, u každého prefixu je otázkou, který aktivní zdroj ho činí způsobilým a co se stane, když tento zdroj zmizí.
Ověřte řetězec na čtyřech místech
Podívejte se na inzerci CE, směrovací tabulku VRF, tabulku VPN tras s jejím route targetem a import vzdáleného VRF, v tomto pořadí. Na IOS to znamená výstup souseda CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, a stejný příkaz na vzdáleném PE. Na IOS-XR se ekvivalentní výstup nachází pod show bgp vrf CUSTOMER ipv4 unicast. Názvy příkazů se liší, čtyři kontrolní body ne.
Zkontrolujte prefix, který má být odmítnut, stejně pečlivě jako ten, který má projít, protože politika povolující vše vypadá stejně jako správná, dokud nedorazí první výjimka. Pak sledujte odvolání: vypněte rozhraní CE a potvrďte, že vzdálená položka zmizí v očekávaném časovači, místo aby přetrvávala.
Zaznamenejte, kdo vlastní každou politiku. Když CE provozuje poskytovatel, dodávané chování patří do smlouvy o službě a jiný protokol nebo politika odvolání na spravovaném zařízení je problém dokumentace dřív než problém směrování.