Pendalaman perutean Virtual WAN

Azure Virtual WAN adalah solusi jaringan yang memungkinkan pembuatan topologi jaringan canggih dengan mudah: ini mencakup perutean di seluruh wilayah Azure antara Azure VNets dan lokasi lokal melalui VPN Titik-ke-Situs, VPN Situs-ke-Situs, ExpressRoute dan appliance SDWAN terintegrasi, termasuk opsi untuk mengamankan lalu lintas. Dalam sebagian besar skenario, Anda tidak diharuskan memiliki pengetahuan mendalam tentang cara kerja perutean internal Virtual WAN, tetapi dalam situasi tertentu dapat berguna untuk memahami konsep perutean Virtual WAN.

Dokumen ini mengeksplorasi sampel skenario Virtual WAN yang menjelaskan beberapa perilaku yang mungkin dihadapi organisasi saat menghubungkan VNet dan cabang mereka di jaringan yang kompleks. Skenario yang ditunjukkan dalam artikel ini sama sekali bukan rekomendasi desain, mereka hanyalah contoh topologi yang dirancang untuk menunjukkan fungsionalitas Virtual WAN tertentu.

Skenario 1: topologi dengan preferensi perutean default

Skenario pertama dalam artikel ini menganalisis topologi dengan dua hub Virtual WAN, ExpressRoute, VPN, dan konektivitas SDWAN. Di setiap hub, ada VNet yang terhubung langsung (VNet 11 dan 21) dan secara tidak langsung melalui NVA (VNet 121, 122, 221, dan 222). VNet 12 bertukar informasi perutean dengan hub 1 melalui BGP (lihat peering BGP dengan hub virtual), dan VNet 22 memiliki rute statis yang dikonfigurasi, sehingga perbedaan antara kedua opsi dapat ditampilkan.

Di setiap hub, appliance VPN dan SDWAN melayani tujuan ganda: di satu sisi mereka mengiklankan awalan individu mereka sendiri (10.4.1.0/24 melalui VPN di hub 1 dan 10.5.3.0/24 melalui SDWAN di hub 2), dan di sisi lain mereka mengiklankan awalan yang sama dengan sirkuit ExpressRoute di wilayah yang sama (10.4.2.0/24 di hub 1 dan 10.5.2.0/24 di hub 2). Perbedaan ini akan digunakan untuk menunjukkan cara kerja preferensi perutean hub Virtual WAN.

Semua koneksi VNet dan cabang dikaitkan juga disebarluaskan ke tabel rute default. Meskipun hub diamankan (ada Azure Firewall yang disebarkan di setiap hub), hub tersebut tidak dikonfigurasi untuk mengamankan lalu lintas privat atau Internet. Melakukannya akan mengakibatkan semua koneksi menyebar ke None tabel rute, yang akan menghapus semua rute non-statis dari Default tabel rute dan mengalahkan tujuan artikel ini karena bilah rute efektif di portal akan hampir kosong (kecuali untuk rute statis untuk mengirim lalu lintas ke Azure Firewall).

Penting

Diagram sebelumnya menunjukkan dua hub virtual aman, topologi ini didukung dengan Niat Perutean. Untuk informasi selengkapnya, lihat Cara mengonfigurasi niat perutean dan kebijakan perutean Hub Virtual WAN.

Di luar kotak, hub Virtual WAN saling bertukar informasi sehingga komunikasi di seluruh wilayah diaktifkan. Anda dapat memeriksa rute efektif dalam tabel rute Virtual WAN: misalnya, gambar berikut menunjukkan rute efektif di hub 1:

Rute efektif ini kemudian akan diiklankan oleh Virtual WAN ke cabang, dan akan menyuntikkannya ke VNet yang terhubung ke hub virtual, membuat penggunaan Rute yang Ditentukan Pengguna tidak perlu. Saat memeriksa rute efektif di hub virtual, bidang "Jenis Hop Berikutnya" dan "Asal" akan menunjukkan dari mana rute berasal. Misalnya, Jenis Hop Berikutnya dari "Koneksi Virtual Network" menunjukkan bahwa awalan ditentukan dalam VNet yang terhubung langsung ke Virtual WAN (VNet 11 dan 12 di cuplikan layar sebelumnya)

