Laluan hilang dalam VRF: setempat, VPNv4 atau jadual penghantaran?

Seorang pelanggan berkata sesuatu awalan hilang selepas perubahan sasaran laluan, dan tangkapan skrin pertama yang mereka hantar biasanya jadual yang salah. Tiga jadual berbeza menjawab tiga soalan berbeza: sama ada awalan itu wujud di dalam VRF, sama ada ia diumumkan dan diimport sebagai laluan VPNv4, dan sama ada entri penghantaran benar-benar dipasang. Membacanya di luar urutan menghasilkan kesimpulan yang yakin tetapi salah. Runbook ini membawa satu awalan setempat dan satu awalan jauh melalui ketiga-tiga jadual mengikut urutan, dan berakhir dengan pelan pengunduran untuk perubahan RT yang memulakannya.

Namakan awalan dan jadual tempat ia tergolong

Tulis dua awalan sebelum menaip apa-apa. Satu bersifat setempat di tapak pelanggan, dipelajari daripada antara muka bersambung atau pengumuman CE. Yang lain bersifat jauh dan dijangka tiba melalui tulang belakang penyedia. Kedua-duanya memasuki VRF yang sama melalui laluan berbeza, dan kerosakan pada satu tidak memberitahu apa-apa tentang yang lain.

Kekalkan perbezaan antara kedua-dua pengecam dengan jelas, kerana sebahagian besar kekeliruan dalam tiket ini datang dari situ. Pemisah laluan ialah bahagian NLRI VPNv4 dan wujud untuk menjadikan awalan pelanggan yang sebenarnya sama kekal unik di seluruh tulang belakang. Sasaran laluan ialah komuniti lanjutan yang dibawa sebagai atribut, dan dasar import serta eksport memadankannya. Ia bukan nama kedua bagi pemisah itu dan ia tidak dibawa dalam paket pelanggan.

Langkah 1: buktikan awalan itu ada dalam VRF

Mulakan dengan paparan setempat, kemudian RT yang mengawal import. Jika awalan setempat tiada di sini, tiada apa di hulu boleh dipersalahkan:

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

Awalan yang kelihatan bersambung atau statik dipelajari secara setempat, dan kehadirannya tidak memberitahu apa-apa tentang sama ada ia dieksport. Inilah salah baca yang paling biasa dalam aliran kerja ini: jadual VRF yang sihat hanyalah bukti pembelajaran setempat. Bahagian eksport ialah soalan berasingan, yang dijawab oleh paparan jiran dan sasaran eksport yang dilampirkan.

Periksa senarai RT pada VRF selagi anda di sini. Jika sasaran import yang dimaksudkan tiada dalam senarai, semua di hilir tidak relevan. Jika ada tetapi berbeza daripada apa yang dieksport oleh PE jauh, anda telah menemui kerosakan itu tanpa membuka satu pun tangkapan paket.

Langkah 2: baca jadual VPNv4 dan sasarannya

Jadual VPNv4 menunjukkan apa yang sebenarnya dipertukarkan oleh satah kawalan. Cari awalan jauh di bawah pemisah yang betul, kemudian lihat komuniti yang dilampirkan 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 sasaran laluan yang betul tetapi tanpa pemasangan setempat menunjukkan dasar import atau pemilihan laluan, bukan kebolehsampaian. Entri yang tidak pernah muncul dalam jadual VPNv4 menunjukkan ke hulu: mungkin PE asal tidak mengeksportnya, atau sesi tidak membawa keluarga alamat itu.

Ada kes ketiga yang mengelirukan orang semasa perubahan. Sesetengah platform mengehadkan laluan VPN mana yang mereka minta atau kekalkan, menggunakan maklumat keahlian sasaran laluan, jadi ketiadaan NLRI jauh dalam satu paparan yang ditapis bukan bukti bahawa pengumuman itu tidak wujud di mana-mana. Periksa jadual yang tidak ditapis dan laluan yang diumumkan jiran sebelum membuat kesimpulan bahawa sesuatu laluan telah ditarik balik secara global.

Langkah 3: sahkan sesuatu telah dipasang dan dilabel

Entri BGP ialah keputusan, bukan laluan. Jadual penghantaran memberitahu sama ada paket mempunyai tempat untuk pergi:

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 kejiranan yang diselesaikan dan label keluar bermaksud trafik satah data sepatutnya berfungsi, dan apa-apa gejala yang tinggal tergolong dalam aplikasi atau penapisan di dalam VRF. Entri CEF yang menunjukkan hop seterusnya yang belum diselesaikan bermaksud laluan label tidak lengkap walaupun BGP kelihatan sihat, dan itulah tepat kes apabila tangkapan skrin jadual BGP telah mengelirukan semakan perubahan.

Bandingkan label yang dikenakan oleh PE setempat dengan label yang dijangka diterima oleh PE jauh. Ketidakpadanan antara dua paparan ialah masalah peruntukan label atau sesi, dan ia tidak akan dibaiki dengan mengedit sasaran laluan, berapa kali pun anda melakukannya.

Undurkan perubahan RT dengan skop yang dinyatakan

Jika kerosakan bermula dengan suntingan sasaran laluan, batalkannya sebagai satu langkah yang disengajakan dan nyatakan skop apa yang anda ubah. Membuang sasaran import menarik balik kelayakan di dalam VRF itu. Ia tidak memadam pengumuman VPNv4 daripada tulang belakang, dan pada sesetengah platform laluan itu kekal dipegang dalam jadual. Ini hasil yang berbeza dan kesan yang kelihatan kepada pengguna bergantung pada yang mana anda maksudkan.

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 semula lembut masuk mencukupi apabila sesi sudah menyimpan awalan; tetapan semula keras sesi yang menghadap penyedia pada waktu bekerja ialah keputusan yang perlu diambil oleh orang lain. Pada Junos pemeriksaan setara membaca jadual bagi setiap VRF dan jadual VPN secara langsung, dan pengunduran ialah pemulangan pada masa commit bukan pembatalan bagi setiap arahan, jadi rakam perbezaan konfigurasi sebelum bermula.

Akhiri dengan tiga arahan yang sama seperti anda bermula, dalam urutan yang sama, dan catat outputnya dengan cap masa. Tiket yang berkata RT itu salah dan kini betul tidak boleh digunakan semula; yang menunjukkan awalan ada dalam VRF, ada dalam VPNv4 dan dipasang dalam CEF ialah bukti yang boleh dibandingkan oleh orang seterusnya. Jika hanya dua yang pertama berubah, anda belum menyelesaikan perubahan itu.