Failover WAN DMVPN: Kebijakan Rute atau Matikan Tunnel?

Hub DMVPN dengan dua WAN melakukan failover dengan salah satu dari dua cara, dan perbedaannya lebih besar dari yang terlihat. Yang satu mengubah hop berikutnya yang dipilih kebijakan rute, sehingga paket tetap mengalir dan hanya jalur keluarnya yang berubah. Yang lain mematikan tunnel secara administratif, yang ikut menurunkan setiap layanan pada antarmuka itu. Keduanya bisa benar, karena menjawab pertanyaan yang berbeda.

Keputusan datang sebelum konfigurasi

Tiga kondisi menentukan ini untuk Anda. Apakah ada hal lain yang bergantung pada antarmuka tunnel tetap aktif, seperti profil DMVPN kedua atau monitor yang membaca statusnya? Apakah lalu lintas yang harus failover membawa kebijakannya sendiri, atau bergantung pada tabel routing global? Dan apakah operator memerlukan perubahan status yang tidak ambigu, atau peralihan jalur yang tenang sudah dapat diterima? Jawab ketiganya dan pilihan biasanya menentukan dirinya sendiri.

Jika mematikan akan menurunkan layanan yang tadinya berfungsi, kebijakan rute adalah tindakan yang lebih kecil. Jika persyaratannya adalah tunnel tidak boleh ada selama WAN utama mati, tidak ada entri kebijakan yang dapat menyatakan itu.

Tuliskan jawabannya, karena konfigurasi adalah bagian yang mudah.

Apa yang sebenarnya diubah kebijakan rute

Dengan perutean berbasis kebijakan, objek yang dilacak dapat menggerbangi hop berikutnya. Entri peta rute menyebutkan hop berikutnya kandidat dan objek yang dilacak yang harus aktif agar dapat digunakan, dan status pelacakan itu berasal dari probe IP SLA. Ketika objek turun, entri berhenti cocok dan paket dievaluasi oleh entri berikutnya atau oleh tabel routing biasa.

Detail terakhir itu mengejutkan orang: kebijakan yang berhenti memilih hop berikutnya biasanya mengizinkan perutean normal alih-alih memblokir lalu lintas. Jika Anda memerlukan lubang hitam saat gagal, Anda harus menulisnya sendiri.

Sintaksnya berbeda antarplatform dan rilis, jadi periksa panduan untuk versi yang benar-benar Anda jalankan.

Apa yang diubah dengan mematikan tunnel

Mematikan antarmuka mengubah status administratif. Setiap tunnel, rute, dan sesi yang bergantung padanya turun sekaligus, yang persis Anda inginkan jika tunnel adalah hal yang harus hilang. Begitulah juga applet EEM mengubah masalah WAN menjadi gangguan yang mencakup layanan tak terkait.

Jika Anda memilih jalan ini, batasi applet ke satu antarmuka dan satu pemicu, simpan status administratif sebelumnya, tetapkan tindakan pemulihan, dan pastikan flap berulang tidak dapat mendorongnya ke dalam loop.

Perintah pemulihan yang dikodekan keras juga dapat menimpa penutupan pemeliharaan yang dilakukan orang lain.

Buat probe menempuh jalur yang Anda pikirkan

Probe yang mengikuti rute terbaik saat ini berpindah ke WAN cadangan bersama semua yang lain, lalu melaporkan yang utama sehat karena tidak lagi menggunakannya.

Sematkan probe ke antarmuka atau alamat sumber jalur yang Anda uji. Periksa juga apa yang dibidiknya, karena mencapai hop berikutnya penyedia membuktikan lebih sedikit daripada mencapai layanan yang menjadi alasan tunnel itu ada. Atur penundaan naik dan turun dengan sengaja: penundaan turun yang singkat bereaksi cepat dan berflap, sedangkan yang panjang menahan kedipan dan menyembunyikan kegagalan nyata. Panduan Cisco tentang pelacakan dan perutean berbasis kebijakan di IOS XE mendokumentasikan kombinasi yang didukung, dan kumpulan fitur di platform Anda menentukan mana yang dapat Anda gunakan.

Catat kedua nilai penundaan di samping objek yang dilacak, atau tidak ada yang tahu mengapa perilakunya begitu.

Putuskan pemulihan, lalu verifikasi

Pemulihan layak mendapat keputusannya sendiri. Tautan yang terus melewati ambang dapat memindahkan sesi lebih sering daripada yang jelas gagal, dan setiap perpindahan memakan negosiasi ulang kunci dan percobaan ulang aplikasi. Pilih persyaratan stabilitas dan biarkan penundaan menyatakannya. Lalu verifikasi selama jendela perubahan dengan jalur probe terlihat: rute terpilih, jalur peer luar, dan apa yang benar-benar dilakukan aplikasi.

Jika failover bekerja tetapi aplikasi masih rusak, masalahnya ada di atas lapisan perutean dan tidak ada pelacakan yang akan memperbaikinya.

Simpan bukti dari jendela itu, karena perubahan berikutnya akan dibandingkan dengannya.