EIGRP-naabrid ei tõuse DMVPN-i pealiskihis

Unicast üle pealiskihi töötab ja naabersuhe ikka ei teki, seega kontrollige NHRP multicast-kordust, tunneli EIGRP-poliitikat ja IPsec-i kolme eraldi kihina.

Tunnel on üleval, üks spoke saab teist pingida ja EIGRP ei näita jaoturis ikkagi ühtegi naabrit. See kombinatsioon on normaalne, mitte müstiline: ping tõestab unicast-kättesaadavust läbi NHRP ja EIGRP hello sõnumid on multicast. DMVPN-i pealiskihis on marsruutimisprotokolli edastusmudel teine konfiguratsioonipind ja just selle jätavad inimesed vahele, sest esimene pind näib juba terve. Iga kiht allpool kontrollitakse oma käsuga, nii et tõrge ühes kihis ei saada teid tagasi nimekirja algusesse.

Kirjutage üles naabersuhted, mida ootate

Enne mis tahes show-käsku tehke lühike nimekiri: milline spoke peaks peerima millise jaoturiga, millise tunneliliidese kaudu ja millises EIGRP autonoomses süsteemis. Mitme jaoturiga lahendused nurjuvad jaoturite vahelistes tühikutes, ja nimekiri muudab „EIGRP on katki“ lauseks „spoke 3 ei registreeru jaoturis 2“. Lisage tunnelivõrgud, mida igal lingil ootate, sest aadresside lahknevus kahe otsa vahel näeb täpselt välja nagu protokollitõrge. Kirjutage nimekiri piletile, et järgmine vahetus võrdleks projekteeritud lahendusega, mitte viimase ekraanipildiga.

Kontrollige NHRP-d, seejärel multicast-teed

Alustage registreerimise olekust ja vastendustest, mida jaotur tegelikult hoiab. Spoke, millel jaoturis dünaamiline kirje puudub, ei ole registreerunud ja ükski marsruutimisprotokoll ei paranda seda. Seejärel kinnitage, et spoke võtab multicast vastu jaoturi NBMA-aadressilt, mis on NHS-kirjest eraldi rida.

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

Just rida ip nhrp map multicast lubab spokel saata oma hellod jaoturile pealiskihis kordatud multicastina ja lubab jaoturi multicastil jõuda registreeritud spokede juurde. Ilma selleta töötab unicast läbi NHRP ja multicast ei tööta, ning just see lõhe paneb pingi tõestusena näima. Cisco juhend IOS XE DMVPN dokumenteerib jaoturi ja spokede multicast-käitumise iga faasi jaoks, seega sobitage oma konfiguratsioon faasiga, mille tegelikult juurutasite, selle asemel et kopeerida fragment teisest topoloogiast.

Kontrollige EIGRP-i enda liidesepoliitikat

Tunnel, mis ei ole EIGRP-protsessis või on passive, ei moodusta naabersuhet kunagi, ükskõik kui terve pealiskiht on. Lugege liidese osalust ja naabritabelit koos, sest esimene selgitab teist.

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

Autentimine ja meetrika kaalud peavad mõlemas otsas kokku langema. Vale režiimiga võtmeahel või K-väärtuse lahknevus heidab hellod kõrvale ilma vastuvõtjas ilmse syslog-reata. Kui lahendus kasutab selgesõnaliselt konfigureeritud unicast-naabreid, järgige seda mudelit täielikult, selle asemel et laduda seda multicast-seadete peale, kuni midagi üles tuleb.

Hoidke GRE vedu ja IPsec-kaitse eraldi

DMVPN kannab multicasti GRE sees ja IPsec kaitseb GRE-pakette, mitte sisemist multicasti otse. Seetõttu on üldine väide, et IPsec ei saa multicasti kanda, selle lahenduse jaoks vale ja diagnoosina kasutu. Kontrollige tunnelil IPsec-profiili, iga peeri turvaassotsiatsioone ja tunneliliidese olekut kolme eraldi faktina.

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

SA, mis on üleval ja mille loendurid liiguvad, samal ajal kui EIGRP jääb alla, viib teie uurimise tagasi virna ülespoole: paketid on kaitstud ja kohale toimetatud, seega on probleem selles, milliseid pakette protokoll saata valib.

Kontrollige marsruute, mitte ainult naabrite arvu

Kui naabersuhe on tekkinud, lugege, mida see reklaamib ja paigaldab. Mitmepunktilises tunnelis otsustavad split horizon ja next-hop-i käitumine, kas spoke jõuab teise spokeni jaoturi kaudu, ja summeerimine võib peita prefiksi isegi siis, kui naabersuhe on täiuslik.

Lõpetage kahe saidi vahel lubatud rakendusega ja kinnitage tee, mille see läbib. Otsesed spoke-to-spoke otseteed on edastusnõue oma NHRP ja turvaolekuga ning nende lisamine, et naabrite arv parem välja näeks, tekitab tavaliselt teise probleemi.

Kirjutage faasipõhine lahendus, multicast-vastendus ja EIGRP-poliitika ühte kohta. Järgmine insener vajab lahendust, mitte transkriptsiooni.

Seotud artiklid