Rute hilang di VRF: lokal, VPNv4, atau tabel penerusan?

Seorang pelanggan mengatakan sebuah prefiks hilang setelah perubahan target rute, dan tangkapan layar pertama yang mereka kirim biasanya tabel yang salah. Tiga tabel berbeda menjawab tiga pertanyaan berbeda: apakah prefiks itu ada di dalam VRF, apakah ia diumumkan dan diimpor sebagai rute VPNv4, dan apakah entri penerusan benar-benar dipasang. Membacanya tidak berurutan menghasilkan kesimpulan yang yakin namun keliru. Runbook ini menuntun satu prefiks lokal dan satu prefiks jarak jauh melewati ketiga tabel secara berurutan, dan berakhir dengan rencana pengembalian untuk perubahan RT yang memulainya.

Sebutkan prefiks dan tabel tempatnya berada

Tuliskan dua prefiks sebelum mengetik apa pun. Satu bersifat lokal di lokasi pelanggan, dipelajari dari antarmuka terhubung atau iklan CE. Yang lain bersifat jarak jauh dan diharapkan tiba melalui tulang punggung penyedia. Keduanya menempuh jalur berbeda ke VRF yang sama, dan gangguan pada satu tidak menjelaskan apa pun tentang yang lain.

Jaga perbedaan antara kedua pengenal tetap jelas, karena sebagian besar kebingungan pada tiket ini berasal dari sana. Pembeda rute adalah bagian dari NLRI VPNv4 dan ada untuk membuat prefiks pelanggan yang sebenarnya identik menjadi unik di seluruh tulang punggung. Target rute adalah komunitas diperluas yang dibawa sebagai atribut, dan kebijakan impor serta ekspor mencocokkannya. Itu bukan nama kedua bagi pembeda dan tidak dibawa dalam paket pelanggan.

Langkah 1: buktikan prefiks ada di VRF

Mulai dari tampilan lokal, lalu RT yang mengatur impor. Jika prefiks lokal tidak ada di sini, tidak ada yang di hulu bisa disalahkan:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Prefiks yang tampil sebagai terhubung atau statis dipelajari secara lokal, dan keberadaannya tidak menjelaskan apakah ia diekspor. Inilah salah baca paling umum dalam alur kerja ini: tabel VRF yang sehat hanya bukti pembelajaran lokal. Sisi ekspor adalah pertanyaan terpisah, yang dijawab oleh tampilan tetangga dan target ekspor yang terpasang.

Periksa daftar RT pada VRF selama Anda di sini. Jika target impor yang dimaksud tidak ada dalam daftar, semua yang di hilir tidak relevan. Jika ada tetapi berbeda dari yang diekspor PE jarak jauh, Anda sudah menemukan gangguannya tanpa membuka satu pun tangkapan paket.

Langkah 2: baca tabel VPNv4 dan targetnya

Tabel VPNv4 menunjukkan apa yang benar-benar dipertukarkan bidang kendali. Cari prefiks jarak jauh di bawah pembeda yang benar, lalu lihat komunitas yang terlampir padanya:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Entri dengan target rute yang benar tetapi tanpa pemasangan lokal menunjuk pada kebijakan impor atau pada pemilihan rute, bukan pada keterjangkauan. Entri yang sama sekali tidak muncul di tabel VPNv4 menunjuk ke hulu: PE asal mungkin tidak mengekspornya, atau sesi tidak membawa keluarga alamat tersebut.

Ada kasus ketiga yang membingungkan orang saat perubahan. Sebagian platform membatasi rute VPN mana yang mereka minta atau pertahankan, menggunakan informasi keanggotaan target rute, sehingga tidak adanya NLRI jarak jauh pada satu tampilan tersaring bukan bukti bahwa pengumuman itu tidak ada di mana pun. Periksa tabel tanpa saringan dan rute yang diumumkan tetangga sebelum menyimpulkan sebuah rute ditarik secara global.

Langkah 3: pastikan sesuatu terpasang dan berlabel

Entri BGP adalah keputusan, bukan jalur. Tabel penerusan memberi tahu apakah paket punya tujuan:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Entri CEF dengan ketetanggaan terselesaikan dan label keluar berarti lalu lintas bidang data seharusnya bekerja, dan gejala yang tersisa milik aplikasi atau penyaringan di dalam VRF. Entri CEF yang menunjukkan lompatan berikutnya belum terselesaikan berarti jalur label tidak lengkap meski BGP tampak sehat, dan itulah tepatnya kasus ketika tangkapan layar tabel BGP menyesatkan tinjauan perubahan.

Bandingkan label yang dipaksakan PE lokal dengan label yang diharapkan diterima PE jarak jauh. Ketidakcocokan antara kedua tampilan adalah masalah alokasi label atau sesi, dan tidak akan diperbaiki dengan menyunting target rute, berapa kali pun Anda melakukannya.

Kembalikan perubahan RT dengan cakupan yang dinyatakan

Jika gangguan dimulai dari penyuntingan target rute, batalkan sebagai satu langkah yang disengaja dan sebutkan cakupan apa yang Anda ubah. Menghapus target impor mencabut kelayakan di dalam VRF itu. Itu tidak menghapus pengumuman VPNv4 dari tulang punggung, dan pada sebagian platform rute tetap dipertahankan di tabel. Ini hasil yang berbeda dan efek yang terlihat pengguna bergantung pada mana yang Anda maksud.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Konfigurasi ulang lunak masuk cukup ketika sesi sudah menyimpan prefiks; reset keras sesi yang menghadap penyedia pada jam kerja adalah keputusan yang harus diambil orang lain. Di Junos pemeriksaan setara membaca tabel per VRF dan tabel VPN secara langsung, dan pengembaliannya adalah kembali saat commit bukan pembatalan per perintah, jadi rekam selisih konfigurasi sebelum mulai.

Akhiri dengan tiga perintah yang sama seperti saat mulai, dalam urutan yang sama, dan catat keluarannya dengan cap waktu. Tiket yang menyatakan RT-nya salah dan kini benar tidak dapat dipakai ulang; yang menunjukkan prefiks ada di VRF, ada di VPNv4 dan terpasang di CEF adalah bukti yang bisa dibandingkan orang berikutnya. Jika hanya dua yang pertama berubah, Anda belum menyelesaikan perubahannya.