Hierarchický DMVPN: jeden cloud pro každý vztah tunelu

Pobočkový uzel se úspěšně zaregistruje u svého regionálního centra, a přesto se nedostane ke službě v jiné oblasti. Tunel je aktivní, stav NHS vypadá zdravě a selhání se objevuje jen u cílů, které překračují hranici vrstvy. Tento vzorec obvykle znamená, že návrh nikdy neuvedl, která zařízení se účastní kterého cloudu DMVPN, takže vrstvy vznikly podle intuice a nyní si neodpovídají.

Příznak se objevuje na hranici vrstev

V hierarchickém návrhu zaujímá centrální centrum, několik regionálních center a mnoho pobočkových uzlů každý svou pozici. Regionální centrum může vlastnit více než jeden vztah tunelu a pobočky se nemusí registrovat u každého centrálního bodu. Důležité cesty jsou z pobočky do regionální služby, z pobočky do jiného schváleného regionálního uzlu a z pobočky do centrálního cíle.

Když jedna z těchto cest selže, zatímco ostatní fungují, problémem je téměř vždy chybějící nebo rozporná definice role, nikoli rozbitý tunel. Zapište zamýšlené cesty a porovnejte je s tím, co zařízení skutečně postavila. Toto srovnání trvá hodinu a zabrání týdnu hádání. Uchovávejte je u návrhového dokumentu.

Jeden cloud, jedna smlouva rozhraní

Pro každý cloud zaznamenejte tunelové rozhraní, adresování překryvu, místní zdroj podkladové sítě, vztahy NHS a NBMA, doručování multicastu a politiku ochrany. Uveďte také, které trasy přecházejí mezi regionálním a centrálním kontextem, protože právě tato věta je návrh.

Regionální centrum se dvěma tunelovými rozhraními potřebuje dvě smlouvy, ne jednu se dvěma adresami. Zdroj podkladové sítě, doména NHRP a trasy se mohou pro každé rozhraní lišit a dokument, který je sloučí, uvede v omyl toho, kdo konfiguruje druhé.

Identifikátory jsou místní kontext, nikoli řízení přístupu

ID sítě NHRP a klíče GRE jsou dvě hodnoty nejčastěji zaměňované za globální nastavení. Průvodce NHRP v IOS XE popisuje ID sítě jako místně významné, takže shodná čísla na vzdálených routerech nic neověřují a změna místního čísla jednoho routeru nevytváří hranici přístupu.

Klíč GRE, pokud jej návrh používá, pomáhá určit kontext přijímajícího tunelu a sjednává se mezi koncovými body, které tento kontext sdílejí. Není to heslo a nenahrazuje ověřování IKE ani směrovací politiku. Berte obě hodnoty jako konfigurační kontext, který se musí v rámci vztahu shodovat, ne jako bezpečnostní kontrolu oddělující oblasti.

Směrujte mezi vrstvami záměrně

Rozhodněte, které prefixy regionální centrum inzeruje nahoru a které centrální cíle nabízí svým pobočkám. Potom u každé cesty zkontrolujte skutečný další skok a chování zkratky specifické pro fázi, protože souhrnná trasa a zkratka mohou vést k velmi odlišnému předávání, než naznačuje diagram.

K prosazení regionálního oddělení používejte směrování a přístupovou politiku. Pokud pobočka nesmí přímo dosáhnout jiné oblasti, musí to říci trasa a politika, místo spoléhání na identifikátor, který k tomu nikdy nebyl navržen. Zapište politiku vedle identifikátoru. Jinak příští inženýr bude předpokládat, že práci dělá číslo.

Diagnostikujte neočekávanou zkratku

Když se pobočka pokusí vytvořit přímý vztah s centrálním bodem, prozkoumejte její trasu, její mapování NHRP a vybraný kontext tunelu, než začnete identifikátory měnit naslepo. Chybějící dostupnost, nezamýšlený vztah NHS a legitimní, ale nepovolená zkratka vyžadují tři různá opravení.

Průvodce konfigurací DMVPN ukazuje nastavení tunelu a NHRP společně, a právě proto je třeba obvody nejprve oddělit na papíře. Zaznamenejte smlouvy cloudu, udržujte trasy vrstev výslovné a příští selhání na hranici bude mít kam ukázat.