NVA di VNet 12 menyuntikkan rute 10.1.20.0/22 melalui BGP, sebagai "HubBgp Koneksi ion" Tipe Hop Berikutnya menyiratkan (lihat BGP Peering dengan Hub Virtual). Rute ringkasan ini mencakup VNet 121 spoke tidak langsung (10.1.21.0/24) dan VNet 122 (10.1.22.0/24). VNet dan cabang di hub jarak jauh terlihat dengan hop berikutnya hub2, serta dapat dilihat di jalur AS bahwa Nomor Sistem Otonom 65520 telah didahului dua kali ke rute interhub ini.

Di hub 2 ada SDWAN Network Virtual Appliance terintegrasi. Untuk detail selengkapnya tentang NVA yang didukung untuk integrasi ini, kunjungi Tentang NVA di hub Virtual WAN. Perhatikan bahwa rute ke cabang 10.5.3.0/24 SDWAN memiliki hop berikutnya VPN_S2S_Gateway. Jenis hop berikutnya ini dapat menunjukkan hari ini baik rute yang berasal dari Azure Virtual Network Gateway atau dari NVA yang terintegrasi di hub.

Di hub 2, rute untuk 10.2.20.0/22 ke spoke tidak langsung VNet 221 (10.2.21.0/24) dan VNet 222 (10.2.22.0/24) diinstal sebagai rute statis, seperti yang ditunjukkan oleh asal defaultRouteTable. Jika Anda memeriksa rute efektif untuk hub 1, rute tersebut tidak ada. Alasannya adalah karena rute statis tidak disebarluaskan melalui BGP, tetapi perlu dikonfigurasi di setiap hub. Oleh karena itu, rute statis diperlukan di hub 1 untuk menyediakan konektivitas antara VNet dan cabang di hub 1 ke spoke tidak langsung di hub 2 (VNet 221 dan 222):

Setelah menambahkan rute statis, hub 1 juga akan berisi 10.2.20.0/22 rute:

Skenario 2: Preferensi perutean hub dan Jangkauan Global

Bahkan jika hub 1 mengetahui awalan ExpressRoute dari sirkuit 2 (10.5.2.0/24) dan hub 2 mengetahui awalan ExpressRoute dari sirkuit 1 (10.4.2.0/24), rute ExpressRoute dari wilayah jarak jauh tidak diiklankan kembali ke tautan ExpressRoute lokal. Akibatnya, ExpressRoute Global Reach diperlukan untuk lokasi ExpressRoute untuk berkomunikasi satu sama lain:

Penting

Diagram sebelumnya menunjukkan dua hub virtual aman, topologi ini didukung dengan Niat Perutean. Untuk informasi selengkapnya, lihat Cara mengonfigurasi niat perutean dan kebijakan perutean Hub Virtual WAN.

Seperti yang dijelaskan dalam preferensi perutean hub virtual, Virtual WAN mendukung rute yang berasal dari ExpressRoute per default. Karena rute diiklankan dari hub 1 ke sirkuit ExpressRoute 1, dari sirkuit ExpressRoute 1 ke sirkuit 2, dan dari sirkuit ExpressRoute 2 ke hub 2 (dan sebaliknya), hub virtual lebih memilih jalur ini daripada tautan inter hub yang lebih langsung sekarang. Rute efektif di hub 1 menunjukkan hal ini:

Seperti yang Anda lihat di rute, ExpressRoute Global Reach telah menambahkan Nomor Sistem Otonom ExpressRoute (12076) beberapa kali sebelum mengirim rute kembali ke Azure untuk membuat rute ini kurang disukai. Namun, prioritas perutean hub default Virtual WAN ExpressRoute mengabaikan panjang jalur AS saat mengambil keputusan perutean.

Rute efektif di hub 2 akan serupa dengan:

Preferensi perutean dapat diubah ke VPN atau AS-Path seperti yang dijelaskan di preferensi perutean hub virtual. Misalnya, Anda dapat mengatur preferensi ke VPN seperti yang ditunjukkan pada gambar ini:

Dengan preferensi perutean hub VPN, rute efektif di hub 1 terlihat seperti ini:

Gambar sebelumnya menunjukkan bahwa rute untuk 10.4.2.0/24 sekarang memiliki hop berikutnya VPN_S2S_Gateway, sementara dengan preferensi perutean default ExpressRoute, sebelumnya adalah ExpressRouteGateway. Namun, di hub 2 rute ke 10.5.2.0/24 akan tetap muncul dengan hop berikutnya ExpressRoute, karena dalam hal ini rute alternatif tidak berasal dari VPN Gateway tetapi dari NVA yang terintegrasi di hub:

Namun, lalu lintas antar hub masih lebih memilih rute yang datang melalui ExpressRoute. Untuk menggunakan koneksi langsung yang lebih efisien antara hub virtual, preferensi rute dapat diatur ke "Jalur AS" di kedua hub:

Sekarang rute untuk spoke dan cabang jarak jauh di hub 1 akan memiliki hop berikutnya Remote Hub seperti yang dimaksudkan:

Anda dapat melihat bahwa awalan IP untuk hub 2 (192.168.2.0/23) masih terlihat dapat dijangkau melalui tautan Jangkauan Global, tetapi ini seharusnya tidak memengaruhi lalu lintas karena seharusnya tidak ada lalu lintas apa pun yang dialamatkan ke perangkat di hub 2. Rute ini mungkin menjadi masalah, jika ada NVA di kedua hub yang membangun terowongan SDWAN antara satu sama lain.

Namun, perhatikan bahwa 10.4.2.0/24 sekarang lebih disukai daripada VPN Gateway. Hal ini bisa terjadi jika rute yang diiklankan melalui VPN memiliki jalur AS yang lebih pendek daripada rute yang diiklankan melalui ExpressRoute. Setelah mengonfigurasi perangkat VPN lokal untuk menambahkan Nomor Sistem Otonomnya (65501) ke rute VPN untuk membuat yang kurang lebih disukai, hub 1 sekarang memilih ExpressRoute sebagai hop berikutnya untuk 10.4.2.0/24:

Hub 2 akan menunjukkan tabel serupa untuk rute efektif, di mana VNet dan cabang di hub lain sekarang muncul dengan Remote Hub sebagai hop berikutnya:

Skenario 3: Menyambungkan silang sirkuit ExpressRoute ke kedua hub

Untuk menambahkan tautan langsung antara wilayah Azure dan lokasi lokal yang terhubung melalui ExpressRoute, sering kali diinginkan untuk menghubungkan satu sirkuit ExpressRoute ke beberapa hub Virtual WAN dalam topologi beberapa kali digambarkan sebagai "dasi busur", seperti yang ditunjukkan topologi berikut:

Penting

Diagram sebelumnya menunjukkan dua hub virtual aman, topologi ini didukung dengan Niat Perutean. Untuk informasi selengkapnya, lihat Cara mengonfigurasi niat perutean dan kebijakan perutean Hub Virtual WAN.

Virtual WAN menunjukkan bahwa kedua sirkuit terhubung ke kedua hub:

Kembali ke preferensi perutean hub default ExpressRoute, rute ke cabang jarak jauh dan VNet di hub 1 akan menampilkan lagi ExpressRoute sebagai hop berikutnya. Meskipun kali ini alasannya bukan Jangkauan Global, tetapi fakta bahwa sirkuit ExpressRoute memantul kembali iklan rute yang mereka dapatkan dari satu hub ke hub lainnya. Misalnya, rute efektif hub 1 dengan preferensi perutean hub ExpressRoute adalah sebagai berikut:

Mengubah kembali preferensi perutean hub lagi ke Jalur AS mengembalikan rute antar hub ke jalur optimal menggunakan koneksi langsung antara hub 1 dan 2:

Langkah berikutnya

Untuk informasi selengkapnya tentang Virtual WAN, lihat:

• FAQ Azure Virtual WAN