DMVPN hierarkis: satu cloud per hubungan tunnel

Sebuah node cabang berhasil mendaftar ke hub regionalnya dan tetap tidak dapat menjangkau layanan di region lain. Tunnel aktif, status NHS terlihat sehat, dan kegagalan hanya muncul untuk tujuan yang melewati batas tingkat. Pola itu biasanya berarti desain tidak pernah menyatakan perangkat mana yang ikut serta di cloud DMVPN mana, sehingga tingkat-tingkat itu dibangun berdasarkan intuisi dan kini tidak lagi selaras.

Gejala muncul di batas tingkat

Dalam desain hierarkis, sebuah hub pusat, beberapa hub regional, dan banyak cabang masing-masing menempati posisi. Hub regional dapat memiliki lebih dari satu hubungan tunnel, dan cabang tidak perlu mendaftar ke setiap titik akhir pusat. Jalur yang penting adalah cabang ke layanan regional, cabang ke node regional lain yang disetujui, dan cabang ke tujuan pusat.

Ketika salah satu jalur itu gagal sementara yang lain berfungsi, masalahnya hampir selalu definisi peran yang hilang atau bertentangan, bukan tunnel yang rusak. Tuliskan jalur yang dimaksud dan bandingkan dengan apa yang sebenarnya dibangun perangkat. Perbandingan itu memakan waktu satu jam dan mencegah sepekan spekulasi. Simpan bersama dokumen desain.

Satu cloud, satu kontrak antarmuka

Untuk setiap cloud, catat antarmuka tunnel, pengalamatan overlay, sumber jaringan dasar lokal, hubungan NHS dan NBMA, pengiriman multicast, dan kebijakan perlindungan. Sebutkan juga rute mana yang melintas antara konteks regional dan pusat, karena kalimat itulah desainnya.

Hub regional dengan dua antarmuka tunnel memerlukan dua kontrak, bukan satu dengan dua alamat. Sumber jaringan dasar, domain NHRP, dan rutenya dapat berbeda per antarmuka, dan dokumen yang menggabungkannya akan menyesatkan siapa pun yang mengonfigurasi yang kedua.

ID adalah konteks lokal, bukan kontrol akses

ID jaringan NHRP dan kunci GRE adalah dua nilai yang paling sering disalahartikan sebagai pengaturan global. Panduan NHRP IOS XE menjelaskan ID jaringan sebagai bermakna lokal, sehingga nomor yang sama pada router jauh tidak mengautentikasi apa pun dan mengubah nomor lokal satu router tidak menciptakan batas akses.

Kunci GRE, jika desain memakainya, membantu mengenali konteks tunnel penerima, dan disepakati di antara titik akhir yang berbagi konteks itu. Itu bukan kata sandi dan tidak menggantikan autentikasi IKE atau kebijakan perutean. Perlakukan kedua nilai sebagai konteks konfigurasi yang harus cocok dalam suatu hubungan, bukan sebagai kontrol keamanan yang memisahkan region.

Rutekan antar tingkat secara sengaja

Putuskan prefiks mana yang diumumkan hub regional ke atas dan tujuan pusat mana yang ditawarkannya kepada cabangnya. Lalu periksa hop berikutnya yang sebenarnya dan perilaku pintasan spesifik fase untuk setiap jalur, karena rute ringkasan dan pintasan dapat menghasilkan penerusan yang sangat berbeda dari yang disiratkan diagram.

Gunakan perutean dan kebijakan akses untuk menegakkan pemisahan regional. Jika sebuah cabang tidak boleh menjangkau region lain secara langsung, rute dan kebijakan harus menyatakannya, bukan mengandalkan ID yang tidak pernah dirancang untuk menegakkannya. Tuliskan kebijakan itu di samping ID. Jika tidak, insinyur berikutnya akan menganggap nomor itulah yang bekerja.

Diagnosis pintasan yang tak terduga

Ketika cabang mencoba membuat hubungan langsung dengan titik akhir pusat, periksa rutenya, pemetaan NHRP-nya, dan konteks tunnel yang dipilih sebelum mengubah ID secara acak. Ketidaktersediaan, hubungan NHS yang tidak disengaja, dan pintasan yang sah tetapi tidak diizinkan menuntut tiga koreksi berbeda.

Panduan konfigurasi DMVPN menampilkan pengaturan tunnel dan NHRP bersama-sama, dan itulah sebabnya cakupan harus dipisahkan di atas kertas lebih dulu. Catat kontrak cloud, pertahankan rute tingkat tetap eksplisit, dan kegagalan batas berikutnya akan punya tempat untuk ditunjuk.