EIGRP-naboen kjem ikkje opp på DMVPN-overlayet

Tunnelen er oppe, éin spoke kan pinga ein annan, og EIGRP viser framleis ingen nabo på huben. Den kombinasjonen er normal og ikkje mystisk: ein ping provar unicast-nåbarheit gjennom NHRP, og EIGRP-helloar er multicast. På eit DMVPN-overlay er leveringsmodellen til ruteprotokollen ein andre konfigurasjonsflate, og det er den folk hoppar over fordi den første flata alt ser sunn ut. Kvart lag nedanfor blir kontrollert med si eiga kommando, så ein feil i eitt lag sender deg ikkje tilbake til toppen av lista.

Skriv ned nabo-tilhøva du ventar

Før kvar einaste show-kommando, lag ei kort liste: kva for ein spoke som skal peera med kva for ein hub, over kva for eit tunnelgrensesnitt, i kva for eit autonomt EIGRP-system. Design med fleire hubar feilar i hola mellom hubane, og ei liste gjer «EIGRP er øydelagt» om til «spoke 3 registrerer seg ikkje hos hub 2». Ta med tunnel-subnetta du ventar på kvar lenke, fordi ein adresseskilnad mellom dei to endane ser nøyaktig ut som ein protokollfeil. Skriv lista i billetten, slik at neste skift samanliknar med designet og ikkje med det siste skjermbiletet.

Kontroller NHRP, deretter multicast-stien

Start med registreringstilstand og tilordningane huben faktisk held. Ein spoke utan dynamisk oppføring på huben er ikkje registrert, og ingen ruteprotokoll rettar det. Stadfest deretter at spoken tek imot multicast frå NBMA-adressa til huben, som er ei eiga line frå NHS-oppføringa.

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

Det er lina ip nhrp map multicast som lèt spoken senda helloane sine til huben som replikert multicast over overlayet, og som lèt multicast-en til huben nå dei spokane han har registrert. Utan henne verkar unicast gjennom NHRP og multicast gjer det ikkje, og det er nettopp denne delinga som får ein ping til å sjå ut som eit prov. Ciscons IOS XE DMVPN-rettleiar dokumenterer multicast-åtferda til hub og spoke for kvar fase, så tilpass konfigurasjonen til fasen du faktisk rulla ut, i staden for å kopiera eit fragment frå ein annan topologi.

Kontroller grensesnittpolicyen til EIGRP sjølv

Ein tunnel som ikkje er i EIGRP-prosessen, eller som er passive, dannar aldri eit nabo-tilhøve, uansett kor sunn overlayet er. Les deltakinga til grensesnittet og nabotabellen saman, fordi den første forklarer den andre.

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

Autentisering og metrikkvekter må stemma i båe endar. Ei nøkkelkjede med feil modus, eller usemje om K-verdien, slepp helloar utan ei tydeleg syslog-line hos mottakaren. Viss designet brukar eksplisitt konfigurerte unicast-naboar, følg den modellen fullt ut i staden for å leggja han oppå multicast-innstillingane til noko kjem opp.

Hald GRE-transport og IPsec-vern skilde

DMVPN fraktar multicast inne i GRE, og IPsec vernar GRE-pakkane i staden for den indre multicast-en direkte. Difor er den generelle påstanden om at IPsec ikkje kan frakta multicast feil for dette designet og ubrukeleg som diagnose. Kontroller IPsec-profilen på tunnelen, tryggingsassosiasjonane for kvar peer og tilstanden til tunnelgrensesnittet som tre separate fakta.

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

Ein SA som er oppe med teljarar som flyttar seg medan EIGRP blir nede, flyttar undersøkinga tilbake opp i stakken: pakkane blir verna og leverte, så problemet er kva for nokre pakkar protokollen vel å senda.

Verifiser ruter, ikkje berre nabo-tal

Når nabo-tilhøvet er danna, les kva det annonserer og installerer. På ein multipoint-tunnel avgjer split horizon og next-hop-åtferd om ein spoke kan nå ein annan spoke gjennom huben, og oppsummering kan skjula eit prefiks sjølv om nabo-tilhøvet er perfekt.

Avslutt med ein tillaten applikasjon mellom to nettstader og stadfest stien han tek. Direkte spoke-til-spoke-snarvegar er eit videresendingskrav med sin eigen NHRP- og tryggingsstatus, og å leggja dei til for å få nabo-talet til å sjå betre ut skaper vanlegvis eit andre problem.

Skriv ned det fasedelte designet, multicast-tilordninga og EIGRP-policyen på ein stad. Den neste ingeniøren treng designet, ikkje transkripsjonen.