Adakah VPNv4 Memerlukan MPLS di Teras? Tidak Semestinya

Menghidupkan keluarga alamat VPNv4 antara dua penghala hanya mencipta konteks pengagihan laluan dan tidak lebih. Ia tidak memasang laluan penghantaran dan tidak memberitahu enkapsulasi mana yang akan membawa paket pelanggan ke titik akhir jauh. Setelah kedua-dua fakta ini dipisahkan, soalan «adakah ini memerlukan MPLS di teras» menjadi soalan yang lebih sempit dan boleh dijawab tentang satah data yang disokong platform.

Apa yang sebenarnya dirundingkan oleh keluarga alamat

BGP berbilang protokol membawa maklumat kebolehcapaian lapisan rangkaian VPNv4 di bawah AFI 1 dan SAFI 128, dan setiap entri memasangkan pembeza laluan dengan awalan dan label. Sesi berunding bahawa kedua-dua pihak boleh mengekod dan menyahkod maklumat itu. Apa yang tidak dirundingkan ialah satah data. Semua selepas perenggan ini berkaitan penghantaran, dan tiada satu pun daripadanya ditentukan oleh sesi yang naik.

Jadi sesi yang berjaya ialah bukti keupayaan satah kawalan, bukan penghantaran. Penghala boleh menyimpan beribu-ribu entri VPNv4 dan masih membuang setiap paket pelanggan, dan itulah sebabnya kedua-dua kelas kegagalan dikelirukan sejak awal.

Perhatikan label dalam NLRI. Ia ialah label perkhidmatan, terikat pada awalan di dalam VRF, dan mempunyai peranan penghantaran apabila paket mencapai titik akhir keluar. Sama ada mana-mana peranti transit membacanya ialah keputusan reka bentuk yang berasingan.

Penerimaan, import dan penghantaran ialah tiga langkah

Menerima laluan, dibenarkan menggunakannya dan mampu menghantar dengannya dilakukan oleh bahagian peranti yang berbeza. BGP menyimpan apa yang didengarnya; dasar import dan padanan sasaran laluan menentukan VRF mana yang boleh mempertimbangkannya; kemudian satah penghantaran mesti menyelesaikan hop seterusnya yang diumumkan menjadi sesuatu yang benar-benar boleh ditolak ke wayar.

Di langkah tengah itulah kegagalan paling mengejutkan tinggal. Laluan boleh hadir dalam jadual BGP, sah dan malah terbaik, sementara jadual laluan VRF kekal kosong kerana tiada sasaran laluan sepadan dengan senarai import. Tiada apa-apa merekodkan ralat protokol, kerana tiada ralat protokol berlaku.

Langkah terakhir ialah tempat sokongan platform muncul. Hop seterusnya yang boleh dicapai dalam lapisan bawah tidak diselesaikan secara automatik sebagai pengangkutan perkhidmatan VPN, dan peranti mungkin memerlukan jenis terowong tertentu, operasi label tertentu atau kedua-duanya. Membaca status penyelesaian lebih bermaklumat daripada membaca bilangan laluan.

Teras IP boleh membawa tindanan yang tidak pernah disuisnya

Beza yang wajar dikekalkan ialah antara «teras tidak menjalankan MPLS» dan «tiada label di mana-mana dalam perkhidmatan». Itu ialah dakwaan yang berbeza, dan hanya yang pertama tentang peranti transit. RFC 4023 mentakrifkan pembawaan MPLS melalui terowong IP atau GRE, dan itulah mekanisme yang menjadikan dakwaan kedua mungkin pada teras sepenuhnya IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Penghala transit menghantar berdasarkan destinasi IP luar dan tidak memerlukan awalan pelanggan mahupun pensuisan label asli. Di hujung jauh terowong luar dibuang dan label perkhidmatan menyambung semula kerjanya. Teras memindahkan muatan legap, dan itulah tepat apa yang rangkaian IP baik padanya.

Apa yang reka bentuk ini tidak berikan kepada anda ialah jaminan sejagat. Ini bukan bukti bahawa setiap penghala menyelesaikan setiap hop seterusnya VPNv4 melalui mana-mana antara muka GRE, dan bukan sebab untuk memadam konfigurasi MPLS asli yang berfungsi. Ini ialah contoh lawan kepada dakwaan sejagat, dan soalan praktikal kekal setempat kepada platform. Catat soalan itu sebagai had platform dan bukan sebagai peraturan protokol.

Jelajah rantaian pada kotak sehingga ia patah

Mulakan dari laluan yang diterima dan berhenti pada langkah pertama yang gagal, kerana langkah seterusnya tidak boleh didiagnosis selagi langkah terdahulu rosak. Empat arahan meliputi sebahagian besarnya dalam pelaksanaan biasa.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Bacalah sebagai urutan dan bukan sebagai empat semakan bebas. Yang pertama mengesahkan keluarga aktif dan rakan setara bertukar laluan; yang kedua menunjukkan sama ada awalan tiba dengan hop seterusnya yang boleh digunakan; yang ketiga membuktikan kelayakan import; yang keempat menunjukkan sama ada satah penghantaran mengikat label atau terowong padanya.

Kemudian uji laluan beban kerja dalam kedua-dua arah, dengan MTU yang bertahan enkapsulasi. GRE menambah bait pengepala, dan laluan yang lulus ujian kecil boleh gagal pada paket bersaiz penuh hanya dalam satu arah, yang kelihatan seperti kerosakan aplikasi dan bukan pengangkutan.

Dua nota operasi menutup gelung. GRE ialah enkapsulasi, bukan kerahsiaan, jadi rangkaian transit tidak dipercayai memerlukan susunan keselamatan yang disokong di atasnya dan bukan andaian. Dan catat enkapsulasi mana yang benar-benar disokong platform sebelum semakan reka bentuk, kerana jawapan tunggal itu menentukan sama ada teras hanya-IP ialah pilihan yang sah atau pelan yang tidak boleh menghantar.