Mengapa rute subnet AWS VGW tidak bisa memilih satu terowongan VPN

Dua koneksi Site-to-Site VPN berakhir pada satu gateway privat virtual dan mengiklankan prefiks cabang yang sama. Tabel rute subnet menyimpan satu entri untuk prefiks itu, menunjuk ke gateway, dan tidak ada bidang yang menyebut terowongan. Karena itu preferensi antar koneksi terjadi di tempat yang tidak dilabeli konsol sebagai perutean. Mengetahui lapisan mana yang memiliki keputusan adalah perbedaan antara siaga yang berfungsi dan perubahan yang tidak melakukan apa pun.

Ada dua lapisan yang bermain: rute VPC yang menyebut gateway mana, dan pilihan terowongan dari gateway itu sendiri. Mencampuradukkan keduanya menghasilkan suntingan yang terlihat benar di tabel rute dan tidak pernah memindahkan paket.

Dua lapisan yang tampak seperti satu

Rute subnet menjawab satu pertanyaan: untuk tujuan ini, lampiran mana? Targetnya adalah gateway privat virtual, dan metriknya hanya bersaing dengan rute lain di tabel yang sama. Tidak ada apa pun dalam entri itu yang membedakan terowongan satu dari terowongan dua, atau koneksi A dari koneksi B. Prefiks yang lebih spesifik adalah kecocokan tujuan yang berbeda, bukan pilihan jalur yang lebih halus.

Gateway menjawab pertanyaan berikutnya: di antara terowongan yang dipegangnya untuk prefiks itu, mana yang membawa lalu lintas sekarang. Keputusan itu berasal dari kesehatan terowongan dan atribut BGP yang diterima dari gateway pelanggan, dan tidak pernah muncul di tabel rute subnet.

Apa yang sebenarnya dibandingkan VGW

Kesehatan lebih dulu. Terowongan yang mati, atau sesi BGP yang belum naik, kalah sebelum atribut apa pun diperiksa. Itulah sebabnya menambahkan jalur di depan pada koneksi yang sudah gagal tidak mengubah apa pun.

Di antara jalur yang memenuhi syarat untuk prefiks yang sama, AWS lebih memilih AS_PATH yang lebih pendek. Bila dua jalur sama panjang, ia membandingkan MED, dengan tunduk pada kondisi terdokumentasi tentang AS pertama di jalur itu. Bacalah urutan yang diterbitkan, bukan versi cerita rakyat, karena cerita rakyat biasanya menghilangkan langkah kesehatan dan pengecualian rute statis. Satu konsekuensi: tiga penambahan di depan pada koneksi cadangan membuat yang primer benar-benar lebih pendek, dan itulah cara biasa menyatakan preferensi.

Menambahkan di depan, dan kapan tidak melakukan apa pun

Penambahan di depan terjadi pada iklan keluar dari gateway pelanggan, bukan di dalam AWS. Anda menambahkan ASN Anda sendiri dua atau tiga kali ke prefiks yang ingin dihindari AWS, lalu AWS melihat jalur yang lebih panjang untuk koneksi itu. Koneksi primer mempertahankan iklan tanpa penambahan. Jika kedua koneksi mengiklankan dari ASN yang sama dengan jumlah penambahan yang sama, Anda tidak menyatakan preferensi apa pun.

Periksa jalur yang diterima di sisi AWS setelah perubahan. Penambahan yang tidak pernah meninggalkan perangkat pelanggan terlihat persis seperti yang diabaikan AWS.

Rute statis mengabaikan seluruh argumen

Jika koneksi memakai perutean statis, tidak ada AS_PATH untuk dipanjangkan. AWS mendokumentasikan rute VPN statis sebagai lebih diutamakan daripada rute yang dipelajari BGP untuk prefiks yang sama, jadi desain campuran tidak berperilaku seperti desain yang sepenuhnya dinamis. Putuskan jenis perutean lebih dulu, lalu pilih mekanisme preferensi yang ada untuknya.

Dengan dua koneksi statis yang mengiklankan prefiks yang sama, tuas yang berguna adalah prefiks: iklankan rentang yang lebih spesifik pada koneksi yang ingin dipakai, dan terima bahwa Anda mengubah tujuan mana yang cocok, bukan jalur mana yang menang.

Mengapa gateway transit adalah jawaban yang berbeda

Gateway transit mendukung multipath berbiaya sama di seluruh lampiran VPN, sehingga dua koneksi dapat berbagi lalu lintas alih-alih satu berjaga. Desain itu memiliki permukaan kegagalan yang berbeda: aliran menyebar di seluruh terowongan, dan satu terowongan mati hanya memindahkan sebagian beban. Menyalin resep VGW ke gateway transit, atau sebaliknya, menciptakan harapan yang tidak dipenuhi salah satu platform.

Pilih model sebelum mekanisme: aktif dan siaga dengan preferensi yang dipatok, atau aktif dan aktif dengan ECMP.

Apa yang harus diverifikasi setelah Anda mengaturnya

Konfirmasikan empat hal secara berurutan. Tabel subnet masih menyelesaikan prefiks ke gateway yang dimaksud. Gateway mencantumkan kedua terowongan sebagai aktif. AS_PATH yang diterima pada koneksi yang ingin dihindari lebih panjang daripada yang lain. Dan aliran nyata dari sebuah instans di subnet itu melewati terowongan yang diharapkan, diamati di kedua ujungnya alih-alih disimpulkan dari status hijau.

Lalu jalankan uji failover yang disetujui dan lihat jalur yang bertahan membawa layanan. Preferensi yang hanya ada dalam diff konfigurasi belum menjadi preferensi.