OSPF atau EIGRP di atas VTI ASA: mana yang didukung rilis Anda
OSPFv2 dan EIGRP hanya berjalan di atas VTI ASA mulai 9.19(1), dan hanya dengan multicast aktif. Bandingkan keduanya pada rilis yang Anda jalankan, lalu verifikasi tetangga.
Sebagian besar perdebatan OSPF versus EIGRP mengasumsikan tunnel sudah dapat membawa protokolnya, dan pada ASA justru asumsi itu bagian yang perlu diperiksa lebih dulu. Perbandingan baru menarik setelah image, tipe VTI, dan jalur multicast dipastikan. Salah urutan itu, Anda menghabiskan satu sore menyetel timer pada tunnel yang tidak akan pernah membentuk ketetanggaan. Saya memulai setiap desain seperti ini dengan catatan rilis dan konfigurasi yang berjalan, bukan dengan preferensi protokol.
Rilis yang memutuskan sebelum protokolnya
Panduan VTI Cisco untuk ASA 9.24 adalah dasar dokumentasi yang bisa dipakai: ia menjelaskan VTI statis dan dinamis serta mendaftar routing statis, BGP, OSPF, dan EIGRP. Riwayat fiturnya menempatkan dukungan OSPFv2 dan EIGRP pada VTI di 9.19(1). Apa pun yang lebih lama dari itu adalah pembicaraan lain.
Jadi dua pertanyaan pertama membosankan dan menentukan:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
Pernyataan bahwa ASA tidak dapat memakai VTI, atau tidak dapat membawa IGP, benar untuk beberapa image lama dan bukan matriks dukungan saat ini. Sama halnya, panduan 9.24 bukan instruksi untuk mengupgrade setiap perangkat. Panduan itu memberi tahu apa yang didukung rilis tersebut, dan rilis yang Anda terapkan harus menjawab untuk dirinya sendiri.
Unicast yang lewat bukan berarti IGP akan terbentuk
Panduan yang sama mencatat bahwa unicast lewat secara default dan multicast harus diaktifkan untuk OSPFv2 atau EIGRP pada VTI, dengan batas terdokumentasi pada grup multicast. Satu kalimat itu menjelaskan sebagian besar ketetanggaan gagal yang saya lihat pada desain ini. Ping yang bekerja melintasi tunnel, atau status IPsec hijau, hanya membuktikan jalur unicast. Penemuan protokol membutuhkan jalur multicast, dan keduanya dikonfigurasi terpisah.
Periksa konfigurasi antarmuka tunnel untuk pengaturan multicast itu sebelum Anda menyentuh timer hello atau hold. Jika pengaturan itu tidak ada, ketetanggaan bukan lambat, melainkan mustahil.
OSPF dan EIGRP berdampingan pada tunnel yang sama
Pada tunnel itu sendiri kedua protokol tampak seperti di tempat lain. OSPF membutuhkan tipe jaringan yang cocok, area, autentikasi, dan parameter tetangga; EIGRP membutuhkan nomor AS-nya dan pengaturan tingkat antarmuka yang menyertainya.
Jebakannya adalah menyalin pernyataan tetangga dari model tunnel lain. Saran tentang tetangga statis pada desain tanpa VTI ada untuk menghindari multicast, dan itu tidak berlaku untuk VTI yang diharapkan membawa protokol secara native. Konfigurasikan perilaku antarmuka yang didukung, lalu biarkan protokol membentuk ketetanggaannya sendiri.
Kemudian bandingkan pada sumbu yang benar-benar berbeda untuk topologi Anda: interoperabilitas dengan sisi lain, perilaku konvergensi yang dapat Anda uji, dan pengetahuan operasional di tim Anda. Anekdot historis bahwa satu protokol lebih cepat atau lebih ringan bukanlah pengukuran jaringan Anda.
Tetangga tidak sama dengan rute yang terpasang
Setelah ketetanggaan naik, pisahkan apa yang berasal dari apa yang diterima. Lihat prefiks cabang mana yang diiklankan tiap sisi, mana yang diterima, mana yang dipilih, dan mana yang benar-benar mencapai tabel routing. Cakupan impor, ekspor, dan redistribusi sebaiknya disengaja, bukan pengumuman menyeluruh atas semua yang diketahui perangkat.
show ospf neighbor dan show eigrp neighbors memberi tahu Anda bahwa sesi hidup. show route memberi tahu Anda apakah prefiks cabang tiba, dan itu pertanyaan yang berbeda.
Jalur aplikasi adalah pertanyaan ketiga lagi. Hubungan tetangga mendistribusikan keterjangkauan; itu tidak memberikan izin menembus firewall, dan tidak membuktikan bahwa selektor lalu lintas dan aturan penyaringan sepakat. Verifikasi aliran yang diizinkan dan jalur balasannya dengan uji yang disetujui, bukan mengasumsikan rute berarti kebijakan.
Apa yang harus dicatat perbandingan yang selesai
Catat antarmuka tunnel, rilis yang mendukungnya, pertukaran kontrol yang Anda verifikasi, dan kebijakan rute yang Anda batasi. Tambahkan pengaturan multicast, karena itulah detail yang diam-diam menentukan apakah sisanya bekerja. Simpan catatan itu di samping rilis yang diterapkan agar perubahan fitur nanti dapat ditinjau tanpa memulai lagi dari asumsi yang sudah kedaluwarsa.
Jika salah satu dari keempatnya tidak ada, Anda punya preferensi, bukan desain. Perbaiki dulu fakta yang hilang; pilihan protokol adalah bagian yang mudah.