EIGRP-najbaroj ne ekleviĝas sur la DMVPN-tavolo

Unicast tra la tavolo funkcias kaj la najbareco ankoraŭ fiaskas, do kontrolu la multicast-ripeton de NHRP, la EIGRP-politikon de la tunelo kaj IPsec kiel tri apartajn tavolojn.

La tunelo estas supren, unu spoke povas pingi alian, kaj EIGRP ankoraŭ montras neniun najbaron ĉe la hub. Tiu kombinaĵo estas normala, ne mistera: ping pruvas unicast-atingeblecon tra NHRP, kaj EIGRP-helloj estas multicast. Sur DMVPN-tavolo la livera modelo de la enkursiga protokolo estas dua agorda surfaco, kaj ĝuste tion homoj preterlasas ĉar la unua surfaco jam aspektas sana. Ĉiu tavolo sube estas kontrolata per sia propra komando, do fiasko en unu ne resendas vin al la supro de la listo.

Skribu la najbarecojn, kiujn vi atendas

Antaŭ iu ajn komando show, faru mallongan liston: kiu spoke devas pariĝi kun kiu hub, per kiu tunela interfaco, en kiu aŭtonoma sistemo EIGRP. Dezajnoj kun pluraj huboj fiaskas en la breĉoj inter la huboj, kaj listo ŝanĝas «EIGRP estas rompita» en «spoke 3 ne registriĝas ĉe hub 2». Inkluzivu la tunelajn subretojn, kiujn vi atendas sur ĉiu ligo, ĉar malkongruo de adresoj inter la du finoj aspektas precize kiel protokola fiasko. Skribu la liston en la bileton, por ke la sekva deĵoro komparu kun la dezajno anstataŭ kun la lasta ekrankopio.

Kontrolu NHRP, poste la multicast-vojon

Komencu per la registra stato kaj la mapadoj, kiujn la hub efektive tenas. Spoke sen dinamika enskribo ĉe la hub ne registriĝis, kaj neniu enkursiga protokolo tion riparos. Poste konfirmu, ke la spoke akceptas multicast de la NBMA-adreso de la hub, kio estas aparta linio disde la NHS-enskribo.

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

La linio ip nhrp map multicast estas tio, kio ebligas al la spoke sendi siajn hellojn al la hub kiel ripetita multicast tra la tavolo, kaj kio ebligas al la multicast de la hub atingi la registritajn spokeojn. Sen ĝi unicast tra NHRP funkcias kaj multicast ne, kaj ĝuste tiu disigo igas ping aspekti kiel pruvo. La gvidilo de Cisco IOS XE DMVPN dokumentas la multicast-konduton de hub kaj spokeoj por ĉiu fazo, do agordu vian konfiguraĵon al la fazo, kiun vi efektive deplojis, anstataŭ kopii fragmenton el alia topologio.

Kontrolu la propran interfacan politikon de EIGRP

Tunelo, kiu ne estas en la EIGRP-procezo aŭ estas passive, neniam formos najbarecon, kiel ajn sana la tavolo estas. Legu la partoprenon de la interfaco kaj la najbaran tabelon kune, ĉar la unua klarigas la duan.

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ŭtentigo kaj metrikaj pezoj devas kongrui ĉe ambaŭ finoj. Ŝlosila ĉeno kun malĝusta reĝimo, aŭ malkongruo de la valoro K, faligas hellojn sen evidenta syslog-linio ĉe la ricevanto. Se la dezajno uzas eksplicite agorditajn unicast-najbarojn, sekvu tiun modelon plene anstataŭ tavoligi ĝin sur la multicast-agordojn ĝis io ekleviĝos.

Tenu la GRE-transporton kaj la IPsec-protekton aparte

DMVPN transportas multicast ene de GRE, kaj IPsec protektas la GRE-paketojn, ne la internan multicast rekte. Tial la ĝenerala aserto, ke IPsec ne povas transporti multicast, estas malĝusta por ĉi tiu dezajno kaj senutila kiel diagnozo. Kontrolu la IPsec-profilon sur la tunelo, la sekurecajn asociojn por ĉiu peer kaj la staton de la tunela interfaco kiel tri apartajn faktojn.

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

SA, kiu estas supren kaj kies nombriloj moviĝas dum EIGRP restas malsupren, resendas vian esploron supren laŭ la stako: la paketoj estas protektataj kaj liverataj, do la problemo estas, kiujn paketojn la protokolo elektas sendi.

Kontrolu la vojojn, ne nur la nombron de najbaroj

Post kiam la najbareco formiĝas, legu, kion ĝi anoncas kaj instalas. Sur plurpunkta tunelo, split horizon kaj la konduto de next-hop decidas, ĉu spoke povas atingi alian spoke tra la hub, kaj sumarigo povas kaŝi prefikson eĉ kiam la najbara rilato estas perfekta.

Finu per permesita aplikaĵo inter du retejoj kaj konfirmu la vojon, kiun ĝi prenas. Rektaj spoke-al-spoke ŝparvojoj estas plusenda postulo kun propra NHRP kaj sekureca stato, kaj aldoni ilin por igi la nombron de najbaroj pli bona kutime kreas duan problemon.

Registru la fazan dezajnon, la multicast-mapadon kaj la EIGRP-politikon en unu loko. La sekva inĝeniero bezonos la dezajnon, ne la transskribon.

Rilataj artikoloj