OSPF atau EIGRP di atas VTI ASA: yang mana disokong rilis anda
OSPFv2 dan EIGRP hanya merentas VTI ASA mulai 9.19(1), dan hanya dengan multicast diaktifkan. Bandingkan kedua-duanya pada rilis yang anda jalankan, kemudian sahkan jiran.
Kebanyakan perdebatan OSPF lawan EIGRP menganggap terowong sudah boleh membawa protokol itu, dan pada ASA andaian itulah bahagian yang wajar diperiksa dahulu. Perbandingan hanya menjadi menarik selepas imej, jenis VTI dan laluan multicast disahkan. Tersilap urutan itu, anda akan menghabiskan satu petang menala pemasa pada terowong yang tidak akan membentuk kejiranan. Saya memulakan setiap reka bentuk sebegini dengan nota rilis dan konfigurasi yang sedang berjalan, bukan dengan keutamaan protokol.
Rilis yang menentukan sebelum protokol
Panduan VTI Cisco untuk ASA 9.24 ialah asas dokumentasi yang boleh digunakan: ia menerangkan VTI statik dan dinamik serta menyenaraikan penghalaan statik, BGP, OSPF dan EIGRP. Sejarah cirinya meletakkan sokongan OSPFv2 dan EIGRP pada VTI pada 9.19(1). Apa-apa yang lebih lama ialah perbualan lain.
Jadi dua soalan 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 |
Kenyataan bahawa ASA tidak boleh menggunakan VTI, atau tidak boleh membawa IGP, adalah benar bagi sesetengah imej lama dan bukan matriks sokongan semasa. Begitu juga, panduan 9.24 bukan arahan untuk menaik taraf setiap peranti. Ia memberitahu apa yang disokong rilis itu, dan rilis yang anda gunakan mesti menjawab untuk dirinya sendiri.
Unicast yang lepas tidak bermakna IGP akan terbentuk
Panduan yang sama menyatakan bahawa unicast lepas secara lalai dan multicast mesti diaktifkan untuk OSPFv2 atau EIGRP pada VTI, dengan had terdokumen pada kumpulan multicast. Satu ayat itu menjelaskan kebanyakan kejiranan gagal yang saya lihat pada reka bentuk ini. Ping yang berfungsi merentas terowong, atau status IPsec hijau, hanya membuktikan laluan unicast. Penemuan protokol memerlukan laluan multicast, dan kedua-duanya dikonfigurasi secara berasingan.
Periksa konfigurasi antara muka terowong untuk tetapan multicast itu sebelum anda menyentuh pemasa hello atau hold. Jika tetapan tiada, kejiranan bukan lambat, ia mustahil.
OSPF dan EIGRP bersebelahan pada terowong yang sama
Pada terowong itu sendiri kedua-dua protokol kelihatan seperti di tempat lain. OSPF memerlukan jenis rangkaian yang sepadan, kawasan, pengesahan dan parameter jiran; EIGRP memerlukan nombor AS-nya dan tetapan peringkat antara muka yang menyertainya.
Perangkapnya ialah menyalin pernyataan jiran daripada model terowong lain. Nasihat tentang jiran statik dalam reka bentuk tanpa VTI wujud untuk mengelakkan multicast, dan ia tidak berpindah ke VTI yang dijangka membawa protokol secara asli. Konfigurasikan tingkah laku antara muka yang disokong, kemudian biarkan protokol membentuk kejiranannya sendiri.
Kemudian bandingkan pada paksi yang benar-benar berbeza untuk topologi anda: kesalingoperasian dengan pihak lain, tingkah laku penumpuan yang boleh anda uji, dan pengetahuan operasi dalam pasukan anda. Anekdot sejarah tentang satu protokol lebih pantas atau lebih ringan bukanlah ukuran rangkaian anda.
Jiran tidak sama dengan laluan yang dipasang
Setelah kejiranan naik, pisahkan apa yang berasal daripada apa yang diterima. Lihat awalan cawangan mana yang diiklankan setiap pihak, yang mana diterima, yang mana dipilih, dan yang mana benar-benar sampai ke jadual penghalaan. Skop import, eksport dan pengagihan semula sepatutnya disengajakan dan bukan pengumuman menyeluruh tentang semua yang diketahui peranti.
show ospf neighbor dan show eigrp neighbors memberitahu anda bahawa sesi itu hidup. show route memberitahu anda sama ada awalan cawangan tiba, dan itu soalan yang berbeza.
Laluan aplikasi ialah soalan ketiga sekali lagi. Hubungan jiran mengagihkan kebolehcapaian; ia tidak memberi kebenaran melalui tembok api dan tidak membuktikan bahawa pemilih trafik dan peraturan penapisan bersetuju. Sahkan aliran yang dibenarkan dan laluan balasnya dengan ujian yang diluluskan dan bukannya menganggap laluan membayangkan dasar.
Apa yang patut direkodkan oleh perbandingan yang siap
Catatkan antara muka terowong, rilis yang menyokongnya, pertukaran kawalan yang anda sahkan, dan dasar laluan yang anda bataskan. Tambah tetapan multicast, kerana itulah perincian yang secara senyap menentukan sama ada apa-apa yang lain berfungsi. Simpan rekod itu di sebelah rilis yang digunakan supaya perubahan ciri kemudian boleh disemak tanpa bermula semula daripada andaian yang sudah tamat tempoh.
Jika mana-mana satu daripada empat itu tiada, anda mempunyai keutamaan dan bukan reka bentuk. Betulkan dahulu fakta yang hilang; pilihan protokol ialah bahagian yang mudah.