Tunnel RSVP-TE aktif, tetapi L3VPN pelanggan tidak punya jalur
Transportasi dan layanan adalah keputusan terpisah. Baca tumpukan label, periksa resolusi hop berikutnya dan keterikatan VRF secara terpisah, lalu uji satu aliran pelanggan yang nyata.
Dua tim bisa sama-sama benar ketika pelanggan melaporkan bahwa VPN mati dan tim transportasi melaporkan bahwa tunnel baik-baik saja. LSP dengan rekayasa lalu lintas dan MPLS L3VPN menjawab pertanyaan yang berbeda: yang satu memindahkan paket berlabel melintasi inti, yang lain memutuskan konteks perutean milik paket. Ketika keduanya dicampur, perdebatan berputar-putar karena setiap pihak mengukur objek yang berbeda dan kedua pengukuran itu sah.
Transportasi aktif dan layanan mati adalah keadaan normal
LSP dapat terbentuk, membawa lalu lintas, dan terlihat di setiap sistem pemantauan, sementara layanan pelanggan tetap tidak dapat digunakan. Tidak ada yang kontradiktif dalam kombinasi itu, karena tunnel tidak punya pendapat soal ada atau tidaknya prefiks jauh, diterima atau tidaknya oleh kebijakan impor, atau lewat atau tidaknya bingkai pada sirkuit keterikatan.
Gejala yang biasanya membuka kebingungan bersifat asimetris: ping dari loopback PE berhasil sementara host di LAN pelanggan tidak menerima apa pun, atau sebaliknya. Catat alamat mana yang berhasil sebelum Anda membentuk teori. Begitu Anda menyadari sedang menguji dua objek berbeda, langkah berikutnya adalah membaca tumpukan label, bukan berdebat tentang grafik siapa yang benar. Dua alamat, dua pemilik, dan biasanya dua orang berbeda yang masing-masing yakin pihak lain merusak sesuatu.
Baca tumpukan sebagai dua tanggung jawab
Label bawah milik layanan dan label atas milik jalur. RFC 4364 menjelaskan urutannya dengan sederhana: label rute VPN dipasang lebih dulu, lalu paket berlabel itu ditunnelkan menuju hop berikutnya BGP, dan di sanalah tunnel rekayasa lalu lintas menekan labelnya sendiri di atas.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
Di PE jauh, label layanan memilih perlakuan, yang bisa berupa pencarian VRF atau keputusan keterikatan. Label itu tidak dapat ditukar dengan label yang hanya melintasi inti, dan keduanya tidak dapat dipertukarkan meskipun keduanya muncul dalam tumpukan yang sama pada antarmuka yang sama.
Apa yang dibuktikan keberhasilan RSVP dan apa yang tidak
RSVP-TE membangun LSP dengan rute eksplisit, dengan atau tanpa reservasi sumber daya, yang merupakan jaminan spesifik dan berguna tentang jalur yang ditempuh paket melalui inti. Ini bukan pernyataan tentang rute pelanggan, dan nama tunnel yang dikonfigurasi sama sekali bukan rute.
Kehadiran RSVP juga tidak memberi janji kinerja ujung ke ujung. Reservasi bandwidth pada satu LSP tidak mengatakan apa pun tentang sirkuit keterikatan, jalur akses milik pelanggan, atau perilaku antrean di tepi jauh. Memperlakukannya sebagai jaminan menghasilkan jawaban percaya diri atas pertanyaan yang tidak diajukan siapa pun. Jika persyaratannya benar-benar komitmen bandwidth, itu harus dirakit dari bagian-bagian yang benar-benar menegakkannya, dan LSP hanyalah bagian tengah rantai itu.
Periksa berurutan, lalu berhenti
Bekerjalah dari transportasi ke luar dan berhentilah pada langkah pertama yang gagal, karena setiap langkah berikutnya mengandaikan langkah sebelumnya bertahan. Pertama pastikan LSP terbentuk dan entri penerusan untuk prefiks layanan benar-benar menunjuk ke sana. Lalu pastikan rute VPN ada di tabel yang benar, pengikatan labelnya tersedia, dan kebijakan impor menerimanya. Lalu pastikan keterikatan: antarmuka, enkapsulasi, dan bila berlaku, pengenal VLAN yang menjadi milik kontrak tersebut.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERSintaks perintah berbeda menurut platform, jadi perlakukan keempat baris itu sebagai empat pertanyaan, bukan skrip. Bagian pentingnya adalah masing-masing menanyai objek yang berbeda, dan itulah yang membuat kegagalan menunjuk ke pemilik tertentu.
Ikuti satu permintaan yang diizinkan dan simpan bukti yang baik
Akhiri dengan satu permintaan pelanggan nyata yang diizinkan kebijakan, beserta balasannya. Satu aliran yang berfungsi dari ujung ke ujung menyelesaikan lebih dari satu halaman pembacaan penghitung, dan itu menguji kombinasi, bukan setiap bagian secara terpisah.
Ketika tahap berikutnya gagal, pertahankan pengamatan LSP yang berhasil alih-alih membangun ulang transportasi. Membangun ulang tunnel yang berfungsi tidak dapat memperbaiki prefiks jauh yang tidak ada, keterikatan VRF yang salah, atau aturan akses tujuan, dan itu menghancurkan bukti yang semula memberi tahu Anda bahwa transportasi sehat.