Tetangga EIGRP tidak muncul di overlay DMVPN
Unicast lewat overlay berfungsi dan ketetanggaan tetap gagal, jadi periksa replikasi multicast NHRP, kebijakan EIGRP terowongan, dan IPsec sebagai tiga lapisan terpisah.
Terowongan sudah naik, satu spoke dapat mem-ping spoke lain, dan EIGRP tetap tidak menampilkan tetangga di hub. Kombinasi itu normal, bukan misterius: ping membuktikan keterjangkauan unicast lewat NHRP, dan hello EIGRP bersifat multicast. Pada overlay DMVPN, model pengiriman protokol routing adalah permukaan konfigurasi kedua, dan itulah yang dilewati orang karena permukaan pertama sudah tampak sehat. Setiap lapisan di bawah diperiksa dengan perintahnya sendiri, sehingga kegagalan di satu lapisan tidak mengirim Anda kembali ke puncak daftar.
Tuliskan ketetanggaan yang Anda harapkan
Sebelum perintah show apa pun, buat daftar singkat: spoke mana harus ber-peer dengan hub mana, lewat antarmuka terowongan mana, dan di sistem otonom EIGRP mana. Desain multi-hub gagal di celah antarhub, dan daftar mengubah «EIGRP rusak» menjadi «spoke 3 tidak mendaftar ke hub 2». Sertakan subnet terowongan yang Anda harapkan di setiap tautan, karena ketidakcocokan alamat antara kedua ujung tampak persis seperti kegagalan protokol. Tulis daftar itu di tiket, agar giliran berikutnya membandingkan dengan desain, bukan dengan tangkapan layar terakhir.
Periksa NHRP, lalu jalur multicast
Mulailah dari status pendaftaran dan pemetaan yang benar-benar dipegang hub. Spoke tanpa entri dinamis di hub belum mendaftar, dan tidak ada protokol routing yang akan memperbaikinya. Lalu pastikan spoke menerima multicast dari alamat NBMA hub, yang merupakan baris terpisah dari 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 memungkinkan spoke mengirim hello-nya ke hub sebagai multicast yang direplikasi lewat overlay, dan yang memungkinkan multicast hub mencapai spoke yang telah didaftarkannya. Tanpanya unicast lewat NHRP berfungsi dan multicast tidak, dan pemisahan itulah yang membuat ping tampak seperti bukti. Panduan Cisco IOS XE DMVPN mendokumentasikan perilaku multicast hub dan spoke untuk setiap fase, jadi sesuaikan konfigurasi Anda dengan fase yang benar-benar Anda terapkan, bukan menyalin potongan dari topologi lain.
Periksa kebijakan antarmuka EIGRP sendiri
Terowongan yang tidak ada di proses EIGRP, atau bersifat passive, tidak akan pernah membentuk ketetanggaan, seberapa sehat pun overlay-nya. Baca keikutsertaan antarmuka dan tabel tetangga bersama-sama, karena yang pertama menjelaskan 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
Autentikasi dan bobot metrik harus cocok di kedua ujung. Rantai kunci dengan mode yang salah, atau ketidakcocokan nilai K, menjatuhkan hello tanpa baris syslog yang jelas di penerima. Jika desain memakai tetangga unicast yang dikonfigurasi eksplisit, ikuti model itu sepenuhnya alih-alih menumpuknya di atas pengaturan multicast sampai ada yang naik.
Pisahkan pengangkutan GRE dan perlindungan IPsec
DMVPN mengangkut multicast di dalam GRE, dan IPsec melindungi paket GRE, bukan multicast dalam secara langsung. Karena itulah klaim umum bahwa IPsec tidak dapat mengangkut multicast salah untuk desain ini dan tidak berguna sebagai diagnosis. Periksa profil IPsec pada terowongan, asosiasi keamanan tiap peer, dan status antarmuka terowongan sebagai tiga fakta terpisah.
show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast
SA yang naik dengan penghitung bergerak sementara EIGRP tetap turun mengembalikan penyelidikan Anda ke atas tumpukan: paket dilindungi dan dikirim, jadi masalahnya adalah paket mana yang dipilih protokol untuk dikirim.
Verifikasi rute, bukan hanya jumlah tetangga
Setelah ketetanggaan terbentuk, baca apa yang diiklankan dan dipasangnya. Pada terowongan multipoint, split horizon dan perilaku next-hop menentukan apakah satu spoke dapat mencapai spoke lain lewat hub, dan peringkasan dapat menyembunyikan prefiks meskipun hubungan tetangga sempurna.
Akhiri dengan aplikasi yang diizinkan antara dua situs dan pastikan jalur yang ditempuhnya. Jalan pintas langsung spoke-ke-spoke adalah persyaratan penerusan dengan status NHRP dan keamanannya sendiri, dan menambahkannya agar jumlah tetangga terlihat lebih baik biasanya menciptakan masalah kedua.
Catat desain bertahap, pemetaan multicast, dan kebijakan EIGRP di satu tempat. Insinyur berikutnya akan membutuhkan desainnya, bukan transkripnya.