Vecinii EIGRP nu urcă pe suprastructura DMVPN

Unicast prin suprastructură funcționează, iar adiacența tot eșuează, așa că verificați replicarea multicast NHRP, politica EIGRP a tunelului și IPsec ca trei straturi separate.

Tunelul este sus, un spoke poate face ping la altul, iar EIGRP tot nu arată niciun vecin pe hub. Combinația aceasta este normală, nu misterioasă: pingul demonstrează accesibilitatea unicast prin NHRP, iar hello-urile EIGRP sunt multicast. Pe o suprastructură DMVPN, modelul de livrare al protocolului de rutare este o a doua suprafață de configurare, și exact pe aceea oamenii o sar pentru că prima suprafață pare deja sănătoasă. Fiecare strat de mai jos se verifică cu comanda lui, așa că o defecțiune într-un strat nu vă trimite înapoi în capul listei.

Notați adiacențele pe care le așteptați

Înainte de orice comandă show, faceți o listă scurtă: ce spoke trebuie să facă peering cu ce hub, prin ce interfață de tunel și în ce sistem autonom EIGRP. Proiectele cu mai multe huburi eșuează în golurile dintre huburi, iar o listă transformă „EIGRP este stricat” în „spoke 3 nu se înregistrează la hub 2”. Includeți subrețelele de tunel pe care le așteptați pe fiecare legătură, pentru că o nepotrivire de adrese între cele două capete arată exact ca o defecțiune de protocol. Scrieți lista pe tichet, ca tura următoare să compare cu proiectul, nu cu ultima captură de ecran.

Verificați NHRP, apoi calea multicast

Începeți cu starea de înregistrare și cu mapările pe care hubul le deține într-adevăr. Un spoke fără intrare dinamică pe hub nu s-a înregistrat, și niciun protocol de rutare nu repară asta. Apoi confirmați că spoke-ul acceptă multicast de la adresa NBMA a hubului, ceea ce este o linie separată de intrarea NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

Linia ip nhrp map multicast este cea care îi permite spoke-ului să trimită hello-urile către hub ca multicast replicat prin suprastructură și care permite multicastului hubului să ajungă la spoke-urile înregistrate. Fără ea, unicast prin NHRP funcționează, iar multicast nu, și exact această separare face un ping să pară o dovadă. Ghidul Cisco IOS XE DMVPN documentează comportamentul multicast al hubului și al spoke-urilor pentru fiecare fază, așa că potriviți configurația cu faza pe care ați implementat-o efectiv, în loc să copiați un fragment din altă topologie.

Verificați politica de interfață proprie a EIGRP

Un tunel care nu este în procesul EIGRP sau care este passive nu va forma niciodată o adiacență, oricât de sănătoasă ar fi suprastructura. Citiți împreună participarea interfeței și tabela de vecini, pentru că prima o explică pe a doua.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Autentificarea și ponderile metricii trebuie să coincidă la ambele capete. Un lanț de chei cu modul greșit sau o nepotrivire a valorii K aruncă hello-urile fără o linie syslog evidentă la receptor. Dacă proiectul folosește vecini unicast configurați explicit, urmați acel model în întregime în loc să îl suprapuneți peste setările multicast până când urcă ceva.

Țineți transportul GRE și protecția IPsec separate

DMVPN transportă multicast în interiorul GRE, iar IPsec protejează pachetele GRE, nu multicastul interior direct. De aceea afirmația generală că IPsec nu poate transporta multicast este greșită pentru acest proiect și inutilă ca diagnostic. Verificați profilul IPsec pe tunel, asocierile de securitate pentru fiecare peer și starea interfeței de tunel ca trei fapte separate.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

O SA care este sus și ale cărei contoare se mișcă în timp ce EIGRP rămâne jos readuce investigația în sus în stivă: pachetele sunt protejate și livrate, deci problema este ce pachete alege protocolul să trimită.

Verificați rutele, nu doar numărul de vecini

Odată ce adiacența se formează, citiți ce anunță și ce instalează. Pe un tunel multipunct, split horizon și comportamentul next-hop decid dacă un spoke poate ajunge la alt spoke prin hub, iar sumarizarea poate ascunde un prefix chiar și când relația de vecinătate este perfectă.

Încheiați cu o aplicație permisă între două locații și confirmați calea pe care o urmează. Scurtăturile directe spoke-to-spoke sunt o cerință de forwarding cu starea lor NHRP și de securitate, iar adăugarea lor ca numărul de vecini să arate mai bine creează de obicei o a doua problemă.

Notați proiectul pe faze, maparea multicast și politica EIGRP într-un singur loc. Următorul inginer va avea nevoie de proiect, nu de transcriere.

Articole similare