Jiran EIGRP tidak naik pada lapisan DMVPN

Terowong sudah naik, satu spoke boleh ping yang lain, tetapi EIGRP masih tidak menunjukkan sebarang jiran pada hub. Gabungan itu normal, bukan misteri: ping membuktikan ketersampaian unicast melalui NHRP, dan hello EIGRP ialah multicast. Pada lapisan DMVPN, model penghantaran protokol penghalaan ialah permukaan konfigurasi kedua, dan itulah yang orang langkau kerana permukaan pertama sudah kelihatan sihat. Setiap lapisan di bawah diperiksa dengan perintahnya sendiri, jadi kegagalan pada satu lapisan tidak menghantar anda kembali ke atas senarai.

Tuliskan kejiranan yang anda jangkakan

Sebelum sebarang perintah show, buat senarai pendek: spoke mana perlu ber-peer dengan hub mana, melalui antara muka terowong mana dan dalam sistem autonomi EIGRP mana. Reka bentuk berbilang hub gagal pada jurang antara hub, dan senarai menukar «EIGRP rosak» kepada «spoke 3 tidak mendaftar pada hub 2». Sertakan subnet terowong yang anda jangkakan pada setiap pautan, kerana ketakpadanan alamat antara kedua-dua hujung kelihatan tepat seperti kegagalan protokol. Tulis senarai itu pada tiket, supaya syif seterusnya membandingkan dengan reka bentuk dan bukan dengan tangkapan skrin terakhir.

Semak NHRP, kemudian laluan multicast

Mulakan dengan keadaan pendaftaran dan pemetaan yang benar-benar dipegang oleh hub. Spoke tanpa entri dinamik pada hub belum mendaftar, dan tiada protokol penghalaan akan membaikinya. Kemudian sahkan bahawa spoke menerima multicast daripada alamat NBMA hub, yang merupakan baris berasingan daripada entri 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

Baris ip nhrp map multicast itulah yang membolehkan spoke menghantar hello-nya kepada hub sebagai multicast yang direplikasi merentas lapisan, dan yang membolehkan multicast hub sampai kepada spoke yang telah didaftarkannya. Tanpanya unicast melalui NHRP berfungsi dan multicast tidak, dan pemisahan itulah yang membuatkan ping kelihatan seperti bukti. Panduan Cisco IOS XE DMVPN mendokumenkan tingkah laku multicast hub dan spoke bagi setiap fasa, jadi selaraskan konfigurasi anda dengan fasa yang benar-benar anda laksanakan dan bukannya menyalin serpihan daripada topologi lain.

Semak dasar antara muka EIGRP itu sendiri

Terowong yang tiada dalam proses EIGRP, atau yang passive, tidak akan membentuk kejiranan, sesihat mana pun lapisan itu. Baca penyertaan antara muka dan jadual jiran bersama-sama, kerana yang pertama menerangkan yang kedua.

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

Pengesahan dan pemberat metrik mesti sepadan pada kedua-dua hujung. Rantaian kunci dengan mod yang salah, atau ketakpadanan nilai K, menjatuhkan hello tanpa baris syslog yang jelas pada penerima. Jika reka bentuk menggunakan jiran unicast yang dikonfigurasi secara eksplisit, ikut model itu sepenuhnya dan bukannya melapiskannya di atas tetapan multicast sehingga sesuatu naik.

Asingkan pengangkutan GRE dan perlindungan IPsec

DMVPN mengangkut multicast di dalam GRE, dan IPsec melindungi paket GRE dan bukan multicast dalaman secara langsung. Itulah sebabnya dakwaan menyeluruh bahawa IPsec tidak boleh mengangkut multicast salah bagi reka bentuk ini dan tidak berguna sebagai diagnosis. Semak profil IPsec pada terowong, persatuan keselamatan bagi setiap peer dan keadaan antara muka terowong sebagai tiga fakta berasingan.

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

SA yang naik dengan pembilang bergerak sementara EIGRP kekal turun mengembalikan siasatan anda ke atas tindanan: paket dilindungi dan dihantar, jadi masalahnya ialah paket mana yang dipilih protokol untuk dihantar.

Sahkan laluan, bukan hanya bilangan jiran

Setelah kejiranan terbentuk, baca apa yang diiklankan dan dipasangnya. Pada terowong berbilang titik, split horizon dan tingkah laku next-hop menentukan sama ada satu spoke boleh mencapai spoke lain melalui hub, dan peringkasan boleh menyembunyikan awalan walaupun hubungan jiran sempurna.

Akhiri dengan aplikasi yang dibenarkan antara dua tapak dan sahkan laluan yang diambilnya. Jalan pintas terus spoke-ke-spoke ialah keperluan penghantaran dengan status NHRP dan keselamatannya sendiri, dan menambahnya supaya bilangan jiran kelihatan lebih baik biasanya mencipta masalah kedua.

Rekod reka bentuk berperingkat, pemetaan multicast dan dasar EIGRP di satu tempat. Jurutera seterusnya akan memerlukan reka bentuk itu, bukan transkripnya.