OSPF meningkatkan bandwidth dengan load-balancing


8

Ini adalah pengaturan saya saat ini di mana saya memiliki 40Gbpstautan di antara semua 4 sakelar yang berjalan OSPFmenggunakan tautan L3 di antara mereka, tetapi sekarang saya ingin menggandakan bandwidth di antara sakelar sehingga saya berencana untuk menambahkan (tautan putus-putus) tautan L3 dan membiarkan lalu lintas load-balance OSPF di atasnya , Apakah menurut Anda ada masalah untuk melakukan itu atau ini akan baik-baik saja? (ingin set kedua mata)

masukkan deskripsi gambar di sini

Inilah yang terlihat pada konfigurasi ospf saya di semua 4 switch.

interface Ethernet2/10
  no switchport
  mtu 9216
  ip address 192.168.250.9/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

interface Ethernet2/11
  no switchport
  mtu 9216
  ip address 192.168.250.13/30
  no ip ospf passive-interface
  ip router ospf 100 area 0.0.0.0
  no shutdown

Lebih detail tentang arus lalu lintas saat ini

arus lalu lintas saya saat ini terlihat seperti diagram berikut saat ini SWadalah saklar BGP aktif sehingga semua lalu lintas masuk / keluar dari ISP. kemudian SW1 melakukan load-sharing antara dua SW3 / 4 menggunakan OSPF ECMP. 1 tahun terakhir kami tidak memiliki keluhan tunggal tentang masalah suara atau masalah kualitas (semua orang senang). Sekarang ketika SW1 saya gagal maka OSPF memindahkan rute BGP ke SW2 dan membuatnya activedan lalu lintas mulai mengalir dari SW2 ke SW3 / 4 (Saya telah menguji beberapa waktu ini dengan secara manual menggeser BGP)

masukkan deskripsi gambar di sini

Perbarui - 2

Info pembagian beban untuk OSPF / ECMP

Saya telah mengikuti konfigurasi pembagian beban yang merupakan default pada sakelar cisco nexus.

# show ip load-sharing
IPv4/IPv6 ECMP load sharing:
Universal-id (Random Seed): 2223335843
Load-share mode : address source-destination port source-destination
GRE-Outer hash is disabled.
Concatenation is disabled.

Pastikan Anda meningkatkan tautan antara SW1-2 dan SW 3-4
Ron Trunk

Oh ya .. lupa menambahkannya dalam diagram. tangkapan yang bagus! tetapi sebaliknya apakah Anda melihat ada masalah untuk hanya membawa L3 Link dan serah terima ke OSFP?
Satish

Seingat saya, Anda melakukan banyak hal dengan VoIP. Anda bisa berakhir dengan banyak paket out-of-order yang benar-benar akan mematikan VoIP.
Ron Maupin

@RonMaupin Saya berpendapat bahwa CEF / ECMP menangani "aliran" dengan cukup baik dan akan mencegah pengiriman aliran VoIP yang tidak teratur dengan baik, dengan menetapkan aliran yang diberikan ke antarmuka jalan keluar yang sama secara konsisten.
Marc 'netztier' Luethi

@ Marc'netztier'Luethi, itu sangat tergantung. Protokol routing per-paket load balancing benar-benar dapat mengacaukan protokol waktu-nyata. Saya benar-benar memikirkan saran saluran layer-3 Anda karena itu pasti akan memberikan keseimbangan per aliran.
Ron Maupin

Jawaban:


8

Karena ini adalah tautan Point-to-Point, saya akan mempertimbangkan untuk menggunakan pemadaman untuk mengkonfigurasi setiap / 30 antarmuka ip ospf network point-to-point. (Tautan baru dan yang sudah ada). Ini mengurangi halo dan timer mati. Konfigurasi ini juga mengurangi kebutuhan untuk menegosiasikan DR dan BDR.

Terakhir, saya akan memverifikasi negara tetangga OSPF dan tabel routing, sebelum dan sesudah cutover. Anda harus melihat rute ECMP setelah cutovers dan tetangga yang sesuai.


mendapatkan downtime akan menjadi latihan darurat bagi kami, karena kami memiliki banyak pelanggan sehingga jalan itu tidak mudah. tetapi apakah mungkin SW2dan SW3/4switch saya dikonfigurasi ip ospf network point-to-pointdan kemudian failover lalu lintas saya ke SW2 dan melakukan hal yang sama pada SW1 dan SW3 / 4? Saya telah memperbarui pertanyaan saya
Satish

Rencananya terdengar masuk akal bagiku. Hanya berhati-hati bahwa lalu lintas masih mengalir seperti yang diharapkan di negara failover.
TDurden

Saya juga berencana untuk menambah biaya ospf yang tinggi pada tautan baru dan menunggu beberapa saat sampai semua beres kemudian mengurangi biaya untuk memulai lalu lintas ECMP
Satish

Apakah Anda pikir jika saya mengubah salah satu tautan siaga OSPF untuk p2pakan mengganggu arus lalu lintas saya saat ini? \
Satish

