Fqinjët EIGRP nuk ngjiten në shtresën DMVPN

Unicast përmes shtresës funksionon dhe fqinjësia prapë dështon, prandaj kontrolloni replikimin multicast të NHRP, politikën EIGRP të tunelit dhe IPsec si tre shtresa të ndara.

Tuneli është lart, një spoke mund të pingojë një tjetër, dhe EIGRP prapë nuk shfaq asnjë fqinj në hub. Ky kombinim është normal, jo misterioz: ping-u vërteton arritshmërinë unicast përmes NHRP, dhe hello-t e EIGRP janë multicast. Në një shtresë DMVPN modeli i dorëzimit të protokollit të rrugëtimit është një sipërfaqe e dytë konfigurimi, dhe pikërisht atë njerëzit e anashkalojnë sepse sipërfaqja e parë duket tashmë e shëndetshme. Çdo shtresë më poshtë kontrollohet me komandën e vet, prandaj një dështim në një shtresë nuk ju kthen në krye të listës.

Shkruani fqinjësitë që prisni

Përpara çdo komande show, bëni një listë të shkurtër: cili spoke duhet të bëjë peer me cilin hub, përmes cilit ndërfaqe tuneli dhe në cilin sistem autonom EIGRP. Dizajnet me shumë hub dështojnë në boshllëqet mes hub-eve, dhe një listë e kthen «EIGRP është prishur» në «spoke 3 nuk regjistrohet në hub 2». Përfshini nënrrjetet e tunelit që prisni në çdo lidhje, sepse mospërputhja e adresave mes dy skajeve duket saktësisht si dështim protokolli. Shkruani listën në tiketë, që turni tjetër të krahasojë me dizajnin dhe jo me pamjen e fundit të ekranit.

Kontrolloni NHRP, pastaj rrugën multicast

Filloni me gjendjen e regjistrimit dhe me hartëzimet që hub-i mban vërtet. Një spoke pa zë dinamik në hub nuk është regjistruar, dhe asnjë protokoll rrugëtimi nuk e rregullon këtë. Pastaj konfirmoni që spoke pranon multicast nga adresa NBMA e hub-it, që është një rresht i veçantë nga zëri 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

Pikërisht ip nhrp map multicast rreshti i lejon spoke-t të dërgojë hello-t e vet te hub-i si multicast i replikuar përmes shtresës, dhe i lejon multicast-it të hub-it të arrijë spoke-t e regjistruar. Pa atë, unicast përmes NHRP funksionon dhe multicast nuk funksionon, dhe pikërisht kjo ndarje e bën ping-un të duket si provë. Udhëzuesi i Cisco IOS XE DMVPN dokumenton sjelljen multicast të hub-it dhe spoke-ve për çdo fazë, prandaj përshtatni konfigurimin tuaj me fazën që keni vënë vërtet në punë, në vend që të kopjoni një fragment nga një topologji tjetër.

Kontrolloni politikën e ndërfaqes së vetë EIGRP

Një tunel që nuk është në procesin EIGRP, ose që është passive, nuk do të formojë kurrë fqinjësi, sado i shëndetshëm të jetë shtresa. Lexoni pjesëmarrjen e ndërfaqes dhe tabelën e fqinjëve bashkë, sepse e para shpjegon të dytën.

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

Vërtetimi dhe peshat e metrikës duhet të përputhen në të dy skajet. Një zinxhir çelësash me modalitet të gabuar, ose një mospërputhje e vlerës K, i hedh poshtë hello-t pa një rresht syslog të dukshëm te marrësi. Nëse dizajni përdor fqinjë unicast të konfiguruar shprehimisht, ndiqni atë model plotësisht në vend që ta vendosni sipër cilësimeve multicast derisa të ngjitet diçka.

Mbani transportin GRE dhe mbrojtjen IPsec të ndara

DMVPN transporton multicast brenda GRE, dhe IPsec mbron paketat GRE dhe jo multicast-in e brendshëm drejtpërdrejt. Prandaj pohimi i përgjithshëm se IPsec nuk mund të transportojë multicast është i gabuar për këtë dizajn dhe i padobishëm si diagnozë. Kontrolloni profilin IPsec në tunel, shoqatat e sigurisë për çdo peer dhe gjendjen e ndërfaqes së tunelit si tre fakte të ndara.

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

Një SA që është lart dhe numëruesit e të cilit lëvizin ndërsa EIGRP mbetet poshtë e kthen hetimin tuaj përsëri lart në stack: paketat mbrohen dhe dorëzohen, prandaj problemi është cilat paketa protokolli zgjedh të dërgojë.

Verifikoni rrugët, jo vetëm numrin e fqinjëve

Sapo të formohet fqinjësia, lexoni çfarë reklamon dhe instalon. Në një tunel shumëpikësh, split horizon dhe sjellja e next-hop përcaktojnë nëse një spoke mund të arrijë një tjetër përmes hub-it, dhe përmbledhja mund të fshehë një prefix edhe kur marrëdhënia e fqinjësisë është e përsosur.

Përfundoni me një aplikacion të lejuar mes dy site-ve dhe konfirmoni rrugën që ndjek. Shkurtoret e drejtpërdrejta spoke-to-spoke janë një kërkesë përcjelljeje me gjendjen e tyre NHRP dhe të sigurisë, dhe shtimi i tyre që numri i fqinjëve të duket më mirë zakonisht krijon një problem të dytë.

Regjistroni dizajnin në faza, hartëzimin multicast dhe politikën EIGRP në një vend. Inxhinieri tjetër do të ketë nevojë për dizajnin, jo për transkriptin.

Artikuj të ngjashëm