Sesi BGP aktif, jalur pelanggan rusak: MPLS di atas DMVPN

Peering sudah aktif berminggu-minggu, jumlah prefiks terlihat benar, tetapi lalu lintas satu pelanggan tetap mengambil jalur jauh atau tidak pernah tiba. Dua hal berbeda sedang dinilai oleh indikator yang sama. Sesi BGP melaporkan bahwa dua peer dapat bertukar pesan melalui koneksi TCP; sesi itu tidak mengatakan apa pun tentang apakah overlay dapat membawa paket berlabel untuk pelanggan tersebut.

Celah itu paling mudah terlihat pada rancangan MPLS di atas DMVPN, tempat jalur hub dan jalur spoke langsung dapat berperilaku berbeda karena alasan yang sama sekali tidak berkaitan dengan peering.

Apa yang sebenarnya dibuktikan sesi

BGP berjalan di atas TCP, jadi setiap peer memerlukan rute ke alamat ujung lain sebelum hal lain dapat terjadi. Pilih loopback sebagai ujung itu dan Anda telah membuat syarat keterjangkauan, bukan jaminan penerusan. Sesi kemudian dapat tetap aktif melalui antarmuka yang tidak akan pernah digunakan lalu lintas pelanggan.

Catat empat fakta di kedua ujung sebelum menarik kesimpulan: alamat sumber sesi, alamat tujuannya, konteks perutean tempat sesi berada, dan antarmuka mana yang akan dipilih kernel atau router untuk pasangan itu. Fakta-fakta itu menggambarkan bidang kendali. Paket pelanggan menambahkan VRF, tumpukan label, dan pemetaan overlay di atasnya.

Empat mekanisme, bukan satu

Dokumentasi Cisco tentang MPLS di atas DMVPN memisahkan bagian-bagiannya dengan jelas. MP-BGP menyebarkan label overlay pelanggan di antara perangkat tepi penyedia. MPLS memakai label itu untuk memilih konteks penerusan sebuah paket. NHRP memetakan alamat overlay ke ujung transport yang dibutuhkan terowongan dinamis. IPsec melindungi jalur peer di tempat yang berlaku.

Salah satu dari keempatnya bisa benar sementara yang lain salah, dan kombinasi itulah yang membawa lalu lintas. Pertukaran rute dapat selesai sementara ikatan label untuk satu VRF hilang, sementara pemetaan NHRP menunjuk alamat transport yang basi, atau sementara terowongan ada tetapi tidak ada kebijakan yang mengizinkan paket dalam. Tak satu pun kondisi itu menjatuhkan sesi.

Bandingkan jalur hub dengan jalur pintas, satu variabel per langkah

Tetapkan hos sumber, hos tujuan, dan VRF, lalu telusuri aliran yang sama dua kali. Pada jalur hub, catat hop berikutnya, label layanan yang mengidentifikasi konteks pelanggan jauh, dan pemetaan overlay-ke-transport yang dipakai. Pada jalur langsung yang dimaksud, catat tiga hal yang sama. Selisih antara kedua daftar itulah gangguannya, atau ketiadaan gangguan.

Jaga aliran tetap konstan selama perbandingan. Mengubah hos sumber, VRF, atau tujuan di antara pengamatan menghasilkan dua cerita yang tidak berhubungan, dan itulah cara paling umum latihan ini menjadi salah.

Simpan uji loopback di kompartemennya sendiri

Ping yang berasal dari loopback router adalah uji yang berguna, dan ia menguji kasus berbeda dari aliran dari hos. Alamat sumber milik router, konteks peruteannya bisa global alih-alih VRF, dan jalur balasan bisa berbeda dari yang akan diambil prefiks pelanggan. Jadi loopback yang menjawab dan aplikasi yang bekerja lewat jalur pintas adalah hasil terpisah, dan hanya yang kedua menggambarkan pelanggan.

Uji keduanya, lalu tandai secara terpisah dalam catatan Anda. Ketika keduanya tidak sepakat, Anda telah mempelajari sesuatu yang spesifik tentang di mana rancangan menyimpang, dan itu lebih dari yang akan pernah dikatakan satu tanda centang hijau.

Klaim versi dan klaim cacat perlu buktinya sendiri

Laporan lapangan kadang menyarankan mengubah mask hos atau alamat sumber BGP, dan laporan semacam itu hanya layak dibaca bersama cacat yang menjadi pokoknya dan rilis yang terpengaruh. Solusi sementara dari satu rilis bukan pernyataan bahwa setiap prefiks /32 tidak didukung arsitektur.

Gunakan dokumentasi yang cocok dengan fase DMVPN, platform, dan rilis Anda, dan ingat bahwa satu bab dapat mencakup beberapa tataan, termasuk FlexVPN. Contoh dari satu tataan tidak berpindah diam-diam ke tataan lain. Pilih ujung sesi untuk rancangan bidang kendali yang benar-benar Anda butuhkan, lalu verifikasi jalur penerusan pelanggan secara terpisah, karena menulis ulang setiap mask loopback bukan pengganti menemukan tugas mana yang gagal.