Tidak, namun saya tetap CYA. Jendela perawatan, periksa rute yang disukai, lihat Netflow, tinjau penghitung antarmuka, dll.
TDurden

8

Ada dua cara untuk melakukan itu.

  • cara yang Anda usulkan, dengan menambahkan tautan kedua dengan / 30 atau / 31 miliknya sendiri, memastikan bahwa OSPF menginstal beberapa rute dengan biaya yang sama di tabel perutean, dan biarkan penerusan ECMP (EqualCostMultiPath) CEF menangani pengiriman paket yang mendorong dan distribusi aliran melintasi set tautan yang tersedia. CEF / ECMP menggunakan logika pembagian beban yang berbeda dari Port-Channel, dan dapat menangani jumlah tautan yang tidak rata jauh lebih baik daripada Port-Channels. Lihat posting Blog Ivan Pepelniak untuk referensi.

  • gunakan L3 Port-Channels: Pindahkan IP dan konfigurasi routing ke objek port-channel (yang tidak memiliki perintah "switchport"), dan gabungkan antarmuka yang diberikan ke objek tersebut. Biarkan logika distribusi muatan Port-Channel menangani distribusi arus.

Ide yang Anda usulkan lebih berorientasi L3 / routing, tetapi mengubah skala mungkin memiliki beberapa masalah: Anda akan menggunakan banyak / 30 atau / 31s. Anda dapat menskala dalam angka ganjil, tetapi Anda harus mengonfigurasi tautan baru dan mungkin subnet untuk setiap langkah penskalaan (atau buka ip unnumbered). Pada sisi positifnya, masing-masing tautan dengan subnet mereka sendiri lebih mudah dipecahkan - ping di satu tautan yang diberikan "secara alami".

Di sisi lain, L3 Port-Channels tidak membutuhkan lebih banyak subnet IP dan tidak benar-benar menyentuh logika konfigurasi routing yang diberikan. Port-Channel sedikit lebih "gaya Nexus", karena seluruh sejarah switch Nexus didasarkan pada konsep VPC (yang tidak cukup berlaku di sini, saya akui). Penskalaan tautan tambahan lebih mudah - cukup tambahkan dua, tanpa menyentuh IP atau konfigurasi perutean apa pun. Namun, aturan untuk Port-Channels berlaku (mis. Menjaga jumlah tautan dalam kekuatan 2), sementara pemecahan masalah masing-masing tautan di Port-Channel kurang mudah (tidak dapat melakukan ping melintasi tautan individual tanpa menghapusnya dari saluran-port dan konfigurasi ulang)

ADDON-1: Dan oh ya, tentu saja LAKUKAN ikuti saran TDurden untuk mengkonfigurasi point-to-point pada ... ehm .. tautan point-to-point (benar-benar buruk, saya akui)

CAVEAT-1: Saat menggunakan saluran port memastikan bahwa Anda memilih strategi penyeimbangan beban yang sesuai dengan pola komunikasi yang diharapkan untuk tautan yang diberikan. Saat menghubungkan router ke router (pada dasarnya hanya dua alamat MAC pada tautan), maka "Src / Dst MAC" mungkin tidak memiliki hasil yang diinginkan ... Untuk referensi, lihat Panduan Konfigurasi Antarmuka Cisco Nexus 9000 Series NX-OS, Rilis 9.2 (x)

ADDON-2: Pada Nexus 9000, dengan ECMP / CEF, algoritma pembagian beban dapat dikonfigurasi untuk menyertakan properti L4: ip load-sharing address source-destination port source-destinationLihat Mengkonfigurasi Pembagian Beban di Unicast FIB dari konfigurasi konfigurasi Unicast Routing gude.

CAVEAT-2 Saat menggunakan L3-Port-Channels, perhatikan properti "bandwidth" dari antarmuka port-channel ketika tautan anggota turun. Bergantung pada platform perangkat keras / lunak, bandwidth antarmuka saluran-port mungkin akan berkurang, dan OSPF mungkin bereaksi terhadap hal itu dengan meningkatkan biaya tautan yang diberikan. Ini mungkin memiliki (un) konsekuensi yang dimaksudkan untuk topologi.


Terima kasih telah ikut serta, saya telah memperbarui pertanyaan saya dengan lebih detail, saat ini SW1 aktif dan yang satu melakukan pembagian-pakai, sekarang jika saya menambahkan satu lagi tautan antara SW1 ke SW3 / 4 mengapa menurut Anda ECMP akan menjadi masalah? pengaturan ECMP saya saat ini berjalan dengan baik 1 tahun terakhir tanpa ada masalah. Saya tidak khawatir membuang-buang IP atau mengetik konfigurasi. Saya mencoba membuatnya lebih menyakitkan tanpa downtime :(
Satish

ECMP tidak mendukung pembagian beban Per-Paket, ia menggunakan pembagian beban berdasarkan aliran. cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/…
Satish
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.