Dua penyewa memberi nomor cabang mereka dengan 10.50.0.0/24 yang sama, dan setelah sebuah perubahan rute salah satu penyewa hilang dari tepi penyedia sementara yang lain tetap berjalan. Penyederhanaan di balik tiket itu biasanya membuang pembeda rute (RD) karena „label sudah mengidentifikasi pelanggan“. Tidak. RD dan label menjawab dua pertanyaan berbeda, dan celahnya baru terlihat ketika alamat yang bertumpang tindih memaksanya.

Satu rute padahal seharusnya dua

Unicast IPv4 biasa membandingkan dua jalur ke prefiks yang sama dan memasang yang lebih baik. 10.50.0.0/24 dari penyewa A dan 10.50.0.0/24 dari penyewa B adalah satu kunci, sehingga satu menang dan yang lain hanya bertahan sebagai jalur cadangan. Protokol melakukan apa yang diperintahkan; bidang kendali diminta menyimpan dua rute berbeda di bawah satu pengenal.

Hasilnya tampak seperti rute yang hilang, bukan kesalahan: PE yang kalah dalam persaingan masih meneruskan penyewanya secara lokal, jadi ping di dalam situs berhasil dan uji antar situs gagal. Hitung entri untuk prefiks itu di tabel VPNv4 sebelum menyentuh kebijakan apa pun.

RD mengubah satu kunci menjadi dua

Pembeda rute sepanjang delapan byte ditambahkan di depan prefiks IPv4, dan objek yang dibawa BGP menjadi alamat VPN-IPv4 alih-alih prefiks IPv4. Dua penyewa dapat memegang 32 bit yang sama karena 64 bit di depannya berbeda. Ada tipe format untuk RD berbasis AS dan untuk yang berbasis alamat, dan pilihannya milik PE asal. RD berbasis AS umum ketika PE berbagi AS, dan yang berbasis alamat ketika tidak.

Jangan membaca RD sebagai tanda keanggotaan. Target rute mengatur impor dan ekspor dan menentukan VRF mana yang boleh memasang rute itu; RD hanya menjamin bahwa rute memiliki identitasnya sendiri. Memberi setiap VRF RD-nya sendiri adalah praktik umum karena menjaga pemetaan itu tetap terbaca di penampil rute.

Label adalah instruksi penerusan lokal

Setiap iklan juga membawa label MPLS, dan maknanya dibatasi pada router yang mengalokasikannya. PE lain dapat memberikan nomor yang sama untuk tujuan yang tidak terkait. Karena itulah label tidak dapat menggantikan identitas pelanggan: nomor itu hanya benar di samping hop berikutnya dan status penerusan yang memasangnya.

Granularitas alokasi bervariasi menurut implementasi dan desain: sebagian platform memberikan satu label per VRF, yang lain per prefiks, dan label dapat menandai tindakan penerusan alih-alih pelanggan. Dua label berbeda yang mencapai tujuan yang sama bukan kontradiksi, dan nomor label yang sama di dua PE juga bukan.

FieldWhere it livesScopeIf you remove it
RDVPNv4 NLRIPer advertised routeOverlapping prefixes collide
Route targetExtended communityImport and export policyRoute lands in the wrong VRF
LabelLabeled NLRI and forwarding statePer allocating routerNo instruction for the data plane
Next hopPath attributePer pathThe label cannot be resolved

Mengapa yang satu tidak dapat menggantikan yang lain

Membaca iklan berarti melihat empat hal sekaligus: prefiks berkualifikasi RD, target rute, hop berikutnya, dan label. Membaca paket pengguna berarti melihat tumpukan yang dipasang dari informasi itu. Desain yang sehat menunjukkan kedua sisi cocok, dan yang rusak biasanya punya satu sisi benar dan sisi lain basi. Perbandingan itulah yang memisahkan masalah identitas dari masalah penerusan.

Kontras rapi antara bidang kendali dan bidang data adalah alat ajar, bukan deskripsi pengodean. RFC 8277 menaruh label di dalam NLRI berlabel, jadi iklannya sendiri membawa ikatan itu; memakainya untuk penerusan adalah langkah berikutnya yang terpisah.

Ketika rute penyewa hilang, periksa dengan urutan ini: dua entri VPNv4 untuk prefiks, target rute yang benar pada masing-masing, hop berikutnya yang dapat diselesaikan, dan label yang statusnya dimiliki PE penerima. Memperbaiki identitas dengan nilai penerusan, atau sebaliknya, akan lolos satu pemeriksaan dan gagal di pemeriksaan berikutnya.

Artikel terkait