Hierarkisk DMVPN: éi sky per tunnelrelasjon

Ein filialnode registrerer seg hjå det regionale navet sitt og kan framleis ikkje nå ein teneste i ein annan region. Tunnelen er oppe, NHS-tilstanden ser sunn ut, og feilen viser seg berre for mål som kryssar ei nivågrense. Det mønsteret tyder vanlegvis at designet aldri sa kva einingar som deltek i kva DMVPN-sky, så nivåa vart bygde på intuisjon og stemmer no ikkje overeins.

Symptomet viser seg ved nivågrensa

I eit hierarkisk design har eit sentralt nav, fleire regionale nav og mange filialnodar kvar sin posisjon. Eit regionalt nav kan eige meir enn éin tunnelrelasjon, og filialar treng ikkje registrere seg ved kvart sentralt endepunkt. Vegane som tel, er filial til regional teneste, filial til ein annan godkjend regional node og filial til ein sentral destinasjon.

Når ein av desse vegane sviktar medan dei andre verkar, er problemet nesten alltid ein manglande eller motstridande rolledefinisjon og ikkje ein øydelagd tunnel. Skriv ned dei tiltenkte vegane og samanlikn dei med det einingane faktisk bygde. Den samanlikninga tek ein time og hindrar ei veke med gjetting. Oppbevar henne saman med designdokumentet.

Éi sky, éin grensesnittkontrakt

For kvar sky, registrer tunnelgrensesnittet, overlay-adresseringa, den lokale underliggjande kjelda, NHS- og NBMA-relasjonane, multicast-leveringa og beskyttelsespolitikken. Oppgi òg kva ruter som kryssar mellom den regionale og den sentrale konteksten, fordi nettopp den setninga er designet.

Eit regionalt nav med to tunnelgrensesnitt treng to kontraktar, ikkje éin med to adresser. Den underliggjande kjelda, NHRP-domenet og rutene kan variere per grensesnitt, og eit dokument som slår dei saman, vil villede den som konfigurerer det andre.

ID-ar er lokal kontekst, ikkje tilgangskontroll

NHRP-nettverks-ID-ar og GRE-nøklar er dei to verdiane som oftast vert forveksla med globale innstillingar. IOS XE NHRP-veiledninga skildrar nettverks-ID-en som lokalt tydingsfull, så samsvarande nummer på eksterne rutarar autentiserer ingenting, og å endre det lokale nummeret til éin rutar skaper inga tilgangsgrense.

Ein GRE-nøkkel, der designet brukar ein, hjelper med å identifisere konteksten til den mottakande tunnelen, og han vert avtalt mellom endepunkta som deler den konteksten. Han er ikkje eit passord og erstattar ikkje IKE-autentisering eller rutepolitikk. Behandle båe verdiane som konfigurasjonskontekst som må stemme innanfor ein relasjon, ikkje som tryggingskontrollar som skil regionar.

Rut mellom nivåa med vilje

Avgjer kva prefiks det regionale navet annonserer oppover, og kva sentrale destinasjonar det tilbyr filialane sine. Sjekk deretter den faktiske neste hoppet og den fasespesifikke snarvegåferda for kvar veg, fordi ei oppsummeringsrute og ein snarveg kan gje heilt anna vidaresending enn diagrammet antydar.

Bruk ruting og tilgangspolitikk for å handheve regional separasjon. Viss ein filial ikkje skal nå ein annan region direkte, må ruta og politikken seie det, i staden for å stole på ein ID som aldri var designa for å handheve det. Skriv politikken ved sida av ID-en. Elles vil den neste ingeniøren gå ut frå at nummeret gjer jobben.

Diagnostiser den uventa snarvegen

Når ein filial prøver å opprette ein direkte relasjon til eit sentralt endepunkt, undersøk ruta, NHRP-mappinga og den valde tunnelkonteksten før du endrar ID-ar tilfeldig. Manglande nåbarheit, ein utilsikta NHS-relasjon og ein legitim, men uautorisert snarveg krev tre ulike rettingar.

DMVPN-konfigurasjonsveiledninga viser tunnel- og NHRP-innstillingane saman, og nettopp derfor må omfanga skiljast på papiret først. Registrer skykontraktane, hald nivårutene eksplisitte, og den neste grensefeilen vil ha noko å peike på.