Bond aktif-cadangan Linux pada EVPN all-active: apa yang rusak

Pasang bond aktif-cadangan di server, pasang segmen Ethernet all-active di fabric, dan separuh lalu lintas balik bisa hilang tanpa satu pun penghitung galat bergerak. Tidak ada satu pun dari kedua konfigurasi itu yang salah dengan sendirinya. Masalahnya ada pada penyerahan di antara keduanya, ketika satu sisi memilih satu port dan sisi lain menganggap setiap leaf yang terpasang bisa mengirimkan. Ikuti satu frame di setiap arah dan ketidaksesuaiannya menjadi jelas.

Apa yang dilakukan aktif-cadangan pada frame yang masuk

Mode bonding 1 mempertahankan tepat satu slave di jalur pengiriman dan hanya menukarnya ketika yang sedang aktif gagal. Bagian itu sudah dikenal luas. Yang penting di sini adalah sisi penerimaan: kernel hanya menyerahkan frame ke stack jika frame itu tiba di slave aktif, dan membuang frame yang muncul di slave lain mana pun. Pengaturan all_slaves_active ini ada justru untuk melonggarkan aturan itu, dan secara bawaan mati. ip -d link show bond0 mencetak nilai saat ini di samping mode.

/proc/net/bonding/bond0 menyebutkan slave aktif dan melaporkan status tautan tiap slave. Berkas itu satu-satunya sumber jujur tentang port mana yang saat ini membawa lalu lintas.

Host dalam mode ini punya satu jalur penerimaan yang bisa dipakai pada satu waktu, dipilih secara lokal tanpa pengetahuan tentang fabric. Jika frame untuk host itu tiba di kabel lain, port switch menghitungnya sebagai diterima, stack host tidak pernah melihatnya, dan semua penghitung kecuali penghitung drop milik host sendiri tampak sehat sepenuhnya.

Apa yang dilakukan multihoming all-active pada hop berikutnya yang jauh

Multihoming EVPN menjelaskan sekumpulan leaf yang berbagi satu segmen Ethernet, yang ditandai oleh ESI, dan mengumumkan segmen itu ke seluruh fabric lainnya. Dalam model all-active, peer jauh memasang lebih dari satu hop berikutnya untuk alamat segmen tersebut. Unicast menuju server lalu bisa tiba di leaf mana pun, dan fabric bebas memilih per aliran. Itulah seluruh maksud desainnya, dan itu juga asumsi yang harus dipenuhi bond server.

Lalu lintas yang dibanjiri mengikuti aturan berbeda. Leaf memilih forwarder yang ditunjuk per segmen, sehingga broadcast, unicast tak dikenal, dan multicast biasanya masuk melalui salah satunya. Jadi unicast dan pembanjiran mengambil dua keputusan terpisah, dan hanya satu yang muncul di status bond host.

Di mana kedua pemilihan berbeda pendapat

Kernel memilih slave aktifnya dari status tautan dan kebijakannya sendiri. Fabric memilih hop berikutnya dari rute EVPN, dan forwarder yang ditunjuk dari pemilihan di antara leaf. Tidak ada proses yang berkonsultasi dengan yang lain. Ketika keduanya memilih leaf berbeda, kegagalannya bergantung arah: yang dikirim server keluar seperti biasa, dan balasannya menghilang.

Ada dua jalan keluar yang didukung, dan keduanya tidak bisa dipertukarkan. Beri host bond yang bisa diperlakukan fabric sebagai satu sambungan logis, yang dalam praktik berarti bond LACP yang dinegosiasikan dengan leaf, dan kedua tautan benar-benar aktif bersamaan. Atau terima juga pengiriman single-active dari fabric, sehingga segmen mengikuti model satu port pada satu waktu yang sama seperti bond. Yang tidak berhasil adalah segmen all-active di depan bond yang hanya mendengarkan di satu port, kecuali Anda sengaja mengaktifkan penerimaan pada slave yang tidak aktif dan menerima pengiriman ganda yang menyusul.

Mengapa kabel cadangan terus terlihat sehat

Kabel yang tidak membawa lalu lintas tetap melaporkan tautan naik, dan slave siaga dalam bond memang dirancang agar terlihat siap. Operator membacanya sebagai redundansi dan berhenti bertanya.

Tanyakan saja port fisik mana yang dipakai frame balik. Di host, hitung paket yang diterima per slave bukan per bond, karena penghitung bond menyembunyikan asimetrinya. Di leaf, lihatlah entri penerusan bridge untuk MAC server dan himpunan hop berikutnya yang dibawa rute EVPN. Jika entri menunjuk ke leaf yang tautan host-nya menjadi cadangan, desain itu mengirim ke port yang diabaikan host. Ini ketidaksesuaian konfigurasi, bukan kerusakan perangkat keras, dan tidak ada pemantauan status tautan sebanyak apa pun yang akan memunculkannya.

Ujilah pengiriman di kedua arah, bukan status tautan

Bangun matriks dengan satu baris per kegagalan dan satu kolom per arah, lalu isi dengan lalu lintas yang terkirim, bukan status antarmuka. Baris satu adalah operasi normal, dan di situlah ketidaksesuaian bersembunyi, karena gejalanya tampak seperti masalah aplikasi.

Kemudian lepaskan tautan host yang aktif, lepaskan satu leaf, lepaskan uplink leaf itu, dan pulihkan semuanya satu per satu. Setelah setiap langkah, catat slave aktif, status segmen EVPN, entri penerusan jauh, dan throughput yang teramati di kedua arah. Leaf yang kehilangan jalur fabric-nya sementara tautan host-nya tetap naik adalah kasus yang menarik, karena sambungannya tetap diumumkan dan bisa diam-diam menjadi jalan buntu. Ujilah dengan aliran unicast baru dan dengan lalu lintas banjir yang menjadi sandaran aplikasi, karena keduanya memakai keputusan penerusan berbeda.

Terima desainnya hanya ketika matriks menunjukkan pengiriman dua arah melalui jalur yang Anda maksud. Dua kabel dengan tautan naik bukan hasil itu.