VRF mana yang mencapai peer VPN dan mana yang membawa paket?
Sebuah terowongan dapat memakai satu konteks perutean untuk mencapai peer-nya dan konteks lain untuk meneruskan paket yang dilindungi. Periksa kedua pencarian secara terpisah sebelum menambahkan rute.
Setiap terowongan di dalam konteks perutean pelanggan tetap harus mencapai peer jauhnya, dan pencarian itu bisa terjadi di tabel yang sama sekali berbeda. Kesalahan di sini menghasilkan salah satu kegagalan paling membingungkan dalam IPsec yang sadar VRF: terowongan naik, rute tampak ada, dan lalu lintas mati karena salah satu dari dua pencarian memakai konteks yang salah. Jalankan empat langkah di bawah ini secara berurutan, dan catat kedua tujuan secara terpisah.
Dua pencarian, satu terowongan
Paket terenkapsulasi luar dialamatkan ke alamat transport peer, dan paket itu dirutekan sebelum ada perlindungan apa pun. Paket dalam dialamatkan ke server pelanggan dan dirutekan setelah dekapsulasi, di dalam konteks pelanggan. Itu dua tujuan, dua pencarian, dan sering dua tabel berbeda.
Dokumentasi Cisco untuk IPsec yang sadar VRF menyebutnya VRF pintu depan dan VRF dalam. Pintu depan membawa transport terenkripsi, dan konteks dalam membawa lalu lintas yang dilindungi. Tidak ada yang membuat salah satu rute muncul hanya karena terowongan dinamai menurut pelanggan.
Jadi daftarkan empat fakta sebelum mengubah konfigurasi: alamat transport peer dan konteks yang mencapainya, lalu prefiks server dan konteks yang mencapainya. Jika Anda tidak dapat mengisi keempatnya, Anda akan menebak. Menebak di bidang ini mahal, karena rute yang ditambahkan ke tabel yang salah dapat membuat satu aliran bekerja sambil diam-diam merusak aliran lain. Keempat fakta itu butuh sepuluh menit untuk dikumpulkan dan menghemat satu hari analisis tangkapan paket.
Pastikan pencarian transport untuk peer
Mulailah dari pintu depan, karena terowongan yang tidak dapat mencapai peer-nya tidak akan pernah meloloskan satu paket terlindungi pun. Di IOS, mintalah rute ke peer di dalam VRF transport, bukan di tabel global.
show ip route vrf wan-blue 203.0.113.20 show ip vrf brief show crypto ikev2 sa
Perintah pertama menjawab apakah alamat peer dapat dijangkau dalam konteks itu, yang kedua mendaftar VRF yang benar-benar ada, dan yang ketiga menunjukkan apakah asosiasi keamanan terbentuk. Alamat peer yang hanya terurai di tabel global adalah kesalahan pintu depan klasik, dan tampil sebagai negosiasi IKE yang tidak pernah dimulai.
Periksa juga penetapan antarmuka. Perilaku yang didokumentasikan mengharuskan VRF pintu depan terowongan dan VRF antarmuka WAN sepakat; ketidakcocokan dapat membiarkan paket keluar dan tetap mencegah balasan diproses dalam konteks yang benar.
Pastikan pencarian dalam untuk server
Setelah pintu depan terbukti, beralihlah ke konteks pelanggan dan ajukan pertanyaan yang sama tentang prefiks server. Pencarian ini menentukan apakah paket yang telah didekapsulasi dapat diteruskan.
show ip route vrf customer-blue 10.60.4.0 show crypto session detail
Perintah pertama menampilkan rute dalam, dan yang kedua menampilkan status sesi bersama konteks yang diasosiasikan platform dengannya. Jika rute ada tetapi detail sesi menyebut konteks dalam yang salah, terowongan meneruskan ke tabel yang tidak mengenal prefiks pelanggan.
Rute di tabel global bukan bukti untuk salah satu dari dua pencarian. Rute global dipakai ketika paket tidak diasosiasikan dengan VRF, dan antarmuka terowongan yang ditetapkan ke konteks pelanggan mengubah asosiasi itu. Jika rute dalam tidak ada, paket didekapsulasi lalu dibuang karena tidak ada entri penerusan, yang tampak seperti kehilangan paket, bukan kesalahan perutean.
Tempatkan pengaturan di tempat model mengharapkannya
Dokumentasi yang sama membedakan model konfigurasi, dan pengaturan yang termasuk dalam satu model belum tentu termasuk dalam model lain. Untuk antarmuka terowongan yang memakai perlindungan terowongan, VRF dalam didefinisikan pada antarmuka terowongan. Untuk rancangan berbasis crypto map, VRF dalam adalah bagian dari entri crypto map. Memindahkan perintah bernama mirip antar model tanpa memeriksa perannya adalah cara rancangan yang berfungsi menjadi tidak stabil.
Perutean dan identitas adalah urusan terpisah. Keterjangkauan tidak pernah menggantikan profil peer yang akan diterima perangkat, dan penggantian nama VRF tidak boleh mengubah kredensial yang ditawarkan. Periksa keduanya setelah setiap perubahan, karena terowongan yang bernegosiasi dengan profil yang salah tetap dapat membentuk asosiasi dan tidak meneruskan apa pun.
Terakhir, catat keempat fakta dan perintah yang membuktikannya dalam catatan perubahan. Insinyur berikutnya akan mewarisi terowongan, bukan penalarannya, dan catatan singkat yang menyebut kedua konteks lebih berharga daripada diagram yang tidak pernah diperbarui siapa pun.