IPv6 dalam VPN MPLS: tiga pilihan, bukan satu keluarga alamat
Rute VPN pelanggan, sesi BGP antar-PE, dan transport di inti adalah keputusan terpisah. Satu sesi bisa berjalan di satu keluarga dan membawa keluarga lain.
Katakan “jalankan L3VPN IPv6 di atas BGP IPv6” dalam tinjauan desain, dan tiga keputusan terpisah tersembunyi di dalam satu kalimat itu. Prefiks mana yang milik VPN pelanggan, alamat mana yang membawa sesi perutean di antara tepi penyedia, dan inti mana yang memindahkan paket berlabel adalah pilihan yang independen. Semuanya bisa IPv6, bisa bercampur, dan pencampuran memang sengaja diizinkan. Memisahkan ketiganya itulah yang mengubah kebutuhan yang kabur menjadi sesuatu yang bisa diuji pada platform.
Pisahkan tiga pekerjaan
Pekerjaan pertama adalah rute pelanggan: prefiks IPv6 yang termasuk satu konteks perutean VPN dan harus tetap di luar konteks lain. Yang kedua adalah koneksi perutean di antara router tepi penyedia yang bertukar prefiks itu. Yang ketiga adalah transport yang membawa paket pelanggan berlabel melintasi inti ke tepi jauh. Menyebut hanya salah satunya belum menjadi desain.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Setiap pekerjaan punya keluarga alamatnya sendiri, pola kegagalannya sendiri, dan sering timnya sendiri. Tabel itu berguna justru karena satu kalimat dalam dokumen desain cenderung meremas ketiga baris menjadi satu.
Keluarga rutenya adalah VPN-IPv6, bukan IPv6 unicast
RFC 4659 mendefinisikan keluarga VPN BGP/MPLS IPv6, dan keanggotaan di dalamnya lebih spesifik daripada yang disiratkan kata IPv6. Rute di sana adalah pembeda rute yang digabungkan dengan prefiks IPv6, dikodekan di bawah AFI 2 dan SAFI 128. IPv6 unicast biasa adalah keluarga lain, jadi pengumuman yang tampak seperti prefiks di looking glass mungkin sama sekali bukan objek yang sama. Salah membaca keluarga adalah cara pertama desain ini keliru.
Perbedaannya menggigit di tepi, tempat rute harus mendarat di konteks VPN yang benar sebelum melakukan apa pun. Menerima prefiks membuktikan pertukaran terjadi dan tidak mengatakan apa pun tentang pemasangan. Celah itu menghasilkan laporan klasik ketika sesi menyala dan pelanggan masih gelap.
Sesi bisa berjalan di keluarga yang berbeda dari VPN
Tidak ada yang memaksa koneksi BGP antara dua tepi memakai keluarga milik VPN itu sendiri. Spesifikasi mengizinkan sesi IPv4 atau IPv6, dan transport VPN IPv6 sendiri didefinisikan di atas kedua jenis inti. Jadi sesi IPv6 tidak mengatakan apa pun tentang keluarga yang dibawanya, dan juga tidak memilih bidang data. Tiga bit yang independen, dan desain seharusnya membawa ketiganya secara terpisah.
Itu membebaskan sekaligus mudah dibaca keliru. Rute pelanggan IPv6 bisa menumpang sesi beralamat IPv4, dan rute IPv4 bisa menumpang sesi IPv6, asalkan platform mendukung kombinasi itu dan hop berikutnya teresolusi. Yang tidak boleh terjadi adalah membiarkan sesi menyiratkan muatannya, baik di dokumen desain maupun di pemantauan yang membuktikan layanan nanti.
Hop berikutnya di inti IPv4 punya pengodean sendiri
Ketika inti di bawah VPN adalah IPv4, rute tidak muncul dengan hop berikutnya yang bisa dipakai langsung oleh tepi masuk. Rute datang dalam bentuk IPv6 yang dipetakan ke IPv4, dan begitulah spesifikasi menyatakan tepi keluar ketika transport di bawahnya IPv4. Router masuk kemudian harus mengubah alamat terpetakan itu menjadi sesuatu yang benar-benar bisa dijangkau melintasi inti, dan resolusi adalah langkah yang diam-diam gagal.
Bacalah sebagai ketergantungan penerusan, bukan sebagai string untuk disalin antarperangkat. Pastikan tiga hal pada platform yang benar-benar Anda jalankan: hop berikutnya yang diumumkan teresolusi ke jalur yang bisa dipakai, tumpukan label diterima, dan tujuan mendarat di konteks VPN yang dimaksud. Jika salah satunya gagal, yang tersisa adalah sesi yang tampak sehat dan tidak meneruskan apa pun, karena itu pemeriksaan ini masuk ke uji penerimaan, bukan ke insiden di kemudian hari.
Tulis kebutuhan dalam empat baris
Kebutuhan yang layak diuji menyebut empat hal: keluarga VPN, transport sesi, pengodean hop berikutnya, dan tata letak inti. Lalu ia menyebut satu prefiks pelanggan untuk diikuti dari ujung ke ujung: melalui pertukaran, pemasangan, resolusi label, dan jalur balik. “Mendukung BGP IPv6” tidak mencakup satu pun dari keempatnya dan menyembunyikan di mana ketidakcocokan sebenarnya berada.
Sesi sehat tanpa pertukaran VPN-IPv6 tidak lengkap, dan rute VPN yang diterima tanpa penerusan yang bekerja sama tidak lengkapnya. Menyimpannya sebagai baris penerimaan terpisah membuat percakapan pemecahan masalah berikutnya singkat, karena baris yang gagal sudah tertulis.