Jiran EIGRP atau Transit DMVPN? Semak Peranan Dahulu

Kejiranan tiada, dan penghala di tengah kelihatan sebagai suspek yang jelas. Ia mungkin tidak bersalah. Menyerahkan paket terowong luar dan menyertai protokol penghalaan overlay ialah dua kerja berbeza, dan peranti boleh melakukan yang pertama tanpa yang kedua. Lakukan lima semakan di bawah mengikut urutan dan berhenti pada yang pertama gagal.

Langkah 1: lukis kedua-dua peranan

Lukis kejiranan EIGRP yang dimaksudkan sebagai sambungan logik antara dua penghala, kemudian lukis penghala underlay yang membawa paket terowongnya. Peranti yang sama tidak perlu muncul dalam kedua-dua senarai, dan mengelirukan senarai itu ialah sebab paling biasa penghala transit yang sihat dituduh memecahkan kejiranan.

Penghala transit menyerahkan paket luar menggunakan penghalaan IP dan dasarnya yang biasa. Ia tidak perlu menjalankan protokol yang dibawa di dalam terowong terlindung, dan tidak memerlukan proses EIGRP untuk menyerahkan paket itu.

Langkah 2: semak apa yang ditamatkan oleh peranti tengah

Jika penghala tengah menamatkan terowong dan sepatutnya membentuk kejiranan EIGRP dengan spoke, jawapannya berubah sepenuhnya. Peranti itu memerlukan tingkah laku penghalaan overlay yang disokong, dan menyebutnya transit tidak menghapuskan keperluan jiran. Baca konfigurasi terowong sebelum konfigurasi penghalaan. Jawapan itu menentukan setiap semakan berikutnya.

Jadi soalan sebenar pertama bukanlah protokol mana yang perlu ditala. Soalannya ialah sama ada kotak itu hub, spoke, lompatan underlay tulen atau perkhidmatan Layer 2 yang membawa bingkai antara hujung.

Langkah 3: sahkan satah kawalan jiran

Pada setiap peranti yang sepatutnya menjadi jiran, sahkan empat perkara: instans EIGRP dan nombor sistem autonomi, parameter pengesahan, antara muka yang menyertai proses, dan pernyataan rangkaian yang meliputi antara muka itu. Ketidakpadanan pada mana-mana daripadanya mengekalkan kejiranan turun manakala antara muka kekal naik dan ping terus berfungsi.

RFC 7868 menerangkan EIGRP sebagai protokol IP dengan pertukaran kawalan multicast, sebab itulah hubungan kejiranan bukan sesuatu yang penghala perantaraan boleh gantikan dengan menghalakan paket ke destinasi. Sama ada pertukaran kawalan sampai kepada rakan atau kejiranan tidak terbentuk.

Langkah 4: sahkan bahawa pengangkutan menyampaikan pertukaran kawalan

Seterusnya, semak sama ada overlay benar-benar membawa trafik kawalan antara hujung yang dimaksudkan. Periksa pemetaan NHRP untuk rakan dan laluan luar yang mencapainya, kemudian sahkan antara muka terowong naik dan melalukan trafik. Ping underlay yang berjaya membuktikan laluan luar wujud; ia tidak membuktikan pertukaran kawalan overlay telah disampaikan.

Perkhidmatan Layer 2 telus, terowong titik-ke-titik dan awan DMVPN berbilang titik menyampaikan multicast secara berbeza. Ikut model antara muka, NHRP dan multicast yang disokong untuk yang benar-benar dilaksanakan dan bukannya menganggap ketiga-tiganya berkelakuan sama.

Langkah 5: reka bentuk semula sempadan jika ia tidak boleh menyertai

Jika peranti overlay yang diperlukan tidak boleh menjalankan protokol itu, ubah reka bentuk secara eksplisit. Gunakan protokol atau model pertukaran yang disokong pada sempadan itu, atau sediakan terowong hujung-ke-hujung yang sesuai supaya jiran ialah hujung yang benar-benar bercakap sesama sendiri. Jangan anggap laluan statik menukar bukan-peserta menjadi pengulang untuk setiap paket kawalan.

Catat peranan setiap peranti dalam rajah dan simpan bersama konfigurasi. RFC 7868 mentakrifkan pertukaran protokol, dan takrifan itu ialah rujukan mengapa hubungan kejiranan tidak boleh disimulasikan dengan penghantaran transit.

Apabila kejiranan masih gagal selepas kelima-lima semakan, suspek yang tinggal ialah ciri platform seperti pengendalian multicast pada antara muka terowong dan dasar yang menapis protokol 88. Itu sebab yang khusus dan boleh diuji, dan ia lebih bernilai daripada satu lagi pusingan menyalahkan penghala di tengah.