Mengapa laluan subnet AWS VGW tidak boleh memilih satu terowong VPN

Dua sambungan Site-to-Site VPN berakhir pada satu get laluan persendirian maya dan mengiklankan awalan cawangan yang sama. Jadual laluan subnet menyimpan satu entri untuk awalan itu, menghala ke get laluan, dan tiada medan yang menamakan terowong. Oleh itu keutamaan antara sambungan berlaku di tempat yang konsol tidak melabelnya sebagai penghalaan. Mengetahui lapisan mana yang memiliki keputusan ialah perbezaan antara siap sedia yang berfungsi dan perubahan yang tidak melakukan apa-apa.

Dua lapisan terlibat: laluan VPC yang menyatakan get laluan mana, dan pilihan terowong get laluan itu sendiri. Mengelirukan keduanya menghasilkan suntingan yang kelihatan betul dalam jadual laluan dan tidak pernah menggerakkan satu paket.

Dua lapisan yang kelihatan seperti satu

Laluan subnet menjawab satu soalan: untuk destinasi ini, lampiran mana? Sasarannya ialah get laluan persendirian maya, dan metriknya hanya bersaing dengan laluan lain dalam jadual yang sama. Tiada apa-apa dalam entri itu yang membezakan terowong satu daripada terowong dua, atau sambungan A daripada sambungan B. Awalan yang lebih khusus ialah padanan destinasi yang berbeza, bukan pilihan laluan yang lebih halus.

Get laluan menjawab soalan seterusnya: antara terowong yang dipegangnya untuk awalan itu, yang mana membawa trafik sekarang. Keputusan itu datang daripada kesihatan terowong dan atribut BGP yang diterima daripada get laluan pelanggan, dan ia tidak pernah muncul dalam jadual laluan subnet.

Apa yang sebenarnya dibandingkan oleh VGW

Kesihatan didahulukan. Terowong yang mati, atau sesi BGP yang tidak naik, kalah sebelum apa-apa atribut diperiksa. Itulah sebabnya menambah laluan di hadapan pada sambungan yang sudah gagal tidak mengubah apa-apa.

Antara laluan yang layak untuk awalan yang sama, AWS lebih suka AS_PATH yang lebih pendek. Apabila dua laluan sama panjang, ia membandingkan MED, tertakluk kepada syarat berdokumen tentang AS pertama dalam laluan itu. Baca susunan yang diterbitkan dan bukan versi cerita rakyat, kerana cerita rakyat biasanya menggugurkan langkah kesihatan dan pengecualian laluan statik. Satu akibat: tiga penambahan di hadapan pada sambungan sandaran menjadikan yang utama benar-benar lebih pendek, dan itulah cara biasa menyatakan keutamaan.

Menambah di hadapan, dan bila ia tidak melakukan apa-apa

Penambahan di hadapan berlaku dalam pengiklanan keluar get laluan pelanggan, bukan di dalam AWS. Anda menambah ASN anda sendiri dua atau tiga kali pada awalan yang anda mahu AWS elakkan, dan AWS kemudian melihat laluan yang lebih panjang untuk sambungan itu. Sambungan utama mengekalkan pengiklanan tanpa penambahan. Jika kedua-dua sambungan mengiklankan daripada ASN yang sama dengan bilangan penambahan yang sama, anda tidak menyatakan apa-apa keutamaan.

Periksa laluan yang diterima di sebelah AWS selepas perubahan. Penambahan yang tidak pernah meninggalkan peranti pelanggan kelihatan sama seperti yang diabaikan oleh AWS.

Laluan statik mengabaikan keseluruhan hujah

Jika sambungan menggunakan penghalaan statik, tiada AS_PATH untuk dipanjangkan. AWS mendokumenkan laluan VPN statik sebagai lebih diutamakan daripada laluan yang dipelajari BGP untuk awalan yang sama, jadi reka bentuk bercampur tidak berkelakuan seperti yang sepenuhnya dinamik. Tentukan jenis penghalaan dahulu, kemudian pilih mekanisme keutamaan yang wujud untuknya.

Dengan dua sambungan statik yang mengiklankan awalan yang sama, tuas yang berguna ialah awalan: iklankan julat yang lebih khusus pada sambungan yang ingin digunakan, dan terima bahawa anda mengubah destinasi mana yang sepadan dan bukan laluan mana yang menang.

Mengapa get laluan transit ialah jawapan yang berbeza

Get laluan transit menyokong berbilang laluan kos sama merentas lampiran VPN, jadi dua sambungan boleh berkongsi trafik dan bukannya satu berdiri siap sedia. Reka bentuk itu mempunyai permukaan kegagalan yang berbeza: aliran tersebar merentas terowong, dan satu terowong yang jatuh hanya menggerakkan sebahagian beban. Menyalin resipi VGW ke get laluan transit, atau sebaliknya, mencipta jangkaan yang tidak dipenuhi oleh mana-mana platform.

Pilih model sebelum mekanisme: aktif dan siap sedia dengan keutamaan yang dipaku, atau aktif dan aktif dengan ECMP.

Apa yang perlu disahkan selepas anda menetapkannya

Sahkan empat perkara mengikut urutan. Jadual subnet masih menyelesaikan awalan ke get laluan yang dimaksudkan. Get laluan menyenaraikan kedua-dua terowong sebagai naik. AS_PATH yang diterima pada sambungan yang ingin dielakkan lebih panjang daripada yang lain. Dan aliran sebenar daripada instans dalam subnet itu melalui terowong yang dijangka, diperhatikan pada kedua-dua hujung dan bukan disimpulkan daripada status hijau.

Kemudian jalankan ujian failover yang diluluskan dan lihat laluan yang terselamat membawa perkhidmatan itu. Keutamaan yang hanya wujud dalam perbezaan konfigurasi belum lagi menjadi keutamaan.