Hierarkisk DMVPN: én sky per tunnelrelation

En filialknude registrerer sig hos sit regionale hub og kan stadig ikke nå en tjeneste i en anden region. Tunnelen er oppe, NHS-tilstanden ser sund ud, og fejlen vises kun for destinationer, der krydser en niveaugrænse. Det mønster betyder normalt, at designet aldrig angav, hvilke enheder der deltager i hvilken DMVPN-sky, så niveauerne blev bygget på intuition og stemmer nu ikke overens.

Symptomet vises ved niveaugrænsen

I et hierarkisk design har et centralt hub, flere regionale hubs og mange filialknuder hver deres position. Et regionalt hub kan eje mere end én tunnelrelation, og filialer behøver ikke at registrere sig ved hvert centralt endepunkt. De veje, der betyder noget, er filial til regional tjeneste, filial til en anden godkendt regional knude og filial til en central destination.

Når en af disse veje fejler, mens de andre virker, er problemet næsten altid en manglende eller modstridende rolledefinition og ikke en brudt tunnel. Skriv de tilsigtede veje ned, og sammenlign dem med det, enhederne faktisk har bygget. Den sammenligning tager en time og forhindrer en uges gætteri. Opbevar den sammen med designdokumentet.

Én sky, én interfacekontrakt

For hver sky skal du registrere tunnelinterfacet, overlay-adresseringen, den lokale underliggende kilde, NHS- og NBMA-relationerne, multicast-levering og beskyttelsespolitikken. Angiv også, hvilke ruter der krydser mellem den regionale og den centrale kontekst, fordi netop den sætning er designet.

Et regionalt hub med to tunnelinterfaces har brug for to kontrakter, ikke én med to adresser. Den underliggende kilde, NHRP-domænet og ruterne kan variere per interface, og et dokument, der slår dem sammen, vil vildlede den, der konfigurerer det andet.

ID'er er lokal kontekst, ikke adgangskontrol

NHRP-netværks-ID'er og GRE-nøgler er de to værdier, der oftest forveksles med globale indstillinger. IOS XE NHRP-vejledningen beskriver netværks-ID'et som lokalt betydningsfuldt, så matchende numre på fjerne routere godkender intet, og ændring af én routers lokale nummer skaber ingen adgangsgrænse.

En GRE-nøgle, hvor designet bruger en, hjælper med at identificere den modtagende tunnelkontekst, og den aftales mellem de endepunkter, der deler den kontekst. Den er ikke en adgangskode og erstatter ikke IKE-godkendelse eller rutepolitik. Behandl begge værdier som konfigurationskontekst, der skal stemme overens inden for en relation, ikke som sikkerhedskontroller, der adskiller regioner.

Rut mellem niveauer med vilje

Beslut, hvilke præfikser det regionale hub annoncerer opad, og hvilke centrale destinationer det tilbyder sine filialer. Kontroller derefter det faktiske næste hop og den fasespecifikke genvejsadfærd for hver vej, fordi en summeringsrute og en genvej kan give en helt anden videresendelse, end diagrammet antyder.

Brug routing og adgangspolitik til at håndhæve regional adskillelse. Hvis en filial ikke må nå en anden region direkte, skal ruten og politikken sige det i stedet for at stole på et ID, der aldrig var designet til at håndhæve det. Skriv politikken ved siden af ID'et. Ellers vil den næste ingeniør antage, at nummeret gør arbejdet.

Diagnoser den uventede genvej

Når en filial forsøger at oprette en direkte relation til et centralt endepunkt, skal du undersøge dens rute, dens NHRP-mapping og den valgte tunnelkontekst, før du ændrer ID'er tilfældigt. Manglende nåbarhed, en utilsigtet NHS-relation og en legitim, men uautoriseret genvej kræver tre forskellige rettelser.

DMVPN-konfigurationsvejledningen viser tunnel- og NHRP-indstillingerne sammen, og netop derfor skal scope-adskillelsen ske på papir først. Registrer skyens kontrakter, hold niveauruterne eksplicitte, og den næste grænsefejl vil have noget at pege på.