IPv6 dalam VPN MPLS: tiga pilihan, bukan satu keluarga alamat
Laluan VPN pelanggan, sesi BGP antara PE dan pengangkutan teras ialah keputusan berasingan. Satu sesi boleh berjalan dalam satu keluarga dan membawa keluarga yang lain.
Sebut “jalankan L3VPN IPv6 di atas BGP IPv6” dalam semakan reka bentuk, dan tiga keputusan berasingan tersembunyi dalam satu ayat itu. Prefiks mana milik VPN pelanggan, alamat mana yang membawa sesi penghalaan antara tepi penyedia, dan teras mana yang menggerakkan paket berlabel ialah pilihan yang bebas. Semuanya boleh jadi IPv6, boleh bercampur, dan pencampuran memang sengaja dibenarkan. Memisahkan ketiga-tiganya itulah yang menjadikan keperluan kabur sebagai sesuatu yang boleh diuji pada platform.
Pisahkan tiga tugasan
Tugasan pertama ialah laluan pelanggan: prefiks IPv6 yang tergolong dalam satu konteks penghalaan VPN dan mesti kekal di luar setiap konteks lain. Yang kedua ialah sambungan penghalaan antara penghala tepi penyedia yang bertukar prefiks itu. Yang ketiga ialah pengangkutan yang membawa paket pelanggan berlabel merentasi teras ke tepi jauh. Menyebut hanya satu daripadanya belum menjadi reka bentuk.
| 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 tugasan mempunyai keluarga alamatnya sendiri, corak kegagalannya sendiri dan selalunya pasukannya sendiri. Jadual itu berguna kerana satu ayat dalam dokumen reka bentuk cenderung memampatkan ketiga-tiga baris menjadi satu.
Keluarga laluan itu ialah VPN-IPv6, bukan IPv6 unicast
RFC 4659 mentakrifkan keluarga BGP/MPLS IPv6 VPN, dan keahlian di dalamnya lebih khusus daripada yang disyaratkan oleh perkataan IPv6. Laluan di sana ialah pembeza laluan yang digabungkan dengan prefiks IPv6, dikodkan di bawah AFI 2 dan SAFI 128. IPv6 unicast biasa ialah keluarga lain, jadi iklan yang kelihatan seperti prefiks dalam looking glass mungkin bukan objek yang sama langsung. Salah membaca keluarga itulah cara pertama reka bentuk ini tersasar.
Perbezaannya menggigit di tepi, tempat laluan mesti mendarat dalam konteks VPN yang betul sebelum ia melakukan apa-apa. Menerima prefiks membuktikan pertukaran berlaku dan tidak berkata apa-apa tentang pemasangan. Jurang itu menghasilkan laporan klasik apabila sesi hidup tetapi pelanggan masih gelap.
Sesi boleh berjalan dalam keluarga yang berbeza daripada VPN
Tiada apa yang memaksa sambungan BGP antara dua tepi menggunakan keluarga VPN itu sendiri. Spesifikasi membenarkan sesi IPv4 atau IPv6, dan pengangkutan VPN IPv6 sendiri ditakrifkan di atas kedua-dua jenis teras. Jadi sesi IPv6 tidak berkata apa-apa tentang keluarga yang dibawanya, dan ia juga tidak memilih satah data. Tiga bit yang bebas, dan reka bentuk sepatutnya membawa ketiga-tiganya secara berasingan.
Itu membebaskan dan pada masa yang sama mudah disalah baca. Laluan pelanggan IPv6 boleh menumpang sesi beralamat IPv4, dan laluan IPv4 boleh menumpang sesi IPv6, asalkan platform menyokong gabungan itu dan hop seterusnya dapat diselesaikan. Apa yang tidak boleh berlaku ialah membiarkan sesi mengisyaratkan muatan, sama ada dalam dokumen reka bentuk atau dalam pemantauan yang membuktikan perkhidmatan kemudian.
Hop seterusnya pada teras IPv4 mempunyai pengekodan sendiri
Apabila teras di bawah VPN ialah IPv4, laluan tidak muncul dengan hop seterusnya yang boleh digunakan terus oleh tepi masuk. Ia tiba dalam bentuk IPv6 yang dipetakan ke IPv4, dan begitulah spesifikasi menyatakan tepi keluar apabila pengangkutan di bawahnya IPv4. Penghala masuk kemudiannya mesti menukar alamat yang dipetakan itu kepada sesuatu yang benar-benar dapat dicapainya merentasi teras, dan penyelesaian itulah langkah yang gagal secara senyap.
Bacalah sebagai kebergantungan penghantaran dan bukan sebagai rentetan untuk disalin antara peranti. Sahkan tiga perkara pada platform yang benar-benar anda kendalikan: hop seterusnya yang diumumkan diselesaikan kepada laluan yang boleh digunakan, timbunan label diterima, dan destinasi mendarat dalam konteks VPN yang dimaksudkan. Jika mana-mana satu gagal, yang tinggal ialah sesi yang kelihatan sihat dan tidak menghantar apa-apa, sebab itu semakan ini tergolong dalam ujian penerimaan, bukan dalam insiden kemudian.
Tulis keperluan dalam empat baris
Keperluan yang wajar diuji menamakan empat perkara: keluarga VPN, pengangkutan sesi, pengekodan hop seterusnya dan susunan teras. Kemudian ia menamakan satu prefiks pelanggan untuk dijejaki dari hujung ke hujung: melalui pertukaran, pemasangan, penyelesaian label dan laluan balik. “Menyokong BGP IPv6” tidak merangkumi mana-mana daripada empat itu dan menyembunyikan di mana ketidakpadanan sebenarnya berada.
Sesi sihat tanpa pertukaran VPN-IPv6 adalah tidak lengkap, dan laluan VPN yang diterima tanpa penghantaran yang berfungsi juga sama tidak lengkap. Menyimpannya sebagai baris penerimaan berasingan memendekkan perbualan penyelesaian masalah seterusnya, kerana baris yang gagal sudah pun tertulis.