Mengapa satu tenant EVPN dapat menampilkan beberapa route distinguisher
Dua RD dalam satu tenant bukan konflik. Telusuri dari keluaran CLI ke MAC-VRF atau IP-VRF yang membuat rute, lalu periksa impor RT dan VNI.
Anda memfilter tabel EVPN untuk satu tenant, dan rutenya membawa dua route distinguisher berbeda. Reaksi pertama adalah konflik konfigurasi, dan reaksi itu biasanya keliru. Nama tenant adalah label bisnis, bukan satu objek bidang kendali, sehingga konteks jembatan dan konteks perutean di dalamnya dapat mengumumkan secara sah di bawah pengenal yang terpisah. Telusuri satu rute setiap kali dari keluaran kembali ke objek layanan lokal yang membuatnya, dan RD kedua berhenti tampak seperti kesalahan.
Mulailah dari keluaran yang membingungkan Anda
Pilih satu rute, bukan seluruh tabel. Catat jenis rutenya, RD-nya, route target yang diekspor, dan hop berikutnya. Keempat bidang itu cukup untuk mengenali objek lokal mana yang mengumumkannya dan kebijakan jarak jauh mana yang seharusnya mengimpornya.
Pada perangkat bergaya NX-OS, tampilan detail dicapai dengan show bgp l2vpn evpn route-type 2 detail atau show bgp l2vpn evpn route-type 5 detail. Di Junos, informasi yang sama ada di show route table bgp.evpn.0 detail. Sintaksis berbeda, bidang sama.
Jangan mulai dengan membuat setiap angka yang ditampilkan menjadi sama. Menyamakan RD adalah perubahan yang merusak kebijakan impor pada fabric yang berfungsi.
Beri setiap pengenal tugasnya
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF menyimpan informasi penerusan MAC untuk layanan jembatan. IP-VRF menyediakan konteks perutean IP untuk layanan yang dirutekan. Satu tenant dapat mencakup keduanya, itulah sebabnya satu tenant dapat menghasilkan lebih dari satu RD tanpa kesalahan konfigurasi.
RFC 7432 menetapkan RD dari MAC-VRF yang mengumumkan ke EVPN NLRI-nya dan mewajibkan RD yang berbeda di antara MAC-VRF pada PE yang sama. Prosedur route-target terpisah: mereka mengizinkan satu atau lebih atribut RT dan mengandalkan kebijakan impor untuk keanggotaan. Kesamaan RD bukan yang menciptakan keanggotaan bersama, dan memperlakukannya begitu adalah akar kebingungan ini.
Telusuri satu rute dari pengumuman ke impor
Ikuti rute dalam satu arah. Pastikan jenis rute, layanan yang membuatnya, RD, RT yang diekspor, lalu kebijakan impor pada PE yang menerima. Setiap langkah menjawab pertanyaan berbeda, dan kegagalan pada langkah mana pun tampak seperti prefiks yang sama-sama hilang di sisi lain.
Setelah rute ada, periksa konteks penerusan yang terpasang dan pemetaan VNI. VNI yang cocok di kedua ujung menunjukkan bahwa bidang data setuju; itu tidak menunjukkan bahwa bidang kendali mengimpor rute melalui kebijakan yang dimaksud.
Jika rute muncul di PE jarak jauh tetapi tidak ada lalu lintas, masalahnya sudah melewati EVPN. Periksa pengikatan VNI-ke-VLAN atau VNI-ke-VRF dan jalur underlay sebelum mengedit route target lagi. Mulailah dari pemetaan, lalu underlay, dan baru setelah itu bidang kendali. Mengembalikan perubahan route-target untuk mengejar gangguan bidang data adalah cara yang andal untuk merusak impor yang berfungsi.
Prefiks lapisan 3 tetap merupakan rute EVPN
Prefiks IP di tabel EVPN bukan BGP IPv4-unicast biasa. rute EVPN IP Prefix adalah jenis rute tersendiri, dan pengumuman MAC/IP serta prefiks IP berjalan di keluarga alamat EVPN, yang oleh RFC 7432 diidentifikasi sebagai AFI 25 dan SAFI 70.
Perbedaan itu penting ketika Anda membandingkan rute di tabel EVPN dengan rute di tabel unicast. Keduanya dapat menjelaskan tujuan yang sama dan tetap dihasilkan, difilter, serta diimpor oleh kebijakan berbeda. Membaca yang satu sebagai bukti tentang yang lain adalah cara fabric yang benar tampak rusak selama migrasi.
Periksa penurunan dari vendor sebelum membandingkan angka
RFC 9136 memperluas EVPN dengan rute IP Prefix dan menetapkan apakah RD yang berlaku berasal dari konteks MAC-VRF atau IP-VRF. Karena itu label layanan L2 dan label layanan yang dirutekan dalam keluaran yang sama harus dibaca terhadap objek tempat keduanya berasal, bukan direduksi menjadi satu RD per tenant.
Penurunan RD dan RT otomatis bersifat spesifik vendor. Baca referensi vendor yang diterapkan untuk rumus yang dipakai; nilai yang dibuat otomatis yang terlihat pada satu switch bukan pengodean universal, dan membandingkan angka dua vendor jarang membuktikan apa pun.
Akhiri dengan jejak tertulis untuk rute yang Anda mulai: jenis, objek asal, RD, RT yang diekspor, kebijakan impor, VNI terpasang. Enam bidang menjelaskan pengumuman itu kepada siapa pun yang membaca tiket berikutnya, dan tidak satu pun mengharuskan angka tenant menjadi sama.