EIGRP-naapurit eivät nouse DMVPN-kerroksessa

Tunneli on ylhäällä, yksi spoke voi pingata toista, eikä EIGRP silti näytä yhtään naapuria hubilla. Yhdistelmä on normaali eikä salaperäinen: ping todistaa unicast-tavoitettavuuden NHRP:n kautta, ja EIGRP:n hellot ovat multicastia. DMVPN-kerroksessa reititysprotokollan toimitusmalli on toinen konfiguraatiopinta, ja juuri sen ihmiset ohittavat, koska ensimmäinen pinta näyttää jo terveeltä. Jokainen alla oleva kerros tarkistetaan omalla komennollaan, joten yhden kerroksen vika ei lähetä sinua takaisin listan alkuun.

Kirjoita ylös ne naapuruudet, joita odotat

Tee ennen mitä tahansa show-komentoa lyhyt lista: minkä spokan pitää peer-oitua minkä hubin kanssa, minkä tunneliliitännän kautta ja missä EIGRP-autonomisessa järjestelmässä. Monen hubin mallit epäonnistuvat hubien välisissä aukoissa, ja lista muuttaa lauseen „EIGRP on rikki“ muotoon „spoke 3 ei rekisteröidy hubille 2“. Lisää tunneliverkot, joita kullakin linkillä odotat, koska osoitteiden eroavuus päiden välillä näyttää täsmälleen protokollavian kaltaiselta. Kirjoita lista tikettiin, jotta seuraava vuoro vertaa suunnitelmaan eikä viimeiseen kuvakaappaukseen.

Tarkista NHRP ja sitten multicast-polku

Aloita rekisteröinnin tilasta ja kartoituksista, joita hubi todella pitää. Spoka, jolla ei ole dynaamista merkintää hubilla, ei ole rekisteröitynyt, eikä mikään reititysprotokolla korjaa sitä. Varmista sitten, että spoka hyväksyy multicasting hubin NBMA-osoitteesta, mikä on erillinen rivi NHS-merkinnästä.

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

Juuri rivi ip nhrp map multicast antaa spokan lähettää hellonsa hubille monistettuna multicastina kerroksen yli ja antaa hubin multicasting päästä rekisteröityihin spokoihin. Ilman sitä unicast NHRP:n kautta toimii ja multicast ei, ja juuri tämä jako saa pingin näyttämään todisteelta. Ciscon opas IOS XE DMVPN dokumentoi hubin ja spokojen multicast-käyttäytymisen jokaista vaihetta varten, joten sovita kokoonpanosi siihen vaiheeseen, jonka todella otit käyttöön, sen sijaan että kopioisit katkelman toisesta topologiasta.

Tarkista EIGRP:n oma liitäntäkäytäntö

Tunneli, joka ei ole EIGRP-prosessissa tai on passive, ei koskaan muodosta naapuruutta, oli kerros miten terve tahansa. Lue liitännän osallistuminen ja naapuritaulukko yhdessä, koska ensimmäinen selittää toisen.

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

Todennuksen ja metripainojen on täsmättävä molemmissa päissä. Väärän tilan avainketju tai K-arvon eroavuus pudottaa hellot ilman ilmeistä syslog-riviä vastaanottajalla. Jos suunnitelma käyttää nimenomaisesti määritettyjä unicast-naapureita, seuraa sitä mallia kokonaan sen sijaan, että kerrostaisit sen multicast-asetusten päälle, kunnes jotain nousee.

Pidä GRE-kuljetus ja IPsec-suoja erillään

DMVPN kuljettaa multicasting GRE:n sisällä, ja IPsec suojaa GRE-paketit eikä sisäistä multicastia suoraan. Siksi yleinen väite, että IPsec ei voi kuljettaa multicastia, on tälle suunnitelmalle väärä ja diagnoosina hyödytön. Tarkista tunnelin IPsec-profiili, kunkin peerin tietoturvayhdistykset ja tunneliliitännän tila kolmena erillisenä tosiasiana.

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

SA, joka on ylhäällä ja jonka laskurit liikkuvat EIGRP:n pysyessä alhaalla, vie tutkintasi takaisin pinon yläpäähän: paketit suojataan ja toimitetaan, joten ongelma on siinä, mitkä paketit protokolla valitsee lähetettäväksi.

Tarkista reitit, älä vain naapurien määrää

Kun naapuruus muodostuu, lue mitä se mainostaa ja asentaa. Monipisteisessä tunnelissa split horizon ja next-hop-käyttäytyminen ratkaisevat, pääseekö spoka toiseen spokaan hubin kautta, ja summarointi voi piilottaa etuliitteen, vaikka naapuruussuhde olisi täydellinen.

Lopeta kahden toimipisteen väliseen sallittuun sovellukseen ja varmista polku, jonka se ottaa. Suorat spoke-to-spoke-oikopolut ovat edelleenlähetysvaatimus omalla NHRP- ja tietoturvatilallaan, ja niiden lisääminen naapurimäärän parantamiseksi luo yleensä toisen ongelman.

Kirjaa vaiheittainen suunnitelma, multicast-kartoitus ja EIGRP-käytäntö yhteen paikkaan. Seuraava insinööri tarvitsee suunnitelman, ei litterointia.