Tetangga EIGRP atau Transit DMVPN? Periksa Perannya Dulu

Ketetanggaan hilang, dan router di tengah tampak sebagai tersangka yang jelas. Ia bisa saja tidak bersalah. Meneruskan paket terowongan luar dan ikut serta dalam protokol perutean overlay adalah dua pekerjaan berbeda, dan perangkat dapat melakukan yang pertama tanpa yang kedua. Kerjakan lima pemeriksaan di bawah ini berurutan dan berhenti pada pemeriksaan pertama yang gagal.

Langkah 1: gambar kedua peran

Gambarkan ketetanggaan EIGRP yang dimaksud sebagai koneksi logis antara dua router, lalu gambarkan router underlay yang membawa paket terowongannya. Perangkat yang sama tidak harus muncul di kedua daftar, dan mencampuradukkan daftar adalah alasan paling umum sebuah router transit yang sehat dituduh merusak ketetanggaan.

Router transit meneruskan paket luar menggunakan perutean IP dan kebijakan biasanya. Ia tidak perlu menjalankan protokol yang dibawa di dalam terowongan terlindung, dan tidak perlu proses EIGRP untuk meneruskan paket itu.

Langkah 2: periksa apa yang diakhiri perangkat tengah

Jika router tengah mengakhiri terowongan dan seharusnya membentuk ketetanggaan EIGRP dengan spoke, jawabannya berubah total. Perangkat itu membutuhkan perilaku perutean overlay yang didukung, dan menyebutnya transit tidak menghapus syarat tetangga. Baca konfigurasi terowongan sebelum konfigurasi perutean. Jawaban itu menentukan setiap pemeriksaan berikutnya.

Jadi pertanyaan nyata pertama bukanlah protokol mana yang harus disetel. Pertanyaannya adalah apakah kotak itu hub, spoke, lompatan underlay murni, atau layanan Layer 2 yang membawa frame antartitik akhir.

Langkah 3: verifikasi bidang kendali tetangga

Pada setiap perangkat yang seharusnya menjadi tetangga, pastikan empat hal: instans EIGRP dan nomor sistem otonom, parameter autentikasi, antarmuka yang ikut dalam proses, dan pernyataan jaringan yang mencakup antarmuka tersebut. Ketidakcocokan pada salah satunya membuat ketetanggaan tetap mati sementara antarmuka tetap hidup dan ping terus berjalan.

RFC 7868 menggambarkan EIGRP sebagai protokol IP dengan pertukaran kendali multicast, karena itu hubungan ketetanggaan bukanlah sesuatu yang dapat diwakili router perantara dengan merutekan paket ke tujuan. Entah pertukaran kendali sampai ke peer atau ketetanggaan tidak terbentuk.

Langkah 4: verifikasi bahwa transportasi mengantarkan pertukaran kendali

Selanjutnya, periksa bahwa overlay benar-benar membawa lalu lintas kendali di antara titik akhir yang dimaksud. Periksa pemetaan NHRP untuk peer dan rute luar yang mencapainya, lalu pastikan antarmuka terowongan hidup dan meneruskan lalu lintas. Ping underlay yang berhasil membuktikan jalur luar ada; itu tidak membuktikan pertukaran kendali overlay telah diantarkan.

Layanan Layer 2 transparan, terowongan titik-ke-titik, dan awan DMVPN multipoint mengantarkan multicast dengan cara berbeda. Ikuti model antarmuka, NHRP, dan multicast yang didukung untuk yang benar-benar diterapkan daripada menganggap ketiganya berperilaku sama.

Langkah 5: rancang ulang batas jika tidak dapat berpartisipasi

Jika perangkat overlay yang diperlukan tidak dapat menjalankan protokol itu, ubah desain secara eksplisit. Gunakan protokol atau model pertukaran yang didukung pada batas tersebut, atau siapkan terowongan ujung-ke-ujung yang sesuai agar tetangga adalah titik akhir yang benar-benar saling berbicara. Jangan menganggap rute statis mengubah bukan-peserta menjadi relai bagi setiap paket kendali.

Catat peran setiap perangkat pada diagram dan simpan bersama konfigurasi. RFC 7868 mendefinisikan pertukaran protokol, dan definisi itu adalah rujukan mengapa hubungan ketetanggaan tidak dapat disimulasikan dengan penerusan transit.

Ketika ketetanggaan masih gagal setelah kelima pemeriksaan, tersangka yang tersisa adalah fitur platform seperti penanganan multicast pada antarmuka terowongan dan kebijakan yang menyaring protokol 88. Itu penyebab yang spesifik dan dapat diuji, dan nilainya lebih tinggi daripada satu putaran lagi menyalahkan router di tengah.