Hierarkisk DMVPN: én sky per tunnelrelasjon

En filialnode registrerer seg hos sitt regionale nav og kan fortsatt ikke nå en tjeneste i en annen region. Tunnelen er oppe, NHS-tilstanden ser sunn ut, og feilen vises bare for destinasjoner som krysser en nivågrense. Det mønsteret betyr vanligvis at designet aldri sa hvilke enheter som deltar i hvilken DMVPN-sky, så nivåene ble bygget på intuisjon og stemmer nå ikke overens.

Symptomet vises ved nivågrensen

I et hierarkisk design har et sentralt nav, flere regionale nav og mange filialnoder hver sin posisjon. Et regionalt nav kan eie mer enn én tunnelrelasjon, og filialer trenger ikke registrere seg ved hvert sentralt endepunkt. Veiene som betyr noe, er filial til regional tjeneste, filial til en annen godkjent regional node og filial til en sentral destinasjon.

Når en av disse veiene svikter mens de andre virker, er problemet nesten alltid en manglende eller motstridende rolledefinisjon og ikke en ødelagt tunnel. Skriv ned de tiltenkte veiene og sammenlign dem med det enhetene faktisk bygde. Den sammenligningen tar en time og forhindrer en uke med gjetting. Oppbevar den sammen med designdokumentet.

Én sky, én grensesnittkontrakt

For hver sky, registrer tunnelgrensesnittet, overlay-adresseringen, den lokale underliggende kilden, NHS- og NBMA-relasjonene, multicast-leveringen og beskyttelsespolicyen. Oppgi også hvilke ruter som krysser mellom den regionale og den sentrale konteksten, fordi nettopp den setningen er designet.

Et regionalt nav med to tunnelgrensesnitt trenger to kontrakter, ikke én med to adresser. Den underliggende kilden, NHRP-domenet og rutene kan variere per grensesnitt, og et dokument som slår dem sammen, vil villede den som konfigurerer det andre.

ID-er er lokal kontekst, ikke tilgangskontroll

NHRP-nettverks-ID-er og GRE-nøkler er de to verdiene som oftest forveksles med globale innstillinger. IOS XE NHRP-veiledningen beskriver nettverks-ID-en som lokalt betydningsfull, så samsvarende numre på eksterne rutere autentiserer ingenting, og å endre én routers lokale nummer skaper ingen tilgangsgrense.

En GRE-nøkkel, der designet bruker en, hjelper med å identifisere den mottakende tunnelkonteksten, og den avtales mellom endepunktene som deler den konteksten. Den er ikke et passord og erstatter ikke IKE-autentisering eller rutingpolicy. Behandle begge verdiene som konfigurasjonskontekst som må stemme innenfor en relasjon, ikke som sikkerhetskontroller som skiller regioner.

Rut mellom nivåene med vilje

Bestem hvilke prefikser det regionale navet annonserer oppover, og hvilke sentrale destinasjoner det tilbyr filialene sine. Sjekk deretter den faktiske neste hoppet og den fasespesifikke snarveiadferden for hver vei, fordi en oppsummeringsrute og en snarvei kan gi helt annen videresending enn diagrammet antyder.

Bruk ruting og tilgangspolicy for å håndheve regional separasjon. Hvis en filial ikke skal nå en annen region direkte, må ruten og policyen si det, i stedet for å stole på en ID som aldri var designet for å håndheve det. Skriv policyen ved siden av ID-en. Ellers vil den neste ingeniøren anta at nummeret gjør jobben.

Diagnostiser den uventede snarveien

Når en filial prøver å opprette en direkte relasjon til et sentralt endepunkt, undersøk ruten, NHRP-mappingen og den valgte tunnelkonteksten før du endrer ID-er tilfeldig. Manglende nåbarhet, en utilsiktet NHS-relasjon og en legitim, men uautorisert snarvei krever tre forskjellige rettelser.

DMVPN-konfigurasjonsveiledningen viser tunnel- og NHRP-innstillingene sammen, og nettopp derfor må omfangene skilles på papiret først. Registrer skykontraktene, hold nivårutene eksplisitte, og den neste grensefeilen vil ha noe å peke på.