Az EIGRP szomszédok nem jönnek fel a DMVPN átfedésen

Az alagút fent van, az egyik spoke pingelni tud egy másikat, az EIGRP mégsem mutat szomszédot a hubon. Ez a kombináció normális, nem rejtélyes: a ping az NHRP-n át bizonyítja az unicast elérhetőséget, az EIGRP hello üzenetei pedig multicastok. Egy DMVPN átfedésen az útválasztási protokoll kézbesítési modellje egy második konfigurációs felület, és éppen ezt hagyják ki az emberek, mert az első felület már egészségesnek látszik. Az alábbi rétegek mindegyike a saját parancsával ellenőrizhető, így az egyik réteg hibája nem küldi vissza a lista elejére.

Írja fel az elvárt szomszédságokat

Bármely show parancs előtt készítsen rövid listát: melyik spoke melyik hubbal peereljen, melyik alagút-interfészen és melyik EIGRP autonóm rendszerben. A több hubos tervek a hubok közötti hézagokban buknak el, és a lista az „az EIGRP elromlott” mondatot „a spoke 3 nem regisztrál a hub 2-n” mondattá alakítja. Vegye fel azokat az alagút-alhálózatokat, amelyeket az egyes linkeken elvár, mert a két vég közötti címeltérés pontosan protokollhibának látszik. Írja fel a listát a ticketre, hogy a következő műszak a tervhez hasonlítson, ne az utolsó képernyőfotóhoz.

Ellenőrizze az NHRP-t, majd a multicast útvonalat

Kezdje a regisztrációs állapottal és a hub által tényleg tartott leképezésekkel. Az a spoke, amelynek nincs dinamikus bejegyzése a hubon, nem regisztrált, és ezt egyetlen útválasztási protokoll sem javítja. Ezután erősítse meg, hogy a spoke elfogad multicastot a hub NBMA-címéről, ami külön sor az NHS-bejegyzéstől.

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

Éppen a ip nhrp map multicast sor az, amely engedi, hogy a spoke a hellóit replikált multicastként küldje a hubnak az átfedésen, és amely engedi, hogy a hub multicastja elérje a regisztrált spokékat. Nélküle az NHRP-n át az unicast működik, a multicast nem, és éppen ez a szétválás teszi a pinget bizonyítéknak látszó dologgá. A Cisco útmutatója IOS XE DMVPN minden fázisra dokumentálja a hub és a spokék multicast-viselkedését, ezért a konfigurációt ahhoz a fázishoz igazítsa, amelyet valóban telepített, ne pedig egy másik topológiából másoljon részletet.

Ellenőrizze az EIGRP saját interfész-szabályát

Egy alagút, amely nincs benne az EIGRP-folyamatban, vagy passive, soha nem hoz létre szomszédságot, akármilyen egészséges az átfedés. Az interfész részvételét és a szomszédtáblát együtt olvassa, mert az első magyarázza a másodikat.

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

A hitelesítésnek és a metrikasúlyoknak mindkét végén egyezniük kell. A rossz módú kulcslánc vagy a K-érték eltérése eldobja a hellókat anélkül, hogy a fogadónál nyilvánvaló syslog-sor keletkezne. Ha a terv kifejezetten beállított unicast szomszédokat használ, kövesse azt a modellt teljesen, ahelyett hogy a multicast-beállításokra rétegezné, amíg valami fel nem jön.

Tartsa külön a GRE-szállítást és az IPsec-védelmet

A DMVPN a multicastot a GRE-n belül szállítja, az IPsec pedig a GRE-csomagokat védi, nem a belső multicastot közvetlenül. Ezért az a sommás állítás, hogy az IPsec nem tud multicastot szállítani, erre a tervre nézve hibás és diagnózisként haszontalan. Ellenőrizze az alagút IPsec-profilját, az egyes peerek biztonsági társulásait és az alagút-interfész állapotát három külön tényként.

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

Egy fent lévő, mozgó számlálójú SA, miközben az EIGRP lent marad, visszaviszi a vizsgálatot a verem teteje felé: a csomagok védettek és kézbesítettek, tehát a probléma az, hogy a protokoll mely csomagokat választja elküldésre.

Az útvonalakat ellenőrizze, ne csak a szomszédok számát

Amint létrejön a szomszédság, olvassa el, mit hirdet és telepít. Egy többpontos alagúton a split horizon és a next-hop viselkedése dönti el, elér-e egy spoke a hubon át egy másik spokét, és az összegzés elrejthet egy prefixet akkor is, ha a szomszédsági viszony tökéletes.

Fejezze be egy engedélyezett alkalmazással két telephely között, és erősítse meg az útvonalat, amelyet használ. A közvetlen spoke-to-spoke átjárók saját NHRP- és biztonsági állapotú továbbítási követelmények, és a hozzáadásuk, hogy a szomszédszám jobban nézzen ki, általában második problémát szül.

Rögzítse a fázisos tervet, a multicast-leképezést és az EIGRP-szabályt egy helyen. A következő mérnöknek a tervre lesz szüksége, nem az átiratra.