Mengapa sesi BGP Anda tidak muncul di tabel rute VPC

Cerita yang sering diulang adalah bahwa daemon routing pada perangkat VPN EC2 akan mengajari VPC prefiks jaraknya begitu BGP naik. Separuh dari itu benar. Sesi naik, dan tidak ada yang berubah di tabel rute VPC karenanya, itulah sebabnya gejala pertama biasanya berupa subnet yang diam-diam membuang lalu lintas ke lubang hitam.

Dua hal berbeda dicampuradukkan di sini: peering dengan route server, dan memasang rute ke dalam tabel.

Mitos: naikkan BGP dan VPC akan mempelajari prefiks

BGP adalah percakapan antara dua pembicara, dan dalam desain ini pembicaranya adalah daemon routing di perangkat Anda dan endpoint VPC Route Server yang ditempatkan AWS di subnet milik Anda. Percakapan itu membawa prefiks. Ia tidak menyentuh tabel rute subnet beban kerja Anda, karena tabel itu hanya belajar melalui propagasi yang harus diaktifkan pada masing-masing. Sampai itu terjadi, jaringan VPC tidak tahu apa pun tentang apa yang diketahui perangkat.

Langkah penyiapannya terpisah karena suatu alasan: kaitkan, buat endpoint, lakukan peering, lalu aktifkan propagasi.

Route Server adalah bidang kendali, bukan terowongan

Route Server tidak mengenkripsi, meneruskan, atau memeriksa satu paket pun. Ia ada untuk bertukar BGP dengan perangkat dan menyerahkan prefiks yang dihasilkan ke tabel rute yang dikonfigurasi untuk menerimanya. Bidang data tidak berubah: paket tetap keluar melalui antarmuka jaringan perangkat, melewati VPN-nya, dan kembali melalui jalur yang sama.

Itu berarti pemeriksaan sumber dan tujuan pada instans penerus masih penting, karena instans itu sekarang meneruskan lalu lintas yang dialamatkan ke orang lain.

Grup keamanan dan kontrol subnet juga tetap berlaku untuk aliran yang diteruskan. Route Server tidak akan membuat perangkat yang membuang lalu lintas meneruskannya, dan tidak akan memperbaiki rute balik yang hilang di sisi jauh.

Propagasi bersifat per tabel rute, bukan per VPC

Mengaitkan route server dengan VPC dan mengaktifkan propagasi pada tabel rute adalah dua keputusan, dan hanya yang kedua mengubah apa yang dilakukan subnet. VPC dengan enam tabel rute dapat menerima prefiks yang dipropagasikan di satu tabel dan tidak di lima lainnya, yang justru tepat untuk subnet hub dan justru itulah yang menghasilkan hasil membingungkan «berfungsi separuh». Bahkan ketika propagasi aktif, rute pesaing bisa menang, karena pemilihan rute VPC mengutamakan prefiks terpanjang dan, pada panjang yang sama, mengutamakan rute statis di atas rute yang dipropagasikan. Preferensi itu diterapkan secara diam-diam.

Periksa tabel efektif untuk subnet tertentu alih-alih daftar prefiks yang diumumkan perangkat. API menjawab pertanyaan itu secara langsung: aws ec2 associate-route-server dan aws ec2 enable-route-server-propagation --route-table-id <id> adalah dua langkah yang orang lupakan, dan aws ec2 describe-route-tables --route-table-ids <id> menunjukkan apakah prefiks tiba sebagai entri route server sama sekali.

Perangkat tetap membawa setiap paket

Mengumumkan keterjangkauan tidak sama dengan memilikinya. Sesi BGP bisa tetap terbentuk sementara VPN perangkat mati, dan pengumuman statis yang tidak pernah berubah terus menarik lalu lintas ke jalur yang mati. Route Server mendukung deteksi kegagalan seperti BFD, tetapi itu menguji keaktifan peer, bukan kesehatan semua yang ada di belakangnya.

Ikat pengumuman ke rute jarak jauh yang sebenarnya: umumkan prefiks saat terowongan dan jaringan jarak jauh aktif, dan tarik kembali saat tidak.

Tarik kembali sebuah prefiks dan lihat apa yang terjadi

Uji secara bertahap, dan jadikan tahap terakhir sebagai penghapusan. Pastikan pengumuman tiba, prefiks muncul di setiap tabel yang dimaksud, perangkat adalah hop berikutnya, penerusan melewati terowongan aktif, dan ujung jauh merespons. Lalu tarik kembali prefiks uji, atau tutup terowongan yang disetujui, dan amati apakah lalu lintas berpindah ke tempat yang dikatakan desain. Catat tabel sebelum dan sesudah selama uji masih terbuka.

Memindahkan rute ke perangkat kedua tidak memindahkan sesi yang dibawanya, karena status NAT dan firewall tetap di perangkat pertama.

Untuk kumpulan tetap selusin prefiks, rute statis di tabel VPC tetap menjadi jawaban yang lebih murah. Route Server layak mendapat tempatnya ketika daftar prefiks benar-benar berubah dan kebijakan penarikan adalah sesuatu yang dapat Anda jelaskan kepada orang yang sedang siaga.