Hierarkisk DMVPN: ett moln per tunnelrelation

En filialnod registrerar sig framgångsrikt hos sin regionala hubb och kan ändå inte nå en tjänst i en annan region. Tunneln är uppe, NHS-tillståndet ser friskt ut, och felet visas bara för destinationer som korsar en nivågräns. Det mönstret betyder vanligtvis att designen aldrig angav vilka enheter som deltar i vilket DMVPN-moln, så nivåerna byggdes på intuition och stämmer nu inte överens.

Symtomet visar sig vid nivågränsen

I en hierarkisk design har en central hubb, flera regionala hubbar och många filialnoder var sin position. En regional hubb kan äga mer än en tunnelrelation, och filialer behöver inte registrera sig hos varje central ändpunkt. De vägar som spelar roll är filial till regional tjänst, filial till en annan godkänd regional nod och filial till en central destination.

När en av dessa vägar fallerar medan de andra fungerar är problemet nästan alltid en saknad eller motstridig rolldefinition och inte en trasig tunnel. Skriv ned de avsedda vägarna och jämför dem med vad enheterna faktiskt byggde. Den jämförelsen tar en timme och förhindrar en vecka av gissningar. Förvara den tillsammans med designdokumentet.

Ett moln, ett gränssnittsavtal

För varje moln, registrera tunnelgränssnittet, overlay-adresseringen, den lokala underliggande källan, NHS- och NBMA-relationerna, multicast-leveransen och skyddspolicyn. Ange också vilka rutter som går mellan den regionala och den centrala kontexten, eftersom just den meningen är designen.

En regional hubb med två tunnelgränssnitt behöver två avtal, inte ett med två adresser. Den underliggande källan, NHRP-domänen och rutterna kan variera per gränssnitt, och ett dokument som slår ihop dem kommer att vilseleda den som konfigurerar det andra.

ID:n är lokal kontext, inte åtkomstkontroll

NHRP-nätverks-ID:n och GRE-nycklar är de två värden som oftast felaktigt tas för globala inställningar. IOS XE NHRP-guiden beskriver nätverks-ID:t som lokalt betydelsefullt, så matchande nummer på fjärroutrar autentiserar ingenting och att ändra en routers lokala nummer skapar ingen åtkomstgräns.

En GRE-nyckel, där designen använder en, hjälper till att identifiera den mottagande tunnelkontexten, och den avtalas mellan de ändpunkter som delar den kontexten. Den är inte ett lösenord och ersätter inte IKE-autentisering eller routingpolicy. Behandla båda värdena som konfigurationskontext som måste stämma inom en relation, inte som säkerhetskontroller som skiljer regioner åt.

Routa mellan nivåerna med avsikt

Bestäm vilka prefix den regionala hubben annonserar uppåt och vilka centrala destinationer den erbjuder sina filialer. Kontrollera sedan den faktiska nästa hoppen och det fasspecifika genvägsbeteendet för varje väg, eftersom en sammanfattningsrutt och en genväg kan ge en helt annan vidarebefordran än diagrammet antyder.

Använd routing och åtkomstpolicy för att upprätthålla regional separation. Om en filial inte får nå en annan region direkt måste rutten och policyn säga det, i stället för att förlita sig på ett ID som aldrig var designat för att upprätthålla det. Skriv policyn bredvid ID:t. Annars kommer nästa ingenjör att anta att numret gör jobbet.

Diagnostisera den oväntade genvägen

När en filial försöker skapa en direkt relation till en central ändpunkt, undersök dess rutt, dess NHRP-mappning och den valda tunnelkontexten innan du ändrar ID:n slumpmässigt. Saknad nåbarhet, en oavsiktlig NHS-relation och en legitim men otillåten genväg kräver tre olika korrigeringar.

DMVPN-konfigurationsguiden visar tunnel- och NHRP-inställningarna tillsammans, och det är just därför omfången först måste separeras på papper. Registrera molnets avtal, håll nivårutterna explicita, och nästa gränsfel kommer att ha något att peka på.