DMVPN ierarhic: un singur cloud pentru fiecare relație de tunel

Un nod de filială se înregistrează cu succes la hubul său regional și tot nu ajunge la un serviciu din altă regiune. Tunelul este activ, starea NHS pare sănătoasă, iar defectul apare doar pentru destinațiile care traversează o graniță de nivel. Acest tipar înseamnă de obicei că proiectarea nu a precizat niciodată ce dispozitive participă la ce cloud DMVPN, așa că nivelurile au fost construite din intuiție și acum nu mai concordă.

Simptomul apare la granița nivelurilor

Într-o proiectare ierarhică, un hub central, mai multe huburi regionale și multe filiale ocupă fiecare o poziție. Un hub regional poate deține mai mult de o relație de tunel, iar filialele nu trebuie să se înregistreze la fiecare punct final central. Căile care contează sunt de la filială la serviciul regional, de la filială la un alt nod regional aprobat și de la filială la o destinație centrală.

Când una dintre aceste căi eșuează în timp ce celelalte funcționează, problema este aproape întotdeauna o definiție de rol lipsă sau contradictorie, nu un tunel defect. Notați căile intenționate și comparați-le cu ceea ce au construit efectiv dispozitivele. Acea comparație durează o oră și previne o săptămână de presupuneri. Păstrați-o împreună cu documentul de proiectare.

Un cloud, un contract de interfață

Pentru fiecare cloud, notați interfața tunelului, adresarea de suprapunere, sursa locală a rețelei de bază, relațiile NHS și NBMA, livrarea multicast și politica de protecție. Indicați și ce rute trec între contextul regional și cel central, pentru că acea propoziție este proiectarea.

Un hub regional cu două interfețe de tunel are nevoie de două contracte, nu de unul cu două adrese. Sursa rețelei de bază, domeniul NHRP și rutele pot diferi pentru fiecare interfață, iar un document care le fuzionează îl va induce în eroare pe cel care configurează a doua.

ID-urile sunt context local, nu control de acces

ID-urile de rețea NHRP și cheile GRE sunt cele două valori cel mai des confundate cu setări globale. Ghidul NHRP din IOS XE descrie ID-ul de rețea ca fiind semnificativ local, așa că numerele identice de pe routerele la distanță nu autentifică nimic, iar schimbarea numărului local al unui router nu creează o graniță de acces.

O cheie GRE, unde proiectarea folosește una, ajută la identificarea contextului tunelului receptor și este convenită între punctele finale care împărtășesc acel context. Nu este o parolă și nu înlocuiește autentificarea IKE sau politica de rutare. Tratați ambele valori ca context de configurare care trebuie să coincidă în cadrul unei relații, nu ca mecanisme de securitate care separă regiunile.

Rutați deliberat între niveluri

Decideți ce prefixe anunță hubul regional în sus și ce destinații centrale oferă filialelor sale. Apoi verificați următorul salt real și comportamentul de scurtătură specific fazei pentru fiecare cale, deoarece o rută sumară și o scurtătură pot produce o redirecționare foarte diferită de ce sugerează diagrama.

Folosiți rutarea și politica de acces pentru a impune separarea regională. Dacă o filială nu trebuie să ajungă direct în altă regiune, ruta și politica trebuie să spună acest lucru, în loc să se bazeze pe un ID care nu a fost niciodată conceput pentru a-l impune. Scrieți politica lângă ID. Altfel următorul inginer va presupune că numărul face treaba.

Diagnosticați scurtătura neașteptată

Când o filială încearcă să creeze o relație directă cu un punct final central, examinați ruta, maparea NHRP și contextul tunelului selectat înainte de a schimba ID-urile la întâmplare. Lipsa accesibilității, o relație NHS neintenționată și o scurtătură legitimă dar neautorizată necesită trei corecturi diferite.

Ghidul de configurare DMVPN arată setările tunelului și ale NHRP împreună, și exact de aceea domeniile trebuie separate mai întâi pe hârtie. Notați contractele cloudului, păstrați rutele nivelurilor explicite, iar următorul defect de graniță va avea unde să indice.