Lab MPLS L3VPN tidak bisa ping? Periksa lima titik ini

Dua router pelanggan, sepasang kotak penyedia tepi, dan ping yang mati tanpa pesan kesalahan. Di lab MPLS L3VPN kecil, kesalahan hampir selalu berada di salah satu dari lima titik pemeriksaan, dan masing-masing punya perintah yang menunjukkan apakah ketergantungan itu bekerja atau tidak ada. Kesalahannya adalah memulai ulang BGP setiap kali ping gagal alih-alih menguji ketergantungan secara berurutan. Langsung melompat ke konfigurasi VRF bisa membuat Anda menghabiskan satu jam pada masalah yang dimulai dari next hop tak terselesaikan dua perangkat jauhnya.

Kerjakan daftar dari bawah ke atas. Titik pemeriksaan yang lolos tetap lolos, dan kegagalan pertama itulah yang layak di-debug.

Titik pemeriksaan pertama: para PE dapat saling menjangkau

Setiap PE memerlukan rute ke loopback PE lainnya, dan rute itu harus diresolusi melalui sesuatu yang nyata. Protokol gateway interior adalah cara yang biasa, tetapi rute statis juga berfungsi selama pencarian rekursif mendarat pada adjasensi yang hidup. Pada perangkat bergaya IOS, show ip route 10.0.0.2 diikuti show ip cef 10.0.0.2 memberi tahu Anda apakah prefiks itu ada dan apakah ia punya adjasensi yang teresolusi. Rute di tabel tanpa adjasensi di belakangnya bukanlah keterjangkauan.

Periksa kedua arah. Biaya IGP asimetris, antarmuka pasif di sisi yang salah, atau daftar distribusi yang menyaring loopback masing-masing hanya merusak satu arah, dan satu arah sudah cukup untuk mematikan sesi. Jika loopback dapat di-ping tetapi sesi BGP diam di Active, periksa sumber pembaruan sebelum menyentuh apa pun.

Titik pemeriksaan kedua: jalur label ada

Rute IP ke loopback jauh tidak membuktikan bahwa transport akan mendorong label. Dalam desain LDP, pastikan loopback jauh punya binding lokal dan remote, dan label keluar muncul di tabel penerusan. show mpls ldp bindings 10.0.0.2 32 menunjukkan pasangan label, dan show mpls forwarding-table 10.0.0.2 menunjukkan apa yang benar-benar akan dipasang kartu jalur. Ketika perintah kedua menampilkan „no label“ atau melempar ke IP, transport tidak membawa lalu lintas VPN seperti yang diasumsikan desain.

Perbedaannya berasal dari cara MPLS memisahkan status penerusan dari prefiks tujuan, yaitu model yang dijelaskan dalam RFC 3031. Jika lab Anda memakai RSVP-TE atau label yang berdekatan dengan BGP alih-alih LDP, periksa status mekanisme itu sendiri; mengasumsikan LDP mendistribusikan setiap label underlay adalah cara umum mengejar bug hantu. Jalur label yang rusak biasanya muncul kemudian sebagai rute VPN yang ada tetapi tidak dapat dipakai.

Titik pemeriksaan ketiga: rute VPN tiba utuh

Lihatlah rute VPNv4 atau VPNv6 untuk prefiks pelanggan yang tepat, bukan ringkasan sesi. show bgp vpnv4 unicast all 10.10.1.0/24 seharusnya menunjukkan route distinguisher, next hop yang disetel ke loopback PE jauh, dan sebuah label. Jika prefiksnya hilang, kebijakan ekspor pada PE asal atau kebijakan impor pada PE penerima adalah tersangka pertama, dan route target adalah biang keladi yang biasa.

Bacalah pemeriksaan route target secara terpisah dari penerimaan BGP. Sebuah rute dapat tiba dengan next hop yang benar namun tetap gagal masuk ke VRF karena import target tidak cocok. Pada PE penerima, show ip route vrf CUSTOMER 10.10.1.0 adalah uji yang penting; tabel BGP hanya membuktikan rute itu menyeberangi bidang kendali.

Titik pemeriksaan keempat: antarmuka ada di dalam VRF

Definisi VRF dengan route distinguisher dan route target tidak memindahkan antarmuka apa pun ke dalamnya. Antarmuka yang menghadap CE membutuhkan penetapan VRF, dan show ip vrf interfaces atau show ip interface brief seharusnya mencantumkannya di bawah instans yang benar. Inilah titik pemeriksaan tempat konfigurasi hasil salin paling sering salah, karena blok VRF tampak lengkap sementara antarmuka masih duduk di tabel global.

Lalu pastikan PE telah mempelajari prefiks pelanggan lokal ke dalam VRF itu, dan CE punya rute kembali melalui sambungan tersebut. Default statis di CE yang menunjuk ke PE cukup untuk lab, asalkan VRF PE punya rute ke LAN CE. Jika salah satu bagian hilang, ping gagal sebelum label apa pun dipasang.

Titik pemeriksaan kelima: balasan menemukan jalan pulang

Lacak paket maju lalu lacak paket balik, karena keduanya memakai tabel berbeda. Pada PE masuk, sumber pelanggan harus teresolusi di dalam VRF ke prefiks jauh dengan label jauh. Pada PE keluar, tujuan harus teresolusi di dalam VRF yang sama ke antarmuka yang menghadap CE. Ping yang bersumber dari PE itu sendiri bukan bukti: ia bisa keluar lewat tabel global atau alamat sumber lain, itulah sebabnya ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 adalah uji yang harus dijalankan.

Firewall host, penyaringan jalur balik, dan daftar akses CE tetap berlaku. Jika jalur maju bekerja dan balasan mati, masalahnya adalah rute atau filter di sisi kembali, bukan transport MPLS.

Simpan catatan satu baris per titik pemeriksaan yang menyebutkan ketergantungan pertama yang gagal. Catatan itu mengubah „pelanggan tidak bisa ping“ menjadi pertanyaan spesifik tentang keterjangkauan, status label, impor rute, keanggotaan antarmuka, atau jalur kembali, dan menjauhkan sesi debug berikutnya dari mengulangi lima perintah yang sama dalam urutan yang sama.