Menggunakan latensi untuk menghitung metrik OSPF

Apakah mungkin untuk mengkonfigurasi OSPF untuk menggunakan latensi dalam penghitungan biaya tautan / metriknya. Gagasannya adalah untuk mengaktifkan perutean berbasis kinerja di mana tautan tercepat dan paling tidak padat dalam jaringan akan dipilih secara dinamis, daripada mengandalkan perilaku default OSPF yang menghasilkan tautan 100Mbps yang memiliki biaya yang sama dengan tautan 1Gbps.

Apakah mungkin untuk mengkonfigurasi OSPF untuk menggunakan latensi dalam penghitungan biaya tautan / metriknya. Gagasannya adalah untuk mengaktifkan perutean berbasis kinerja di mana tautan tercepat dan paling tidak padat dalam jaringan akan dipilih secara dinamis, daripada mengandalkan perilaku default OSPF yang menghasilkan tautan 100Mbps yang memiliki biaya yang sama dengan tautan 1Gbps.

Jawaban singkat: Tidak, tidak dengan OSPF saja

Jawaban panjang:

Satu-satunya cara bagi OSPF untuk menghitung jalur secara dinamis berdasarkan latensi / kemacetan adalah dengan menggunakan Rekayasa Lalu Lintas MPLS dengan optimasi offline biaya MPLS TE berdasarkan kriteria Anda ; MPLS TE menggunakan OSPF LSA untuk membawa informasi tentang label pathed paths. Namun, Rekayasa Lalu Lintas MPLS adalah palu berat dan banyak operasi jaringan tidak dapat menangani alur kerja tambahan yang dimasukkan ke dalam penyediaan atau pemecahan masalah MPLS TE.

Jawaban lain menyarankan agar Anda tidak menyesuaikan biaya tautan berdasarkan bandwidth, dan menggunakan peran simpul untuk biaya. Saya tidak dapat berbicara untuk jaringannya, tetapi panduan ini tidak perlu dalam banyak kasus karena jalur biaya terendah dalam topologi yang dirancang dengan baik secara otomatis mengikuti inti jaringan. Saya tidak akan mencoba menyesuaikan topologi yang tidak efisien dengan biaya tautan ... cukup buat lalu lintas mengalir melalui inti secara alami dan pastikan bahwa OSPF melihat 1GE sebagai jalur yang lebih baik daripada tautan FastEthernet. Ini secara alami akan terjadi jika Anda meletakkan topologi dengan baik, dan menggunakan bandwidth referensi-biaya otomatis di bawah proses OSPF. Pastikan Anda menggunakan ini pada semua router OSPF sehingga mereka memahami biaya tautan dengan cara yang sama.

Anda seharusnya tidak mengandalkan metrik / biaya default, bukan di IGP atau STP. Satu pertanyaan saya meninjau apakah LAN dirancang untuk menanyakan tautan mana yang diblokir, jika insinyur tidak dapat menjawab tanpa melihat, itu indikasi kuat bahwa jaringan tidak dirancang.

Anda harus merancang bagaimana Anda ingin lalu lintas mengalir dalam operasi normal dan dalam skenario kesalahan dan kemudian merancang standar metrik dengan memenuhi persyaratan tersebut. Saya lebih suka melakukan ini dengan menambahkan kopi dan pena jika suka.

Saya sangat suka standar metrik berbasis peran , di mana PP, P-PE, PE-PE dll masing-masing memiliki nilai metrik yang sama, terlepas dari bandwidth atau latensi. Artinya, saya tahu ke mana saya ingin lalu lintas saya pergi, bagi saya tidak masalah apa latensi atau kapasitasnya, jika saya tidak memiliki kapasitas yang cukup di mana saya ingin lalu lintas mengalir, saya akan meningkatkan tautan.

Berbasis peran tentu bukan hanya cara untuk melakukannya, jika Anda ingin mendasarkan standar metrik Anda pada kecepatan tautan atau latensi terukur, silakan.

Terlepas dari bagaimana Anda merancang standar metrik Anda, itu akan sepenuhnya statis dan tidak mengetahui kondisi tautan yang sebenarnya seperti kehilangan paket, latensi, jitter, kapasitas, dll. Jika Anda ingin jaringan merespons secara lebih dinamis (permintaan yang cenderung saya pikir sering naik dari perencanaan yang buruk) ) untuk mengubah kondisi jaringan, Anda perlu melihat ke RSVP atau bahkan SDN.

Pilihan lain jika menggunakan PfR atau OER yaitu router menggunakan probe aktif atau data netflow untuk memilih jalur secara dinamis. Atau tentu saja pilihan yang sangat sederhana adalah kode keras nilai biaya OSPF.

Pertimbangan lain adalah Anda mencoba kode metrik statis atau Anda ingin perilaku dinamis (perubahan latensi dengan beban lalu lintas).

Akhirnya seperti yang disebutkan di atas, apakah Anda yakin Anda ingin kompleksitas, jika Anda melihat EIGRP memiliki metrik beban tetapi tidak ada yang pernah menggunakan karena menambah kompleksitas operasional dan Anda bisa mendapatkan osilasi lalu lintas.