Hindi umaangat ang mga kapitbahay ng EIGRP sa overlay ng DMVPN

Gumagana ang unicast sa overlay at nabigo pa rin ang pagkakapitbahay, kaya suriin ang multicast replication ng NHRP, patakaran ng EIGRP sa tunnel at IPsec bilang tatlong hiwalay na layer.

Nakaangat ang tunnel, kayang pingin ng isang spoke ang isa pa, at wala pa ring ipinapakitang kapitbahay ang EIGRP sa hub. Normal ang kombinasyong ito, hindi mahiwaga: pinatutunayan ng ping ang unicast reachability sa pamamagitan ng NHRP, at ang hello ng EIGRP ay multicast. Sa overlay ng DMVPN, ang delivery model ng routing protocol ay pangalawang configuration surface, at iyon ang nilalaktawan ng mga tao dahil mukha nang malusog ang unang surface. Bawat layer sa ibaba ay sinusuri ng sariling command, kaya ang pagkabigo sa isang layer ay hindi ka ibinabalik sa tuktok ng listahan.

Isulat ang mga pagkakapitbahay na inaasahan mo

Bago ang anumang show command, gumawa ng maikling listahan: aling spoke ang dapat mag-peer sa aling hub, sa aling tunnel interface, at sa aling autonomous system ng EIGRP. Nabibigo ang mga disenyong may maraming hub sa mga puwang sa pagitan ng mga hub, at binabago ng listahan ang «sira ang EIGRP» tungo sa «hindi nagrerehistro ang spoke 3 sa hub 2». Isama ang mga tunnel subnet na inaasahan mo sa bawat link, dahil ang hindi pagtutugma ng address sa dalawang dulo ay mukhang eksaktong pagkabigo ng protocol. Isulat ang listahan sa ticket, upang ang susunod na shift ay maghambing sa disenyo at hindi sa huling screenshot.

Suriin ang NHRP, pagkatapos ang landas ng multicast

Magsimula sa estado ng rehistro at sa mga mapping na talagang hawak ng hub. Ang spoke na walang dynamic na entry sa hub ay hindi nakarehistro, at walang routing protocol ang makakapag-ayos niyon. Pagkatapos, kumpirmahin na tumatanggap ang spoke ng multicast mula sa NBMA address ng hub, na isang hiwalay na linya mula sa entry ng 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

Ang linyang ip nhrp map multicast ang nagpapahintulot sa spoke na ipadala ang hello nito sa hub bilang replicated multicast sa overlay, at nagpapahintulot sa multicast ng hub na maabot ang mga nakarehistrong spoke. Kung wala ito, gumagana ang unicast sa NHRP at hindi ang multicast, at iyon ang eksaktong paghahati na nagpapamukhang patunay ang ping. Ang gabay ng Cisco IOS XE DMVPN ay nagdodokumento ng pag-uugali ng multicast ng hub at mga spoke para sa bawat yugto, kaya itugma ang iyong configuration sa yugtong aktwal mong inilunsad sa halip na kopyahin ang isang bahagi mula sa ibang topology.

Suriin ang sariling patakaran ng interface ng EIGRP

Ang tunnel na wala sa proseso ng EIGRP, o passive, ay hindi kailanman bubuo ng pagkakapitbahay, gaano man kalusog ang overlay. Basahin nang sabay ang partisipasyon ng interface at ang talahanayan ng kapitbahay, dahil ipinapaliwanag ng una ang pangalawa.

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

Dapat magtugma ang authentication at timbang ng metric sa dalawang dulo. Ang key chain na mali ang mode, o hindi pagtutugma ng halaga ng K, ay nagtatapon ng hello nang walang malinaw na linya ng syslog sa receiver. Kung gumagamit ang disenyo ng tahasang naka-configure na unicast na kapitbahay, sundin nang buo ang modelong iyon sa halip na ipatong ito sa mga setting ng multicast hanggang may umangat.

Ihiwalay ang pagdadala ng GRE at proteksyon ng IPsec

Dinadala ng DMVPN ang multicast sa loob ng GRE, at pinoprotektahan ng IPsec ang mga packet ng GRE at hindi ang panloob na multicast nang direkta. Iyon ang dahilan kung bakit mali ang pangkalahatang pahayag na hindi kayang magdala ng multicast ang IPsec para sa disenyong ito at walang silbi bilang diagnosis. Suriin ang profile ng IPsec sa tunnel, ang mga seguridad na asosasyon ng bawat peer at ang estado ng tunnel interface bilang tatlong hiwalay na katotohanan.

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

Ang SA na nakaangat at gumagalaw ang mga counter habang nananatiling bumaba ang EIGRP ay nagbabalik ng imbestigasyon pataas sa stack: pinoprotektahan at inihahatid ang mga packet, kaya ang problema ay kung aling mga packet ang pinipiling ipadala ng protocol.

I-verify ang mga ruta, hindi lang bilang ng kapitbahay

Kapag nabuo ang pagkakapitbahay, basahin kung ano ang inaanunsyo at inilalagay nito. Sa multipoint tunnel, ang split horizon at pag-uugali ng next-hop ang nagpapasya kung maaabot ng isang spoke ang isa pa sa pamamagitan ng hub, at kayang itago ng summarization ang isang prefix kahit perpekto ang ugnayan ng kapitbahay.

Tapusin sa isang pinapayagang application sa pagitan ng dalawang site at kumpirmahin ang landas na tinatahak nito. Ang direktang spoke-to-spoke shortcut ay pangangailangan sa forwarding na may sariling estado ng NHRP at seguridad, at ang pagdaragdag ng mga ito upang gumanda ang bilang ng kapitbahay ay karaniwang lumilikha ng pangalawang problema.

Itala ang disenyong may yugto, ang mapping ng multicast at ang patakaran ng EIGRP sa isang lugar. Kakailanganin ng susunod na inhinyero ang disenyo, hindi ang transkripsyon.

Kaugnay na mga artikulo