Cara memberi sinyal perubahan multihoming VPLS ke perangkat L2 CE

Kami memiliki pengaturan berikut:

Dua router MX terhubung ke situs L2 yang sama. Perlindungan loop / redundansi dilakukan melalui VPLS multihoming . Di ujung lainnya ada dua sakelar (misalnya EX4200).

Ketika tautan biru gagal, kedua sakelar dan sisa infrastruktur L2 harus mengetahui bahwa lalu lintas sekarang harus melalui tautan kuning (dan akibatnya melalui sakelar EX di sebelah kanan).

Masalahnya adalah, tabel mac kuning hanya akan terisi ketika ada lalu lintas yang datang dari VPLS melalui tautan kuning. Jika tidak ada lalu lintas yang diterima dari alamat MAC tertentu, lalu lintas untuk alamat itu masih akan dikirim melalui tautan biru dan tidak ada yang tahu bahwa tautan itu sekarang rusak (kecuali mungkin saklar EX di sebelah kiri jika tautan gagal secara fisik).

Saya tidak dapat menemukan solusi yang baik untuk memperbaiki masalah ini.

Beberapa pendekatan:

1. Anda dapat mengurangi dampaknya dengan tidak membuat portfast tautan biru / kuning sehingga spanning-tree dapat mengirim perubahan topologi ketika antarmuka turun / naik. Ketika antarmuka tidak turun secara fisik Anda kurang beruntung. Di sisi lain solusi spanning tree akan menggigit Anda saat port muncul kembali. VPLS akan membuat situs online tetapi port harus melalui tahap pembelajaran STP sebelum meneruskan lalu lintas.

2. Anda dapat menumpuk kedua sakelar. Ini akan memperbaiki masalah untuk sisa infrastruktur L2 karena mereka selalu mengirim ke switch (stack) yang sama. Tumpukan masih perlu tahu kapan harus beralih ke antarmuka uplink lainnya dengan instance VPLS aktif.

3. Saat melakukan pemeliharaan terencana (dan jika Anda memiliki tumpukan), Anda dapat menonaktifkan tautan primer secara manual untuk beralih ke tautan sekunder. Kemudian Anda dapat menurunkan preferensi situs untuk tautan yang dinonaktifkan pada router sehingga situs yang sekarang aktif menjadi primer baru. Hal yang sama ketika beralih kembali. Tidak ideal dan tidak berfungsi untuk pemadaman yang tak terduga.

Masukan apa pun tentang cara mengatasi masalah ini sangat dihargai. (Menunggu EVPN / TRILL tidak dihitung.;))

1. Nonaktifkan Portfast pada PE menghadap port (On CE)
2. Aktifkan RSTP di seluruh jaringan CE
3. Mendukung "Tautan biru" dengan biaya antarmuka

Mengerjakan ini di kepala saya, saya percaya itu harus bereaksi sebagai berikut:

Ketika tautan biru mati, CE akan berhenti mengirim / menerima BPDU dari antarmuka biru. Timer halo RSTP default adalah 2 detik. Ia menunggu tiga halo yang terlewatkan sebelum menyebut tautan itu "mati". Setelah tiga hellos (6 detik) dilewatkan, maka ia akan membangun kembali pohon STP dan menentukan umur alamat MAC.

Ini pada dasarnya adalah opsi 1 yang telah Anda nyatakan di atas kecuali cara saya membaca komentar dan posting asli Anda. Sepertinya Anda ingin PE berpartisipasi dalam STP. Saya menyarankan agar pelanggan membangun pohon sendiri di antara semua CE.

Jaringan Anda akan gagal dengan lancar, dan jaringan klien akan mengikutinya beberapa detik kemudian.

Ini terasa terlalu sederhana untuk menjadi jawabannya ... tapi itulah yang bisa saya lihat berdasarkan tulisan Anda.

Apa jenis anggaran konvergensi yang Anda cari?

Jika Anda membuang ide menggunakan pencegahan loop VPLS dan menjalankan siteID unik, Anda bisa kembali ke STP. Anda akan mengalami kehilangan tautan melalui BPDU bahkan jika tidak ada kegagalan keaktifan perangkat keras.

Kemudian Anda bisa menyetel anggaran konvergensi Anda dengan TCN / waktu-maju (MAC timeout, setelah TCN terlihat) atau dengan palu yang lebih besar 'mac aging-time'.
Sisi sebaliknya adalah, Anda akan memiliki lebih banyak unicast yang tidak dikenal di jaringan, yang dapat Anda atasi dengan memastikan batas waktu ARP kurang atau sama dengan TCN / waktu-maju

Saya tahu mungkin bukan jawaban yang Anda cari, tetapi jika ada peluru perak di sini, saya melewatkannya. Saya tidak berpikir trill atau EVPN draft akan membantu Anda dalam skenario ini, jika VPLS atau EVPN Anda akan end-to-end langsung ke port host, maka itu akan memperbaikinya. Tetapi hanya mengganti VPLS ke EVPN pada intinya dan menjaga LAN yang terputus di kedua sisi, akan memberikan masalah yang sama.

Berpegang teguh pada opsi yang Anda berikan, saya pribadi akan mengikuti # 1 di daftar Anda, tetapi saya tidak akan menggunakan ST umum. Saya lebih suka menggunakan RST (atau MST jika Anda perlu memuat keseimbangan VLAN di seluruh tautan) karena memungkinkan untuk transisi yang lebih cepat / lancar saat tautan muncul atau turun.

Ini mengatasi kedua kekhawatiran yang Anda miliki untuk pendekatan ini:

1. "Antarmuka tidak turun secara fisik" - setiap perangkat yang menjalankan RST menghasilkan BPDU (bukan hanya menyampaikan) dan digunakan sebagai tetap hidup. Kegagalan untuk menerima BPDU akan mengakibatkan penuaan informasi.
2. "Perlu melalui tahapan pembelajaran STP sebelum meneruskan lalu lintas" - RST dapat secara aktif mengonfirmasi bahwa port dapat dengan aman beralih ke status penerusan tanpa menunggu penghitung waktu.

Saya juga akan mempertimbangkan melakukan # 2 sebagai tambahan karena ini hanya menyederhanakan pengelolaan perangkat.

Mungkin skrip acara dapat dibuat pada MX yang "gagal" untuk menghapus tautannya? Jika ada semacam transportasi yang menyala, maka itu mungkin tidak berfungsi.

Di sebagian besar aplikasi yang saya kerjakan seperti ini, kami memiliki lalu lintas dua arah, sehingga menghapus MAC yang akan pindah akhirnya masuk melalui port cadangan, dan entri FIB lama digusur, dan port baru dipasang.

Jika situs L2 Anda dilayani oleh para EXE yang hanya pernah mengirimkan lalu lintas, maka satu-satunya hal yang bisa saya pikirkan adalah mengurangi waktu mac-table-aging-ke jumlah yang dapat diterima.