Gateway cabang menampilkan prefiks cloud di tabel BGP-nya, sesi ke penyedia terjalin, dan tetap saja permintaan pengguna ke prefiks itu keluar melalui antarmuka yang salah. Tidak ada yang rusak seperti yang disiratkan pemantauan, karena “BGP mempelajarinya” adalah pernyataan tentang bidang kendali. Di antara tabel itu dan paket ada empat transisi terpisah, dan aliran berhenti tepat di salah satunya. Telusuri gerbang secara berurutan dan berhenti di gerbang pertama yang gagal.

Gerbang pertama: apa yang benar-benar dikirim tetangga

Mulailah dari prefiks sebagaimana diterima, bukan sebagaimana diringkas. Cari jaringan dan mask yang tepat di tabel BGP dan catat hop berikutnya, jalur AS, serta komunitas apa pun yang mungkin dicocokkan oleh kebijakan impor. Rute ringkasan di dasbor dapat menyembunyikan fakta bahwa prefiks tertentu tidak pernah diterima.

Kebijakan impor adalah tempat biasa sebuah rute menghilang tanpa kesalahan. Daftar prefiks, filter komunitas, atau peta rute masuk dapat membuang pembaruan sementara sesi tetap naik dan sehat, itulah sebabnya lampu tetangga hijau begitu sedikit membuktikan. Tidak adanya baris log bukan berarti tidak adanya keputusan. Biasanya berarti keputusan diambil diam-diam, persis seperti yang dikonfigurasi.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Baca keluaran dalam urutan itu. Dua perintah pertama memberi tahu apakah informasi tiba dan apa yang diklaim rekan dikirim; dua perintah terakhir memberi tahu apakah ada yang mencapai tabel perutean dan penerusan. Prefiks yang ada di perintah pertama dan tidak ada di perintah ketiga adalah masalah pemilihan atau pemasangan, bukan masalah konektivitas.

Gerbang kedua: pemilihan, lalu pemasangan

BGP memilih jalur terbaik, dan jalur yang dipilih tidak otomatis dipasang. Hop berikutnya harus diselesaikan, dan sumber rute lain mungkin sudah memiliki prefiks itu dengan jarak administratif yang lebih baik. Rute statis sisa migrasi akan dengan mudah mengalahkan jalur BGP yang sah dan mengirim lalu lintas ke tempat lain.

RFC 4271 memisahkan tiga gagasan: apa yang dikirim rekan, apa yang dipilih pembicara ini sebagai terbaik, dan apa yang akan diumumkannya selanjutnya. Itu peran konseptual, bukan tiga basis data fisik yang harus diekspos vendor, tetapi justru pemisahan itulah yang membuat “itu ada di BGP” menjadi jawaban yang tidak lengkap.

Periksa juga konteks perutean mana yang Anda baca. Rute yang dipasang di VRF yang tidak memuat antarmuka pengguna tidak terlihat oleh paket pengguna itu, dan tabelnya tampak benar sepanjang waktu.

Gerbang ketiga: pencarian yang berlaku untuk aliran ini

Sekarang berhenti bertanya tentang rute dan mulailah bertanya tentang paket. Catat alamat sumber pengguna, tujuan, protokol, port, dan antarmuka masuk, karena masing-masing dapat memilih kebijakan berbeda. Lalu lihat pencarian yang berlaku untuk kombinasi itu alih-alih tabel perutean umum.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Prefiks yang lebih spesifik adalah kejutan paling umum di sini, dan rute kebijakan adalah yang kedua. Keduanya mengalahkan agregat yang Anda lihat, dan keduanya tidak terlihat dalam ringkasan tabel BGP.

Ping yang berasal dari gateway itu sendiri bukan bukti tentang sesi pengguna. Alamat sumber berbeda, jalur kebijakan berbeda, dan sering hasil berbeda. Uji dengan sumber yang sama dengan yang dipakai aplikasi, atau terimalah bahwa uji itu menjawab pertanyaan lain.

Gerbang keempat: separuh jalur yang jauh

Jika pencarian lokal memang memilih terowongan, paket tetap harus diterima kebijakan perlindungan, diizinkan aturan penerusan, dan dijawab oleh sesuatu di sisi seberang. ACL kripto yang tidak mencakup pasangan alamat akan membuang lalu lintas sementara terowongan melaporkan dirinya naik, yang menghasilkan batas waktu tak terbedakan dari kegagalan perutean.

Jalur kembali sama pentingnya dengan jalur keluar. Sisi cloud harus tahu cara mencapai sumber cabang, baik melalui rute maupun melalui terjemahan yang Anda konfigurasikan dengan sengaja. Jalur kembali asimetris umum pada desain yang hanya diuji dari satu arah.

Korelasikan koneksi berizin yang baru dengan tiga pengamatan: kebijakan lokal yang cocok, penghitung terowongan yang bergerak, dan penerimaan di sisi jauh tempat itu terlihat. Jika penghitung tidak bergerak, paket tidak pernah masuk terowongan, apa pun kata tabel rute. Jika bergerak dan tidak ada yang tiba, sisi jauh membuang atau salah merutekannya. Kedua hasil itu mengarah ke tim yang sama sekali berbeda.

Namai transisi yang gagal

Tuliskan hasilnya sebagai salah satu dari lima keadaan: tidak diterima, tidak disetujui kebijakan, tidak dipilih, tidak dipasang, atau tidak dicocokkan oleh aliran ini. Tambahkan yang keenam untuk kasus jalur lokal benar dan ujung jauh tidak dapat menjawab. Kalimat itulah hasil serahannya, dan jauh lebih berguna daripada tangkapan layar tetangga yang terjalin.

Simpan juga uji negatif dalam rencana penerimaan: tujuan yang tidak boleh melewati terowongan, diverifikasi setelah perubahan. Daftar periksa yang hanya membuktikan jalur bahagia tidak akan menangkap aturan kebijakan luas yang ditambahkan seseorang pada jendela pemeliharaan berikutnya.

Artikel terkait