Integrasi SDWAN dengan topologi jaringan hub-and-spoke Azure

Azure ExpressRoute

Azure VPN Gateway

Microsoft Azure Virtual Network

Artikel ini ditujukan untuk arsitek jaringan yang ingin merancang Wide Area Networks (SD-WAN) yang ditentukan perangkat lunak untuk menghubungkan fasilitas lokal satu sama lain dan dengan Azure. Ini menjelaskan arsitektur yang memungkinkan pelanggan Azure menggunakan investasi yang ada di platform, dengan membangun overlay SD-WAN global yang efisien di atas tulang punggung Microsoft.

Skenario yang berlaku

Rekomendasi dalam artikel ini adalah vendor-agnostik dan berlaku untuk teknologi non-Microsoft SD-WAN yang memenuhi dua prasyarat dasar:

• Mengandalkan protokol penerowongan yang menggunakan Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP) sebagai transportasi yang mendasarinya, seperti menjadi IPsec ESP mode terowongan dengan NAT-Traversal.
• Dukungan Border Gateway Protocol (BGP) v4 untuk pertukaran rute dengan entitas eksternal. Tidak ada asumsi yang dibuat pada protokol perutean yang digunakan oleh perangkat non-Microsoft SD-WAN untuk bertukar informasi perutean antara satu sama lain.

Pelanggan yang mematuhi rekomendasi ini dapat menggunakan teknologi pilihan SD-WAN mereka untuk mencapai tujuan berikut:

• Integrasikan produk SD-WAN di hub Azure dan jaringan spoke yang ada, dengan mengotomatiskan pertukaran rute antara Perangkat Azure Virtual Network dan SD-WAN.
• Optimalkan konektivitas (baik ke Azure maupun pusat data lokal) untuk cabang dengan breakout internet lokal. Jangkauan backbone Microsoft, dikombinasikan dengan kapasitas, ketahanan, dan kebijakan perutean "cold potato" menunjukkan bahwa itu dapat digunakan sebagai underlay berkinerja tinggi untuk SD-WAN global.
• Gunakan backbone Microsoft untuk semua lalu lintas Azure-ke-Azure (lintas wilayah dan geografi silang).
• Gunakan jaringan Multi-Protocol-Label-Switching (MPLS) yang ada sebagai underlay berkinerja tinggi. Ini juga dapat digunakan untuk menggantikan jaringan MPLS yang ada dalam pendekatan bertahas yang meminimalkan efek pada bisnis.

Bagian berikut mengasumsikan bahwa pembaca terbiasa dengan dasar-dasar paradigmaSD-WAN dan dengan arsitektur backbone Microsoft. Backbone Microsoft menghubungkan wilayah Azure satu sama lain dan dengan internet publik.

Sistem

Organisasi dengan kehadiran global dan jejak Azure multi-wilayah biasanya menggunakan kombinasi layanan konektivitas untuk mengimplementasikan jaringan perusahaan mereka dan untuk terhubung ke backbone Microsoft:

• Layanan konektivitas khusus, seperti MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN), dapat digunakan di situs terbesar, seperti pusat data atau kantor pusat.
• Situs besar dapat mencakup konektivitas khusus ke tulang punggung Microsoft melalui sirkuit ExpressRoute, menggunakan salah satu model konektivitas yang didukung. Lebih khusus lagi, situs dapat menggunakan sirkuit titik-ke-titik khusus untuk terhubung ke lokasi peering ExpressRoute terdekat. Atau dapat menerapkan MPLS IPVPN-nya untuk mengakses sirkuit ExpressRoute yang disediakan oleh operator MPLS.
• Kantor cabang yang hanya memiliki konektivitas internet mungkin menggunakan VPN IPsec untuk terhubung ke pusat data lokal terdekat dan menggunakan koneksi ExpressRoute pusat data tersebut untuk mengakses sumber daya Azure. Atau mereka mungkin menggunakan VPN IPsec untuk langsung terhubung ke hub Azure dan jaringan spoke.

Proyek SD-WAN dapat memiliki cakupan yang berbeda dalam hal layanan jaringan tradisional mana yang ingin mereka ganti. Beberapa organisasi mungkin ingin tetap berpegang pada tautan khusus atau MPLS untuk fasilitas besar dan menyebarkan SD-WAN hanya untuk menggantiKAN VPN IPsec berbasis internet warisan di situs kecil. Organisasi lain mungkin ingin memperluas SD-WAN mereka ke situs yang terhubung dengan MPLS dan menggunakan jaringan MPLS yang ada sebagai underlay berkinerja tinggi. Akhirnya, beberapa organisasi mungkin ingin menutup IPVPN MPLS mereka. atau layanan konektivitas khusus apa pun, untuk merangkul paradigma SD-WAN. Dengan cara ini, mereka dapat membangun seluruh jaringan perusahaan mereka sebagai overlay logis di atas underlay publik atau bersama (internet publik dan backbone Microsoft).

Arsitektur yang dijelaskan dalam artikel ini mendukung semua cakupan yang tercantum sebelumnya dan didasarkan pada prinsip-prinsip berikut:

• Perangkat SD-WAN disebarkan sebagai Network Virtual Appliances (NVA) di setiap hub wilayah Azure dan jaringan spoke dan dikonfigurasi sebagai hub SD-WAN yang mengakhiri terowongan dari situs lokal.
• Perangkat SD-WAN di Azure dikonfigurasi untuk membuat terowongan satu sama lain, sehingga membuat overlay hub-ke-hub yang sepenuhnya bertaut yang dapat secara efisien mengangkut lalu lintas di antara wilayah Azure, dan menyampaikan lalu lintas antara situs lokal yang jauh secara geografis, di atas backbone Microsoft.
• Perangkat SD-WAN disebarkan di semua situs lokal yang dicakup oleh solusi SD-WAN dan dikonfigurasi untuk membuat terowongan ke NVA SD-WAN di wilayah Azure terdekat. Situs yang berbeda dapat menggunakan layanan transportasi yang berbeda sebagai underlay untuk terowongan, seperti internet publik, konektivitas ExpressRoute, dan sebagainya.
• Lalu lintas dari situs ke tujuan apa pun, baik di Azure atau di situs lokal lain, dirutekan ke NVA SD-WAN di wilayah Azure terdekat. Kemudian merutekan melalui overlay hub-to-hub.

Produk SD-WAN dapat menggunakan protokol dan fitur eksklusif untuk mendeteksi, setelah dibuat secara dinamis, terowongan langsung antara dua situs dapat memberikan performa yang lebih baik daripada menyampaikan lalu lintas melalui NVA SD-WAN di Azure.

Arsitektur tingkat tinggi dari SD-WAN global yang menggunakan backbone Microsoft, internet publik, dan koneksi ER khusus sebagai underlay ditampilkan dalam gambar berikut.

Gambar 1: Arsitektur tingkat tinggi dari SD-WAN global yang menggunakan backbone Microsoft, internet publik, dan koneksi ER khusus sebagai underlay. Garis putus-putus hitam menunjukkan bagaimana lalu lintas antara dua situs lokal dapat dirutekan melalui NVA SD-WAN yang disebarkan di wilayah Azure yang secara geografis dekat dengan situs. Backbone Microsoft, karena jangkauannya, kapasitas dan kebijakan perutean "cold potato" dapat menyebabkan performa yang jauh lebih baik/dapat diprediksi daripada internet publik, terutama untuk koneksi jarak jauh.

Produk SD-WAN di jaringan hub-and-spoke Azure

Bagian ini memberikan rekomendasi untuk menyebarkan perangkat CPE non-Microsoft SD-WAN sebagai NVA di hub yang ada dan jaringan Azure spoke.

NVA SD-WAN di jaringan virtual hub

Hub dan Spoke adalah topologi yang direkomendasikan Microsoft untuk membangun jaringan yang dapat diskalakan di wilayah Azure menggunakan jaringan virtual yang dikelola pelanggan. Jaringan virtual hub menghosting komponen bersama seperti NVA non-Microsoft dan layanan asli yang menyediakan fungsi jaringan, seperti firewall, penyeimbangan beban, dan konektivitas ke situs lokal melalui VPN situs-2 situs atau ExpressRoute. Jaringan virtual hub adalah lokasi alami untuk NVA SD-WAN, yang pada akhirnya adalah gateway non-Microsoft yang menyediakan akses ke jaringan jarak jauh.

NVA SD-WAN harus disebarkan di jaringan virtual hub sebagai berikut:

• Satu pengontrol antarmuka jaringan tunggal (NIC) digunakan untuk semua lalu lintas SD-WAN. NIC lain, seperti NIC manajemen, dapat ditambahkan untuk memenuhi persyaratan keamanan dan kepatuhan atau untuk mematuhi pedoman vendor untuk penyebaran Azure.
• NIC yang digunakan untuk lalu lintas SD-WAN harus dilampirkan ke subnet khusus. Ukuran subnet harus ditentukan berdasarkan jumlah NVA SD-WAN yang disebarkan untuk memenuhi ketersediaan tinggi (HA) dan persyaratan skala atau throughput, yang dibahas nanti dalam artikel ini.
• Kelompok Keamanan Jaringan (NSG) harus dikaitkan dengan NIC lalu lintas SD-WAN, baik secara langsung atau di tingkat subnet. Asosiasi ini memungkinkan koneksi dari situs lokal jarak jauh melalui port TCP/UDP yang digunakan oleh solusi SD-WAN.
• Penerusan IP harus diaktifkan pada NIC yang digunakan untuk lalu lintas SD-WAN.

Azure Route Server di jaringan virtual hub

Azure Route Server mengotomatiskan pertukaran rute antara NVA SD-WAN dan tumpukan Azure Software Defined Networking (SDN). Route Server mendukung BGP sebagai protokol perutean dinamis. Dengan menetapkan adjacencies BGP antara Route Server dan NVA SD-WAN:

• Rute untuk semua situs lokal yang terhubung ke SD-WAN disuntikkan dalam tabel rute jaringan virtual dan dipelajari oleh semua Azure VM.
• Rute untuk semua prefiks IP yang disertakan dalam ruang alamat jaringan virtual disebarkan ke semua situs yang terhubung dengan SD-WAN.

Route Server harus dikonfigurasi sebagai berikut.

• Ini harus disebarkan di subnet khusus di jaringan virtual hub sesuai Membuat dan mengonfigurasi Route Server menggunakan portal Microsoft Azure.
• Untuk mengaktifkan pertukaran rute otomatis untuk semua jaringan virtual spoke, peering jaringan virtual harus dikonfigurasi untuk memungkinkan jaringan virtual spoke menggunakan gateway jaringan virtual hub dan Route Server. Detail yang tersedia di FAQ Azure Route Server.
• Karena Route Server dan NVA SD-WAN dilampirkan ke subnet yang berbeda, sesi BGP antara Route Server dan NVA SD-WAN harus dikonfigurasi dengan dukungan multihop eBGP. Sejumlah hop antara 2 dan maksimum yang didukung oleh NVA SD-WAN dapat diatur. Detail tentang mengonfigurasi adjacencies BGP untuk Route Server tersedia di Membuat dan mengonfigurasi Route Server menggunakan portal Microsoft Azure.
• Dua /32 rute statis harus dikonfigurasi pada NVA SD-WAN untuk titik akhir BGP yang diekspos oleh Route Server. Konfigurasi ini memastikan bahwa tabel rute NVA selalu berisi rute untuk rekan BGP multihop -nya (tidak terhubung langsung).

Route Server tidak berada di jalur data. Ini adalah entitas sarana kontrol. Ini menyebarkan rute antara NVA SD-WAN dan tumpukan SDN jaringan virtual, tetapi penerusan lalu lintas aktual antara NVA SD-WAN dan komputer virtual di jaringan virtual dilakukan oleh tumpukan Azure SDN, seperti yang ditunjukkan pada gambar berikut. Untuk mendapatkan perilaku perutean ini, Route Server menyuntikkan semua rute yang dipelajarinya dari NVA SD-WAN dengan hop berikutnya diatur ke alamat NVA sendiri.

Route Server tidak mendukung IPv6 sampai sekarang. Arsitektur ini hanya untuk IPv4.

Gambar 2. Route Server mendukung penyebaran rute antara CPE SD-WAN dan tumpukan SDN jaringan virtual, tetapi tidak meneruskan lalu lintas antara CPE SD-WAN dan komputer virtual di jaringan virtual.

Ketersediaan tinggi untuk NVA SD-WAN dengan Route Server

Route Server memiliki KETERSEDIAAN TINGGI bawaan. Dua simpul komputasi mengembalikan satu instans Route Server. Mereka disebarkan di zona ketersediaan yang berbeda, untuk wilayah yang memiliki dukungan zona ketersediaan, atau dalam set ketersediaan yang sama. Mereka mengekspos dua titik akhir BGP. HA untuk NVA SD-WAN dicapai dengan menyebarkan beberapa instans di zona ketersediaan yang berbeda, untuk wilayah yang mendukungnya, atau dalam set ketersediaan yang sama. Setiap NVA SD-WAN menetapkan dua sesi BGP dengan kedua titik akhir yang diekspos oleh Route Server.

Arsitektur yang dijelaskan dalam artikel ini tidak bergantung pada Azure Load Balancer. Lebih spesifik:

• Tidak ada penyeimbang beban publik yang mengekspos titik akhir terowongan SD-WAN. Setiap NVA SD-WAN mengekspos titik akhir terowongannya sendiri. Rekan jarak jauh membuat beberapa terowongan, satu untuk setiap NVA SD-WAN di Azure.

• Tidak ada penyeimbang beban internal yang mendistribusikan lalu lintas yang berasal dari Azure VM ke NVA SD-WAN. Route Server dan tumpukan Azure SDN mendukung perutean Equal-Cost Multipath (ECMP). Jika beberapa NVA menyiapkan adjacencies BGP dengan Route Server dan mengumumkan rute untuk tujuan yang sama (seperti dalam, jaringan jarak jauh dan situs yang terhubung ke SD-WAN) dengan menggunakan tingkat preferensi yang sama, Route Server:

  • Menyuntikkan beberapa rute untuk tujuan tersebut di tabel rute jaringan virtual.
  • Mengatur setiap rute untuk menggunakan NVA yang berbeda sebagai hop berikutnya.

Tumpukan SDN kemudian mendistribusikan lalu lintas ke tujuan tersebut di semua hop berikutnya yang tersedia.

Arsitektur HA yang dihasilkan ditunjukkan pada gambar berikut:

Gambar 3. Route Server mendukung perutean Equal-Cost Multipath (ECMP). Azure Load Balancer tidak diperlukan saat beberapa NVA SD-WAN digunakan untuk tujuan ketersediaan dan/atau skalabilitas.

N-aktif versus aktif stand-by ketersediaan tinggi

Saat Anda menggunakan beberapa NVA SD-WAN dan mengintipnya dengan Route Server, BGP mendorong failover. Jika NVA SD-WAN offline, SD-WAN akan menghentikan rute iklan ke Route Server. Rute yang dipelajari dari perangkat yang gagal kemudian ditarik dari tabel rute jaringan virtual. Jadi, jika NVA SD-WAN tidak lagi menyediakan konektivitas ke situs SD-WAN jarak jauh karena kesalahan, di perangkat itu sendiri atau di underlay, itu tidak lagi muncul sebagai lompatan berikutnya ke situs jarak jauh dalam tabel rute jaringan virtual. Semua lalu lintas masuk ke perangkat sehat yang tersisa. Untuk informasi selengkapnya tentang penyebaran rute antara NVA SD-WAN dan Route Server, lihat Rute yang diiklankan oleh serekan BGP ke Route Server.

Gambar 4. Failover berbasis BGP. Jika SD-WAN NVA #0 offline, sesi BGP-nya dengan Route Server ditutup. SD-WAN NVA #0 dihapus dari tabel rute jaringan virtual sebagai lompatan berikutnya untuk lalu lintas dari Azure ke situs lokal.

Failover berbasis BGP dan perutean ECMP secara alami memungkinkan arsitektur N-active HA dengan perangkat N memproses lalu lintas secara bersamaan. Tetapi Anda juga dapat menggunakan BGP untuk menerapkan arsitektur HA aktif dan pasif: mengonfigurasi perangkat pasif untuk mengumumkan ke Route Server rute dengan tingkat preferensi yang lebih rendah daripada serekan aktifnya. Route Server membuang rute yang diterima dari perangkat pasif jika menerima dari perangkat aktif rute apa pun untuk tujuan yang sama dengan tingkat preferensi yang lebih tinggi. Dan plumbs hanya rute terakhir di tabel rute jaringan virtual.

Jika perangkat aktif gagal atau menarik beberapa rutenya, Route Server:

• Memilih rute terkait yang diumumkan oleh perangkat pasif.
• Plumbs rute di tabel rute jaringan virtual.

Satu-satunya atribut BGP yang dapat digunakan NVA SD-WAN untuk mengekspresikan tingkat preferensi untuk rute yang mereka umumkan ke Route Server adalah Jalur AS.

Kami merekomendasikan arsitektur N-active HA karena mengaktifkan penggunaan sumber daya yang optimal (tidak ada NVA SD-WAN siaga) dan skalabilitas horizontal. Untuk meningkatkan throughput, beberapa NVA dapat berjalan secara paralel, hingga jumlah maksimum serekan BGP yang didukung oleh Route Server. Untuk informasi selengkapnya, lihat Serekan BGP. Tetapi model N-active HA mengharuskan NVA SD-WAN bertindak sebagai router lapisan 3 tanpa status. Ketika beberapa terowongan ke situs ada, koneksi TCP dapat dirutekan secara asimetris. Artinya, alur ASLI dan BALASAN dari koneksi TCP yang sama dapat dirutekan melalui terowongan yang berbeda dan NVA yang berbeda. Gambar berikut menunjukkan contoh koneksi TCP yang dirutekan secara asimetris. Asimetri perutean tersebut dimungkinkan untuk koneksi TCP yang dimulai di jaringan virtual atau situs lokal.

Gambar 5. Perutean asimetris dalam arsitektur HA aktif/aktif. SD-WAN NVA #0 dan SD-WAN NVA #1 mengumumkan rute yang sama untuk tujuan 192.168.1.0/24 (situs SD-WAN jarak jauh) dengan panjang Jalur AS yang sama ke Route Server. Alur ASLI (dari situs jarak jauh SD-WAN ke Azure, jalur merah) dirutekan melalui terowongan yang dihentikan, di sisi Azure, dengan SD-WAN NVA #1. CPE SD-WAN lokal memilih terowongan ini. Tumpukan Azure SDN merutekan alur REPLY (dari Azure ke situs SD-WAN jarak jauh, jalur hijau) ke SD-WAN NVA #0, yang merupakan salah satu lompatan berikutnya yang mungkin untuk 192.168.1.0/24, menurut tabel rute jaringan virtual. Tidak dimungkinkan untuk menjamin bahwa hop berikutnya yang dipilih oleh tumpukan Azure SDN selalu sama SD-WAN CPE yang menerima alur ASLI.

Arsitektur HA aktif dan pasif hanya boleh dipertimbangkan ketika NVA SD-WAN di Azure melakukan fungsi jaringan lain yang memerlukan simetri perutean, seperti firewall stateful. Kami tidak merekomendasikan pendekatan ini karena implikasinya pada skalabilitas. Menjalankan lebih banyak fungsi jaringan pada NVA SD-WAN meningkatkan konsumsi sumber daya. Pada saat yang sama, arsitektur HA aktif dan pasif memungkinkan memiliki satu lalu lintas pemrosesan NVA tunggal kapan saja. Artinya, seluruh lapisan SD-WAN hanya dapat diskalakan hingga ukuran Azure VM maksimum yang didukungnya, tidak diskalakan. Jalankan fungsi jaringan stateful yang memerlukan simetri perutean pada kluster NVA terpisah yang mengandalkan Standard Load Balancer untuk ha n-aktif.

Pertimbangan konektivitas ExpressRoute

Arsitektur yang dijelaskan dalam artikel ini memungkinkan pelanggan sepenuhnya merangkul paradigma SD-WAN dan membangun jaringan perusahaan mereka sebagai overlay logis di atas internet publik dan backbone Microsoft. Ini juga mendukung penggunaan sirkuit Expressroute khusus untuk mengatasi skenario tertentu, yang dijelaskan nanti.

Skenario #1: Koeksistensi ExpressRoute dan SD-WAN

Solusi SD-WAN dapat berdampingan dengan konektivitas ExpressRoute saat perangkat SD-WAN hanya disebarkan di subset situs. Misalnya, beberapa organisasi mungkin menyebarkan solusi SD-WAN sebagai pengganti VPN IPsec tradisional di situs dengan konektivitas internet saja. Kemudian mereka menggunakan layanan MPLS dan sirkuit ExpressRoute untuk situs besar dan pusat data, seperti yang ditunjukkan pada gambar berikut.

Gambar 6. solusi SD-WAN dapat berdampingan dengan konektivitas ExpressRoute ketika perangkat CPE SD-WAN hanya disebarkan di subset situs.

Skenario koeksistensi ini mengharuskan NVA SD-WAN yang disebarkan di Azure untuk mampu merutekan lalu lintas antar situs yang terhubung ke SD-WAN dan situs yang terhubung ke sirkuit ExpressRoute. Route Server dapat dikonfigurasi untuk menyebarluaskan rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN di Azure dengan mengaktifkan fitur tersebut, seperti yang AllowBranchToBranch didokumenkan di sini. Penyebaran rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN terjadi melalui BGP. Route Server menetapkan sesi BGP dengan keduanya dan menyebar ke setiap rekan rute yang dipelajari dari yang lain. Platform ini mengelola sesi BGP antara Route Server dan gateway jaringan virtual ExpressRoute. Pengguna tidak perlu mengonfigurasinya secara eksplisit, tetapi hanya untuk mengaktifkan AllowBranchToBranch bendera saat menyebarkan Route Server.

Gambar 7. Perambatan rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN terjadi melalui BGP. Route Server menetapkan sesi BGP dengan dan menyebarkan rute di kedua arah saat dikonfigurasi dengan "AllowBranchToBranch=TRUE". Route Server bertindak sebagai reflektor rute, yaitu, itu bukan bagian dari jalur data.

Skenario koeksistensi SD-WAN dan ExpressRoute ini memungkinkan migrasi dari jaringan MPLS ke SD-WAN. Ini menawarkan jalur antara situs MPLS warisan dan situs SD-WAN yang baru dimigrasikan, menghilangkan kebutuhan untuk merutekan lalu lintas melalui pusat data lokal. Pola ini dapat digunakan tidak hanya selama migrasi tetapi juga dalam skenario yang timbul dari merger perusahaan dan akuisisi, menyediakan interkoneksi jaringan yang berbeda yang mulus.

Skenario #2: Expressroute sebagai underlay SD-WAN

Jika situs lokal Anda memiliki konektivitas ExpressRoute, Anda dapat mengonfigurasi perangkat SD-WAN untuk menyiapkan terowongan ke NVA hub SD-WAN yang berjalan di Azure di atas sirkuit atau sirkuit ExpressRoute. Konektivitas ExpressRoute dapat dilakukan melalui sirkuit titik-ke-titik atau jaringan MPLS. Anda dapat menggunakan peering privat ExpressRoute dan peering Microsoft.

Peering Pribadi

Saat Anda menggunakan peering privat ExpressRoute sebagai underlay, semua situs SD-WAN lokal membuat terowongan ke NVA hub SD-WAN di Azure. Tidak ada penyebaran rute antara NVA SD-WAN dan gateway jaringan virtual ExpressRoute yang diperlukan dalam skenario ini (yaitu, Route Server harus dikonfigurasi dengan bendera "AllowBranchToBranch" diatur ke false).

Pendekatan ini memerlukan konfigurasi BGP yang tepat pada router sisi pelanggan atau penyedia yang mengakhiri koneksi ExpressRoute. Bahkan, Microsoft Enterprise Edge Routers (MSEEs) mengumumkan semua rute untuk jaringan virtual yang terhubung ke sirkuit (baik secara langsung atau melalui peering jaringan virtual). Tetapi untuk meneruskan lalu lintas yang ditujukan ke jaringan virtual melalui terowongan SD-WAN, situs lokal harus mempelajari rute tersebut dari perangkat SD-WAN - bukan sirkuit ER.

Oleh karena itu, router sisi pelanggan atau sisi penyedia yang mengakhiri koneksi ExpressRoute harus memfilter rute yang diterima dari Azure. Satu-satunya rute yang dikonfigurasi dalam underlay harus rute yang memungkinkan perangkat SD-WAN lokal mencapai NVA hub SD-WAN di Azure. Pelanggan yang ingin menggunakan peering privat ExpressRoute sebagai underlay SD-WAN harus memverifikasi bahwa mereka dapat mengonfigurasi perangkat perutean mereka. Melakukannya sangat relevan bagi pelanggan yang tidak memiliki kontrol langsung atas perangkat edge mereka untuk ExpressRoute. Contohnya adalah ketika sirkuit ExpressRoute disediakan oleh operator MPLS di atas layanan IPVPN.

Gambar 8. Peering privat ExpressRoute sebagai underlay SD-WAN. Dalam skenario ini, router pelanggan dan sisi penyedia menerima rute untuk jaringan virtual yang mengakhiri koneksi ExpressRoute, dalam sesi BGP peering privat ER, dan CPE SD-WAN. Hanya CPE SD-WAN yang harus menyebarluaskan rute Azure ke LAN situs.

Peering Microsoft

Anda juga dapat menggunakan peering Microsoft ExpressRoute sebagai underlay untuk terowongan SD-WAN. Dalam skenario ini, NVA hub SD-WAN di Azure hanya mengekspos titik akhir terowongan publik, yang digunakan oleh kedua CPU SD-WAN di situs yang terhubung ke internet, jika ada, dan oleh CPU SD-WAN di situs yang terhubung dengan Expressroute. Meskipun peering Microsoft ExpressRoute memiliki prasyarat yang lebih kompleks daripada peering privat, sebaiknya gunakan opsi ini sebagai underlay karena dua keuntungan ini:

• Ini tidak memerlukan gateway jaringan virtual Expressroute di jaringan virtual hub. Ini menghapus kompleksitas, mengurangi biaya, dan memungkinkan solusi SD-WAN skala di luar batas bandwidth gateway itu sendiri ketika Anda tidak menggunakan ExpressRoute FastPath.

• Ini menyediakan pemisahan yang bersih antara rute overlay dan underlay. MSEEs hanya mengumumkan awalan publik jaringan Microsoft ke tepi pelanggan atau penyedia. Anda dapat mengelola rute tersebut di VRF terpisah dan menyebarkan hanya ke segmen DMZ LAN situs. Perangkat SD-WAN menyebarluaskan rute untuk jaringan perusahaan pelanggan dalam overlay, termasuk rute untuk jaringan virtual. Pelanggan yang mempertimbangkan pendekatan ini harus memverifikasi bahwa mereka dapat mengonfigurasi perangkat perutean mereka sesuai atau meminta layanan yang tepat ke operator MPLS mereka.

Pertimbangan MPLS

Migrasi dari jaringan perusahaan MPLS tradisional ke arsitektur jaringan yang lebih modern berdasarkan paradigma SD-WAN membutuhkan upaya yang signifikan dan sejumlah besar waktu. Arsitektur yang dijelaskan dalam artikel ini memungkinkan migrasi SD-WAN bertahas. Dua skenario migrasi umum dibahas nanti.

Penonaktifan MPLS bertahas

Pelanggan yang ingin membangun SD-WAN di atas internet publik dan backbone Microsoft, dan SEPENUHNYA menonaktifkan IPVPN MPLS atau layanan konektivitas khusus lainnya, dapat menggunakan skenario Koeksistensi ExpressRoute dan SD-WAN yang dijelaskan di bagian sebelumnya selama migrasi. Ini memungkinkan situs yang terhubung dengan SD-WAN untuk menjangkau situs yang masih terhubung ke MPLS warisan. Segera setelah situs dimigrasikan ke perangkat SD-WAN dan CPE disebarkan, tautan MPLS-nya dapat dinonaktifkan. Situs ini dapat mengakses seluruh jaringan perusahaan melalui terowongan SD-WAN-nya ke wilayah Azure terdekat.

Gambar 9. Skenario "ExpressRoute dan SD-WAN koeksistensi" memungkinkan penonaktifan MPLS bertahap.

Ketika semua situs dimigrasikan, MPLS IPVPN dapat dinonaktifkan, bersama dengan sirkuit ExpressRoute yang menghubungkannya ke backbone Microsoft. Gateway jaringan virtual ExpressRoute tidak lagi diperlukan dan dapat dibatalkan provisinya. NVA hub SD-WAN di setiap wilayah menjadi satu-satunya titik masuk ke jaringan hub dan spoke wilayah tersebut.

Integrasi MPLS

Organisasi yang tidak mempercayai jaringan publik dan bersama untuk memberikan performa dan keandalan yang diinginkan dapat memutuskan untuk menggunakan jaringan MPLS yang ada sebagai underlay kelas perusahaan. Dua opsinya adalah:

• Subset situs seperti pusat data atau kantor cabang besar.
• Subset koneksi, biasanya lalu lintas peka latensi atau misi penting.

Skenario Expressroute sebagai underlay SD-WAN yang dijelaskan sebelumnya memungkinkan integrasi SD-WAN dan MPLS. Peering Microsoft ExpressRoute harus lebih disukai daripada peering privat karena alasan yang dibahas sebelumnya. Selain itu, ketika peering Microsoft digunakan, jaringan MPLS dan internet publik menjadi underlay yang setara secara fungsional. Mereka menyediakan akses ke semua titik akhir terowongan SD-WAN yang diekspos oleh NVA hub SD-WAN di Azure. CPE SD-WAN yang disebarkan di situs dengan konektivitas internet dan MPLS dapat membangun beberapa terowongan ke hub SD-WAN di Azure pada kedua underlay. Mereka kemudian dapat merutekan koneksi yang berbeda melalui terowongan yang berbeda, berdasarkan kebijakan tingkat aplikasi yang dikelola oleh sarana kontrol SD-WAN.

Gambar 10. Skenario "ExpressRoute sebagai underlay SD-WAN" memungkinkan integrasi SD-WAN dan MPLS.

Preferensi perutean Route Server

Dalam kedua skenario MPLS yang tercakup dalam dua bagian sebelumnya, beberapa situs cabang dapat dihubungkan baik ke MPLS IPVPN maupun ke SD-WAN. Akibatnya, instans Route Server yang disebarkan di jaringan virtual hub dapat mempelajari rute yang sama dari Gateway ExpressRoute dan NVA SD-WAN. Preferensi perutean Route Server memungkinkan kontrol jalur mana yang harus disukai dan disematkan ke dalam tabel rute jaringan virtual. Preferensi perutean berguna ketika prepending Jalur AS tidak dapat digunakan. Contohnya adalah layanan MPLS IPVPN yang tidak mendukung konfigurasi BGP kustom pada PEs yang menghentikan koneksi ExpressRoute.

Batas Route Server dan pertimbangan desain

Route Server adalah landasan arsitektur yang dijelaskan dalam artikel ini. Ini menyebarkan rute antara NVA SD-WAN yang disebarkan di jaringan virtual dan tumpukan Azure SDN yang mendasar. Ini menyediakan pendekatan berbasis BGP untuk menjalankan beberapa NVA SD-WAN untuk ketersediaan tinggi dan skalabilitas horizontal. Ketika Anda merancang SD-WANs besar berdasarkan arsitektur ini, batas skalabilitas Route Server harus diperhitungkan.

Bagian berikut memberikan panduan tentang maksimum skalabilitas dan cara menangani setiap batas.

Rute yang diiklankan oleh peer BGP ke Route Server

Route Server tidak menentukan batas eksplisit untuk jumlah rute yang dapat diiklankan ke Gateway Jaringan Virtual ExpressRoute saat AllowBranchToBranch bendera diatur. Namun, Gateway ExpressRoute semakin menyebarluaskan rute yang mereka pelajari dari Route Server ke sirkuit ExpressRoute yang terhubung dengannya.

Ada batasan jumlah rute yang dapat diiklankan Gateway ExpressRoute ke sirkuit ExpressRoute melalui peering privat, yang didokumentasikan di batas langganan dan layanan Azure, kuota, dan batasan. Saat merancang solusi SD-WAN berdasarkan panduan dalam artikel ini, penting untuk memastikan bahwa rute SD-WAN tidak menyebabkan batas ini terpukul. Jika terpukul, sesi BGP antara Gateway ExpressRoute dan sirkuit ExpressRoute dihilangkan, dan konektivitas antara jaringan virtual dan jaringan jarak jauh yang terhubung melalui ExpressRoute hilang.

Jumlah total rute yang diiklankan ke sirkuit oleh Gateway ExpressRoute adalah jumlah jumlah rute yang dipelajari dari Route Server dan jumlah awalan yang membentuk hub Azure dan ruang alamat jaringan spoke. Untuk menghindari pemadaman karena sesi BGP yang dihentikan, kami sarankan Anda menerapkan mitigasi berikut:

• Gunakan fitur perangkat SD-WAN asli untuk membatasi jumlah rute yang diumumkan ke Route Server, jika fitur tersedia.
• Gunakan Pemberitahuan Azure Monitor untuk mendeteksi lonjakan jumlah rute yang diumumkan oleh Gateway ExpressRoute secara proaktif. Metrik yang akan dipantau diberi nama Count of Routes Advertised to Peer, seperti yang didokumentasikan dalam pemantauan ExpressRoute.

Rekan-rekan BGP

Route Server dapat membuat sesi BGP hingga jumlah maksimum serekan BGP. Batas ini menentukan jumlah maksimum NVA SD-WAN yang dapat menetapkan adjacencies BGP dengan Route Server, dan oleh karena itu throughput agregat maksimum yang dapat didukung di semua terowongan SD-WAN. Hanya SD-WAN besar yang diharapkan mencapai batas ini. Tidak ada solusi untuk mengatasinya, selain membuat beberapa jaringan hub dan spoke, masing-masing dengan gateway dan server rutenya sendiri.

VM yang berpartisipasi

Gateway Virtual Network dan Route Server mengonfigurasi rute yang mereka pelajari dari rekan jarak jauh mereka untuk semua VM di jaringan virtual mereka sendiri dan di jaringan virtual yang di-peering secara langsung. Untuk melindungi Route Server dari konsumsi sumber daya yang berlebihan karena pembaruan perutean ke VM, Azure menentukan batas jumlah VM yang dapat ada di satu hub dan jaringan spoke. Tidak ada solusi untuk mengatasi batas ini, selain membuat beberapa jaringan hub dan spoke, masing-masing dengan gateway dan server rutenya sendiri, di wilayah yang sama.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Federico Guerrini | Arsitek Solusi Cloud Senior
• Khush Kaviraj | Arsitek Solusi Cloud

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Kerangka Kerja Well-Architected Microsoft

Sumber daya terkait

• Menyambungkan jaringan lokal ke Azure menggunakan ExpressRoute
• Menyebarkan NVA yang sangat tersedia

Artikel ini ditujukan untuk arsitek jaringan yang ingin merancang Wide Area Networks (SD-WAN) yang ditentukan perangkat lunak untuk menghubungkan fasilitas lokal satu sama lain dan dengan Azure. Ini menjelaskan arsitektur yang memungkinkan pelanggan Azure menggunakan investasi yang ada di platform, dengan membangun overlay SD-WAN global yang efisien di atas tulang punggung Microsoft.

Skenario yang berlaku

Rekomendasi dalam artikel ini adalah vendor-agnostik dan berlaku untuk teknologi non-Microsoft SD-WAN yang memenuhi dua prasyarat dasar:

• Mengandalkan protokol penerowongan yang menggunakan Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP) sebagai transportasi yang mendasarinya, seperti menjadi IPsec ESP mode terowongan dengan NAT-Traversal.
• Dukungan Border Gateway Protocol (BGP) v4 untuk pertukaran rute dengan entitas eksternal. Tidak ada asumsi yang dibuat pada protokol perutean yang digunakan oleh perangkat non-Microsoft SD-WAN untuk bertukar informasi perutean antara satu sama lain.

Pelanggan yang mematuhi rekomendasi ini dapat menggunakan teknologi pilihan SD-WAN mereka untuk mencapai tujuan berikut:

• Integrasikan produk SD-WAN di hub Azure dan jaringan spoke yang ada, dengan mengotomatiskan pertukaran rute antara Perangkat Azure Virtual Network dan SD-WAN.
• Optimalkan konektivitas (baik ke Azure maupun pusat data lokal) untuk cabang dengan breakout internet lokal. Jangkauan backbone Microsoft, dikombinasikan dengan kapasitas, ketahanan, dan kebijakan perutean "cold potato" menunjukkan bahwa itu dapat digunakan sebagai underlay berkinerja tinggi untuk SD-WAN global.
• Gunakan backbone Microsoft untuk semua lalu lintas Azure-ke-Azure (lintas wilayah dan geografi silang).
• Gunakan jaringan Multi-Protocol-Label-Switching (MPLS) yang ada sebagai underlay berkinerja tinggi. Ini juga dapat digunakan untuk menggantikan jaringan MPLS yang ada dalam pendekatan bertahas yang meminimalkan efek pada bisnis.

Bagian berikut mengasumsikan bahwa pembaca terbiasa dengan dasar-dasar paradigmaSD-WAN dan dengan arsitektur backbone Microsoft. Backbone Microsoft menghubungkan wilayah Azure satu sama lain dan dengan internet publik.

Sistem

Organisasi dengan kehadiran global dan jejak Azure multi-wilayah biasanya menggunakan kombinasi layanan konektivitas untuk mengimplementasikan jaringan perusahaan mereka dan untuk terhubung ke backbone Microsoft:

• Layanan konektivitas khusus, seperti MPLS Internet-Protocol-Virtual-Private-Networks (IPVPN), dapat digunakan di situs terbesar, seperti pusat data atau kantor pusat.
• Situs besar dapat mencakup konektivitas khusus ke tulang punggung Microsoft melalui sirkuit ExpressRoute, menggunakan salah satu model konektivitas yang didukung. Lebih khusus lagi, situs dapat menggunakan sirkuit titik-ke-titik khusus untuk terhubung ke lokasi peering ExpressRoute terdekat. Atau dapat menerapkan MPLS IPVPN-nya untuk mengakses sirkuit ExpressRoute yang disediakan oleh operator MPLS.
• Kantor cabang yang hanya memiliki konektivitas internet mungkin menggunakan VPN IPsec untuk terhubung ke pusat data lokal terdekat dan menggunakan koneksi ExpressRoute pusat data tersebut untuk mengakses sumber daya Azure. Atau mereka mungkin menggunakan VPN IPsec untuk langsung terhubung ke hub Azure dan jaringan spoke.

Proyek SD-WAN dapat memiliki cakupan yang berbeda dalam hal layanan jaringan tradisional mana yang ingin mereka ganti. Beberapa organisasi mungkin ingin tetap berpegang pada tautan khusus atau MPLS untuk fasilitas besar dan menyebarkan SD-WAN hanya untuk menggantiKAN VPN IPsec berbasis internet warisan di situs kecil. Organisasi lain mungkin ingin memperluas SD-WAN mereka ke situs yang terhubung dengan MPLS dan menggunakan jaringan MPLS yang ada sebagai underlay berkinerja tinggi. Akhirnya, beberapa organisasi mungkin ingin menutup IPVPN MPLS mereka. atau layanan konektivitas khusus apa pun, untuk merangkul paradigma SD-WAN. Dengan cara ini, mereka dapat membangun seluruh jaringan perusahaan mereka sebagai overlay logis di atas underlay publik atau bersama (internet publik dan backbone Microsoft).

Arsitektur yang dijelaskan dalam artikel ini mendukung semua cakupan yang tercantum sebelumnya dan didasarkan pada prinsip-prinsip berikut:

• Perangkat SD-WAN disebarkan sebagai Network Virtual Appliances (NVA) di setiap hub wilayah Azure dan jaringan spoke dan dikonfigurasi sebagai hub SD-WAN yang mengakhiri terowongan dari situs lokal.
• Perangkat SD-WAN di Azure dikonfigurasi untuk membuat terowongan satu sama lain, sehingga membuat overlay hub-ke-hub yang sepenuhnya bertaut yang dapat secara efisien mengangkut lalu lintas di antara wilayah Azure, dan menyampaikan lalu lintas antara situs lokal yang jauh secara geografis, di atas backbone Microsoft.
• Perangkat SD-WAN disebarkan di semua situs lokal yang dicakup oleh solusi SD-WAN dan dikonfigurasi untuk membuat terowongan ke NVA SD-WAN di wilayah Azure terdekat. Situs yang berbeda dapat menggunakan layanan transportasi yang berbeda sebagai underlay untuk terowongan, seperti internet publik, konektivitas ExpressRoute, dan sebagainya.
• Lalu lintas dari situs ke tujuan apa pun, baik di Azure atau di situs lokal lain, dirutekan ke NVA SD-WAN di wilayah Azure terdekat. Kemudian merutekan melalui overlay hub-to-hub.

Produk SD-WAN dapat menggunakan protokol dan fitur eksklusif untuk mendeteksi, setelah dibuat secara dinamis, terowongan langsung antara dua situs dapat memberikan performa yang lebih baik daripada menyampaikan lalu lintas melalui NVA SD-WAN di Azure.

Arsitektur tingkat tinggi dari SD-WAN global yang menggunakan backbone Microsoft, internet publik, dan koneksi ER khusus sebagai underlay ditampilkan dalam gambar berikut.

Gambar 1: Arsitektur tingkat tinggi dari SD-WAN global yang menggunakan backbone Microsoft, internet publik, dan koneksi ER khusus sebagai underlay. Garis putus-putus hitam menunjukkan bagaimana lalu lintas antara dua situs lokal dapat dirutekan melalui NVA SD-WAN yang disebarkan di wilayah Azure yang secara geografis dekat dengan situs. Backbone Microsoft, karena jangkauannya, kapasitas dan kebijakan perutean "cold potato" dapat menyebabkan performa yang jauh lebih baik/dapat diprediksi daripada internet publik, terutama untuk koneksi jarak jauh.

Produk SD-WAN di jaringan hub-and-spoke Azure

Bagian ini memberikan rekomendasi untuk menyebarkan perangkat CPE non-Microsoft SD-WAN sebagai NVA di hub yang ada dan jaringan Azure spoke.

NVA SD-WAN di jaringan virtual hub

Hub dan Spoke adalah topologi yang direkomendasikan Microsoft untuk membangun jaringan yang dapat diskalakan di wilayah Azure menggunakan jaringan virtual yang dikelola pelanggan. Jaringan virtual hub menghosting komponen bersama seperti NVA non-Microsoft dan layanan asli yang menyediakan fungsi jaringan, seperti firewall, penyeimbangan beban, dan konektivitas ke situs lokal melalui VPN situs-2 situs atau ExpressRoute. Jaringan virtual hub adalah lokasi alami untuk NVA SD-WAN, yang pada akhirnya adalah gateway non-Microsoft yang menyediakan akses ke jaringan jarak jauh.

NVA SD-WAN harus disebarkan di jaringan virtual hub sebagai berikut:

• Satu pengontrol antarmuka jaringan tunggal (NIC) digunakan untuk semua lalu lintas SD-WAN. NIC lain, seperti NIC manajemen, dapat ditambahkan untuk memenuhi persyaratan keamanan dan kepatuhan atau untuk mematuhi pedoman vendor untuk penyebaran Azure.
• NIC yang digunakan untuk lalu lintas SD-WAN harus dilampirkan ke subnet khusus. Ukuran subnet harus ditentukan berdasarkan jumlah NVA SD-WAN yang disebarkan untuk memenuhi ketersediaan tinggi (HA) dan persyaratan skala atau throughput, yang dibahas nanti dalam artikel ini.
• Kelompok Keamanan Jaringan (NSG) harus dikaitkan dengan NIC lalu lintas SD-WAN, baik secara langsung atau di tingkat subnet. Asosiasi ini memungkinkan koneksi dari situs lokal jarak jauh melalui port TCP/UDP yang digunakan oleh solusi SD-WAN.
• Penerusan IP harus diaktifkan pada NIC yang digunakan untuk lalu lintas SD-WAN.

Azure Route Server di jaringan virtual hub

Azure Route Server mengotomatiskan pertukaran rute antara NVA SD-WAN dan tumpukan Azure Software Defined Networking (SDN). Route Server mendukung BGP sebagai protokol perutean dinamis. Dengan menetapkan adjacencies BGP antara Route Server dan NVA SD-WAN:

• Rute untuk semua situs lokal yang terhubung ke SD-WAN disuntikkan dalam tabel rute jaringan virtual dan dipelajari oleh semua Azure VM.
• Rute untuk semua prefiks IP yang disertakan dalam ruang alamat jaringan virtual disebarkan ke semua situs yang terhubung dengan SD-WAN.

Route Server harus dikonfigurasi sebagai berikut.

• Ini harus disebarkan di subnet khusus di jaringan virtual hub sesuai Membuat dan mengonfigurasi Route Server menggunakan portal Microsoft Azure.
• Untuk mengaktifkan pertukaran rute otomatis untuk semua jaringan virtual spoke, peering jaringan virtual harus dikonfigurasi untuk memungkinkan jaringan virtual spoke menggunakan gateway jaringan virtual hub dan Route Server. Detail yang tersedia di FAQ Azure Route Server.
• Karena Route Server dan NVA SD-WAN dilampirkan ke subnet yang berbeda, sesi BGP antara Route Server dan NVA SD-WAN harus dikonfigurasi dengan dukungan multihop eBGP. Sejumlah hop antara 2 dan maksimum yang didukung oleh NVA SD-WAN dapat diatur. Detail tentang mengonfigurasi adjacencies BGP untuk Route Server tersedia di Membuat dan mengonfigurasi Route Server menggunakan portal Microsoft Azure.
• Dua /32 rute statis harus dikonfigurasi pada NVA SD-WAN untuk titik akhir BGP yang diekspos oleh Route Server. Konfigurasi ini memastikan bahwa tabel rute NVA selalu berisi rute untuk rekan BGP multihop -nya (tidak terhubung langsung).

Route Server tidak berada di jalur data. Ini adalah entitas sarana kontrol. Ini menyebarkan rute antara NVA SD-WAN dan tumpukan SDN jaringan virtual, tetapi penerusan lalu lintas aktual antara NVA SD-WAN dan komputer virtual di jaringan virtual dilakukan oleh tumpukan Azure SDN, seperti yang ditunjukkan pada gambar berikut. Untuk mendapatkan perilaku perutean ini, Route Server menyuntikkan semua rute yang dipelajarinya dari NVA SD-WAN dengan hop berikutnya diatur ke alamat NVA sendiri.

Route Server tidak mendukung IPv6 sampai sekarang. Arsitektur ini hanya untuk IPv4.

Gambar 2. Route Server mendukung penyebaran rute antara CPE SD-WAN dan tumpukan SDN jaringan virtual, tetapi tidak meneruskan lalu lintas antara CPE SD-WAN dan komputer virtual di jaringan virtual.

Ketersediaan tinggi untuk NVA SD-WAN dengan Route Server

Route Server memiliki KETERSEDIAAN TINGGI bawaan. Dua simpul komputasi mengembalikan satu instans Route Server. Mereka disebarkan di zona ketersediaan yang berbeda, untuk wilayah yang memiliki dukungan zona ketersediaan, atau dalam set ketersediaan yang sama. Mereka mengekspos dua titik akhir BGP. HA untuk NVA SD-WAN dicapai dengan menyebarkan beberapa instans di zona ketersediaan yang berbeda, untuk wilayah yang mendukungnya, atau dalam set ketersediaan yang sama. Setiap NVA SD-WAN menetapkan dua sesi BGP dengan kedua titik akhir yang diekspos oleh Route Server.

Arsitektur yang dijelaskan dalam artikel ini tidak bergantung pada Azure Load Balancer. Lebih spesifik:

• Tidak ada penyeimbang beban publik yang mengekspos titik akhir terowongan SD-WAN. Setiap NVA SD-WAN mengekspos titik akhir terowongannya sendiri. Rekan jarak jauh membuat beberapa terowongan, satu untuk setiap NVA SD-WAN di Azure.

• Tidak ada penyeimbang beban internal yang mendistribusikan lalu lintas yang berasal dari Azure VM ke NVA SD-WAN. Route Server dan tumpukan Azure SDN mendukung perutean Equal-Cost Multipath (ECMP). Jika beberapa NVA menyiapkan adjacencies BGP dengan Route Server dan mengumumkan rute untuk tujuan yang sama (seperti dalam, jaringan jarak jauh dan situs yang terhubung ke SD-WAN) dengan menggunakan tingkat preferensi yang sama, Route Server:

  • Menyuntikkan beberapa rute untuk tujuan tersebut di tabel rute jaringan virtual.
  • Mengatur setiap rute untuk menggunakan NVA yang berbeda sebagai hop berikutnya.

Tumpukan SDN kemudian mendistribusikan lalu lintas ke tujuan tersebut di semua hop berikutnya yang tersedia.

Arsitektur HA yang dihasilkan ditunjukkan pada gambar berikut:

Gambar 3. Route Server mendukung perutean Equal-Cost Multipath (ECMP). Azure Load Balancer tidak diperlukan saat beberapa NVA SD-WAN digunakan untuk tujuan ketersediaan dan/atau skalabilitas.

N-aktif versus aktif stand-by ketersediaan tinggi

Saat Anda menggunakan beberapa NVA SD-WAN dan mengintipnya dengan Route Server, BGP mendorong failover. Jika NVA SD-WAN offline, SD-WAN akan menghentikan rute iklan ke Route Server. Rute yang dipelajari dari perangkat yang gagal kemudian ditarik dari tabel rute jaringan virtual. Jadi, jika NVA SD-WAN tidak lagi menyediakan konektivitas ke situs SD-WAN jarak jauh karena kesalahan, di perangkat itu sendiri atau di underlay, itu tidak lagi muncul sebagai lompatan berikutnya ke situs jarak jauh dalam tabel rute jaringan virtual. Semua lalu lintas masuk ke perangkat sehat yang tersisa. Untuk informasi selengkapnya tentang penyebaran rute antara NVA SD-WAN dan Route Server, lihat Rute yang diiklankan oleh serekan BGP ke Route Server.

Gambar 4. Failover berbasis BGP. Jika SD-WAN NVA #0 offline, sesi BGP-nya dengan Route Server ditutup. SD-WAN NVA #0 dihapus dari tabel rute jaringan virtual sebagai lompatan berikutnya untuk lalu lintas dari Azure ke situs lokal.

Failover berbasis BGP dan perutean ECMP secara alami memungkinkan arsitektur N-active HA dengan perangkat N memproses lalu lintas secara bersamaan. Tetapi Anda juga dapat menggunakan BGP untuk menerapkan arsitektur HA aktif dan pasif: mengonfigurasi perangkat pasif untuk mengumumkan ke Route Server rute dengan tingkat preferensi yang lebih rendah daripada serekan aktifnya. Route Server membuang rute yang diterima dari perangkat pasif jika menerima dari perangkat aktif rute apa pun untuk tujuan yang sama dengan tingkat preferensi yang lebih tinggi. Dan plumbs hanya rute terakhir di tabel rute jaringan virtual.

Jika perangkat aktif gagal atau menarik beberapa rutenya, Route Server:

• Memilih rute terkait yang diumumkan oleh perangkat pasif.
• Plumbs rute di tabel rute jaringan virtual.

Satu-satunya atribut BGP yang dapat digunakan NVA SD-WAN untuk mengekspresikan tingkat preferensi untuk rute yang mereka umumkan ke Route Server adalah Jalur AS.

Kami merekomendasikan arsitektur N-active HA karena mengaktifkan penggunaan sumber daya yang optimal (tidak ada NVA SD-WAN siaga) dan skalabilitas horizontal. Untuk meningkatkan throughput, beberapa NVA dapat berjalan secara paralel, hingga jumlah maksimum serekan BGP yang didukung oleh Route Server. Untuk informasi selengkapnya, lihat Serekan BGP. Tetapi model N-active HA mengharuskan NVA SD-WAN bertindak sebagai router lapisan 3 tanpa status. Ketika beberapa terowongan ke situs ada, koneksi TCP dapat dirutekan secara asimetris. Artinya, alur ASLI dan BALASAN dari koneksi TCP yang sama dapat dirutekan melalui terowongan yang berbeda dan NVA yang berbeda. Gambar berikut menunjukkan contoh koneksi TCP yang dirutekan secara asimetris. Asimetri perutean tersebut dimungkinkan untuk koneksi TCP yang dimulai di jaringan virtual atau situs lokal.

Gambar 5. Perutean asimetris dalam arsitektur HA aktif/aktif. SD-WAN NVA #0 dan SD-WAN NVA #1 mengumumkan rute yang sama untuk tujuan 192.168.1.0/24 (situs SD-WAN jarak jauh) dengan panjang Jalur AS yang sama ke Route Server. Alur ASLI (dari situs jarak jauh SD-WAN ke Azure, jalur merah) dirutekan melalui terowongan yang dihentikan, di sisi Azure, dengan SD-WAN NVA #1. CPE SD-WAN lokal memilih terowongan ini. Tumpukan Azure SDN merutekan alur REPLY (dari Azure ke situs SD-WAN jarak jauh, jalur hijau) ke SD-WAN NVA #0, yang merupakan salah satu lompatan berikutnya yang mungkin untuk 192.168.1.0/24, menurut tabel rute jaringan virtual. Tidak dimungkinkan untuk menjamin bahwa hop berikutnya yang dipilih oleh tumpukan Azure SDN selalu sama SD-WAN CPE yang menerima alur ASLI.

Arsitektur HA aktif dan pasif hanya boleh dipertimbangkan ketika NVA SD-WAN di Azure melakukan fungsi jaringan lain yang memerlukan simetri perutean, seperti firewall stateful. Kami tidak merekomendasikan pendekatan ini karena implikasinya pada skalabilitas. Menjalankan lebih banyak fungsi jaringan pada NVA SD-WAN meningkatkan konsumsi sumber daya. Pada saat yang sama, arsitektur HA aktif dan pasif memungkinkan memiliki satu lalu lintas pemrosesan NVA tunggal kapan saja. Artinya, seluruh lapisan SD-WAN hanya dapat diskalakan hingga ukuran Azure VM maksimum yang didukungnya, tidak diskalakan. Jalankan fungsi jaringan stateful yang memerlukan simetri perutean pada kluster NVA terpisah yang mengandalkan Standard Load Balancer untuk ha n-aktif.

Pertimbangan konektivitas ExpressRoute

Arsitektur yang dijelaskan dalam artikel ini memungkinkan pelanggan sepenuhnya merangkul paradigma SD-WAN dan membangun jaringan perusahaan mereka sebagai overlay logis di atas internet publik dan backbone Microsoft. Ini juga mendukung penggunaan sirkuit Expressroute khusus untuk mengatasi skenario tertentu, yang dijelaskan nanti.

Skenario #1: Koeksistensi ExpressRoute dan SD-WAN

Solusi SD-WAN dapat berdampingan dengan konektivitas ExpressRoute saat perangkat SD-WAN hanya disebarkan di subset situs. Misalnya, beberapa organisasi mungkin menyebarkan solusi SD-WAN sebagai pengganti VPN IPsec tradisional di situs dengan konektivitas internet saja. Kemudian mereka menggunakan layanan MPLS dan sirkuit ExpressRoute untuk situs besar dan pusat data, seperti yang ditunjukkan pada gambar berikut.

Gambar 6. solusi SD-WAN dapat berdampingan dengan konektivitas ExpressRoute ketika perangkat CPE SD-WAN hanya disebarkan di subset situs.

Skenario koeksistensi ini mengharuskan NVA SD-WAN yang disebarkan di Azure untuk mampu merutekan lalu lintas antar situs yang terhubung ke SD-WAN dan situs yang terhubung ke sirkuit ExpressRoute. Route Server dapat dikonfigurasi untuk menyebarluaskan rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN di Azure dengan mengaktifkan fitur tersebut, seperti yang AllowBranchToBranch didokumenkan di sini. Penyebaran rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN terjadi melalui BGP. Route Server menetapkan sesi BGP dengan keduanya dan menyebar ke setiap rekan rute yang dipelajari dari yang lain. Platform ini mengelola sesi BGP antara Route Server dan gateway jaringan virtual ExpressRoute. Pengguna tidak perlu mengonfigurasinya secara eksplisit, tetapi hanya untuk mengaktifkan AllowBranchToBranch bendera saat menyebarkan Route Server.

Gambar 7. Perambatan rute antara gateway jaringan virtual ExpressRoute dan NVA SD-WAN terjadi melalui BGP. Route Server menetapkan sesi BGP dengan dan menyebarkan rute di kedua arah saat dikonfigurasi dengan "AllowBranchToBranch=TRUE". Route Server bertindak sebagai reflektor rute, yaitu, itu bukan bagian dari jalur data.

Skenario koeksistensi SD-WAN dan ExpressRoute ini memungkinkan migrasi dari jaringan MPLS ke SD-WAN. Ini menawarkan jalur antara situs MPLS warisan dan situs SD-WAN yang baru dimigrasikan, menghilangkan kebutuhan untuk merutekan lalu lintas melalui pusat data lokal. Pola ini dapat digunakan tidak hanya selama migrasi tetapi juga dalam skenario yang timbul dari merger perusahaan dan akuisisi, menyediakan interkoneksi jaringan yang berbeda yang mulus.

Skenario #2: Expressroute sebagai underlay SD-WAN

Jika situs lokal Anda memiliki konektivitas ExpressRoute, Anda dapat mengonfigurasi perangkat SD-WAN untuk menyiapkan terowongan ke NVA hub SD-WAN yang berjalan di Azure di atas sirkuit atau sirkuit ExpressRoute. Konektivitas ExpressRoute dapat dilakukan melalui sirkuit titik-ke-titik atau jaringan MPLS. Anda dapat menggunakan peering privat ExpressRoute dan peering Microsoft.

Peering Pribadi

Saat Anda menggunakan peering privat ExpressRoute sebagai underlay, semua situs SD-WAN lokal membuat terowongan ke NVA hub SD-WAN di Azure. Tidak ada penyebaran rute antara NVA SD-WAN dan gateway jaringan virtual ExpressRoute yang diperlukan dalam skenario ini (yaitu, Route Server harus dikonfigurasi dengan bendera "AllowBranchToBranch" diatur ke false).

Pendekatan ini memerlukan konfigurasi BGP yang tepat pada router sisi pelanggan atau penyedia yang mengakhiri koneksi ExpressRoute. Bahkan, Microsoft Enterprise Edge Routers (MSEEs) mengumumkan semua rute untuk jaringan virtual yang terhubung ke sirkuit (baik secara langsung atau melalui peering jaringan virtual). Tetapi untuk meneruskan lalu lintas yang ditujukan ke jaringan virtual melalui terowongan SD-WAN, situs lokal harus mempelajari rute tersebut dari perangkat SD-WAN - bukan sirkuit ER.

Oleh karena itu, router sisi pelanggan atau sisi penyedia yang mengakhiri koneksi ExpressRoute harus memfilter rute yang diterima dari Azure. Satu-satunya rute yang dikonfigurasi dalam underlay harus rute yang memungkinkan perangkat SD-WAN lokal mencapai NVA hub SD-WAN di Azure. Pelanggan yang ingin menggunakan peering privat ExpressRoute sebagai underlay SD-WAN harus memverifikasi bahwa mereka dapat mengonfigurasi perangkat perutean mereka. Melakukannya sangat relevan bagi pelanggan yang tidak memiliki kontrol langsung atas perangkat edge mereka untuk ExpressRoute. Contohnya adalah ketika sirkuit ExpressRoute disediakan oleh operator MPLS di atas layanan IPVPN.

Gambar 8. Peering privat ExpressRoute sebagai underlay SD-WAN. Dalam skenario ini, router pelanggan dan sisi penyedia menerima rute untuk jaringan virtual yang mengakhiri koneksi ExpressRoute, dalam sesi BGP peering privat ER, dan CPE SD-WAN. Hanya CPE SD-WAN yang harus menyebarluaskan rute Azure ke LAN situs.

Peering Microsoft

Anda juga dapat menggunakan peering Microsoft ExpressRoute sebagai underlay untuk terowongan SD-WAN. Dalam skenario ini, NVA hub SD-WAN di Azure hanya mengekspos titik akhir terowongan publik, yang digunakan oleh kedua CPU SD-WAN di situs yang terhubung ke internet, jika ada, dan oleh CPU SD-WAN di situs yang terhubung dengan Expressroute. Meskipun peering Microsoft ExpressRoute memiliki prasyarat yang lebih kompleks daripada peering privat, sebaiknya gunakan opsi ini sebagai underlay karena dua keuntungan ini:

• Ini tidak memerlukan gateway jaringan virtual Expressroute di jaringan virtual hub. Ini menghapus kompleksitas, mengurangi biaya, dan memungkinkan solusi SD-WAN skala di luar batas bandwidth gateway itu sendiri ketika Anda tidak menggunakan ExpressRoute FastPath.

• Ini menyediakan pemisahan yang bersih antara rute overlay dan underlay. MSEEs hanya mengumumkan awalan publik jaringan Microsoft ke tepi pelanggan atau penyedia. Anda dapat mengelola rute tersebut di VRF terpisah dan menyebarkan hanya ke segmen DMZ LAN situs. Perangkat SD-WAN menyebarluaskan rute untuk jaringan perusahaan pelanggan dalam overlay, termasuk rute untuk jaringan virtual. Pelanggan yang mempertimbangkan pendekatan ini harus memverifikasi bahwa mereka dapat mengonfigurasi perangkat perutean mereka sesuai atau meminta layanan yang tepat ke operator MPLS mereka.

Pertimbangan MPLS

Migrasi dari jaringan perusahaan MPLS tradisional ke arsitektur jaringan yang lebih modern berdasarkan paradigma SD-WAN membutuhkan upaya yang signifikan dan sejumlah besar waktu. Arsitektur yang dijelaskan dalam artikel ini memungkinkan migrasi SD-WAN bertahas. Dua skenario migrasi umum dibahas nanti.

Penonaktifan MPLS bertahas

Pelanggan yang ingin membangun SD-WAN di atas internet publik dan backbone Microsoft, dan SEPENUHNYA menonaktifkan IPVPN MPLS atau layanan konektivitas khusus lainnya, dapat menggunakan skenario Koeksistensi ExpressRoute dan SD-WAN yang dijelaskan di bagian sebelumnya selama migrasi. Ini memungkinkan situs yang terhubung dengan SD-WAN untuk menjangkau situs yang masih terhubung ke MPLS warisan. Segera setelah situs dimigrasikan ke perangkat SD-WAN dan CPE disebarkan, tautan MPLS-nya dapat dinonaktifkan. Situs ini dapat mengakses seluruh jaringan perusahaan melalui terowongan SD-WAN-nya ke wilayah Azure terdekat.

Gambar 9. Skenario "ExpressRoute dan SD-WAN koeksistensi" memungkinkan penonaktifan MPLS bertahap.

Ketika semua situs dimigrasikan, MPLS IPVPN dapat dinonaktifkan, bersama dengan sirkuit ExpressRoute yang menghubungkannya ke backbone Microsoft. Gateway jaringan virtual ExpressRoute tidak lagi diperlukan dan dapat dibatalkan provisinya. NVA hub SD-WAN di setiap wilayah menjadi satu-satunya titik masuk ke jaringan hub dan spoke wilayah tersebut.

Integrasi MPLS

Organisasi yang tidak mempercayai jaringan publik dan bersama untuk memberikan performa dan keandalan yang diinginkan dapat memutuskan untuk menggunakan jaringan MPLS yang ada sebagai underlay kelas perusahaan. Dua opsinya adalah:

• Subset situs seperti pusat data atau kantor cabang besar.
• Subset koneksi, biasanya lalu lintas peka latensi atau misi penting.

Skenario Expressroute sebagai underlay SD-WAN yang dijelaskan sebelumnya memungkinkan integrasi SD-WAN dan MPLS. Peering Microsoft ExpressRoute harus lebih disukai daripada peering privat karena alasan yang dibahas sebelumnya. Selain itu, ketika peering Microsoft digunakan, jaringan MPLS dan internet publik menjadi underlay yang setara secara fungsional. Mereka menyediakan akses ke semua titik akhir terowongan SD-WAN yang diekspos oleh NVA hub SD-WAN di Azure. CPE SD-WAN yang disebarkan di situs dengan konektivitas internet dan MPLS dapat membangun beberapa terowongan ke hub SD-WAN di Azure pada kedua underlay. Mereka kemudian dapat merutekan koneksi yang berbeda melalui terowongan yang berbeda, berdasarkan kebijakan tingkat aplikasi yang dikelola oleh sarana kontrol SD-WAN.

Gambar 10. Skenario "ExpressRoute sebagai underlay SD-WAN" memungkinkan integrasi SD-WAN dan MPLS.

Preferensi perutean Route Server

Dalam kedua skenario MPLS yang tercakup dalam dua bagian sebelumnya, beberapa situs cabang dapat dihubungkan baik ke MPLS IPVPN maupun ke SD-WAN. Akibatnya, instans Route Server yang disebarkan di jaringan virtual hub dapat mempelajari rute yang sama dari Gateway ExpressRoute dan NVA SD-WAN. Preferensi perutean Route Server memungkinkan kontrol jalur mana yang harus disukai dan disematkan ke dalam tabel rute jaringan virtual. Preferensi perutean berguna ketika prepending Jalur AS tidak dapat digunakan. Contohnya adalah layanan MPLS IPVPN yang tidak mendukung konfigurasi BGP kustom pada PEs yang menghentikan koneksi ExpressRoute.

Batas Route Server dan pertimbangan desain

Route Server adalah landasan arsitektur yang dijelaskan dalam artikel ini. Ini menyebarkan rute antara NVA SD-WAN yang disebarkan di jaringan virtual dan tumpukan Azure SDN yang mendasar. Ini menyediakan pendekatan berbasis BGP untuk menjalankan beberapa NVA SD-WAN untuk ketersediaan tinggi dan skalabilitas horizontal. Ketika Anda merancang SD-WANs besar berdasarkan arsitektur ini, batas skalabilitas Route Server harus diperhitungkan.

Bagian berikut memberikan panduan tentang maksimum skalabilitas dan cara menangani setiap batas.

Rute yang diiklankan oleh peer BGP ke Route Server

Route Server tidak menentukan batas eksplisit untuk jumlah rute yang dapat diiklankan ke Gateway Jaringan Virtual ExpressRoute saat AllowBranchToBranch bendera diatur. Namun, Gateway ExpressRoute semakin menyebarluaskan rute yang mereka pelajari dari Route Server ke sirkuit ExpressRoute yang terhubung dengannya.

Ada batasan jumlah rute yang dapat diiklankan Gateway ExpressRoute ke sirkuit ExpressRoute melalui peering privat, yang didokumentasikan di batas langganan dan layanan Azure, kuota, dan batasan. Saat merancang solusi SD-WAN berdasarkan panduan dalam artikel ini, penting untuk memastikan bahwa rute SD-WAN tidak menyebabkan batas ini terpukul. Jika terpukul, sesi BGP antara Gateway ExpressRoute dan sirkuit ExpressRoute dihilangkan, dan konektivitas antara jaringan virtual dan jaringan jarak jauh yang terhubung melalui ExpressRoute hilang.

Jumlah total rute yang diiklankan ke sirkuit oleh Gateway ExpressRoute adalah jumlah jumlah rute yang dipelajari dari Route Server dan jumlah awalan yang membentuk hub Azure dan ruang alamat jaringan spoke. Untuk menghindari pemadaman karena sesi BGP yang dihentikan, kami sarankan Anda menerapkan mitigasi berikut:

• Gunakan fitur perangkat SD-WAN asli untuk membatasi jumlah rute yang diumumkan ke Route Server, jika fitur tersedia.
• Gunakan Pemberitahuan Azure Monitor untuk mendeteksi lonjakan jumlah rute yang diumumkan oleh Gateway ExpressRoute secara proaktif. Metrik yang akan dipantau diberi nama Count of Routes Advertised to Peer, seperti yang didokumentasikan dalam pemantauan ExpressRoute.

Rekan-rekan BGP

Route Server dapat membuat sesi BGP hingga jumlah maksimum serekan BGP. Batas ini menentukan jumlah maksimum NVA SD-WAN yang dapat menetapkan adjacencies BGP dengan Route Server, dan oleh karena itu throughput agregat maksimum yang dapat didukung di semua terowongan SD-WAN. Hanya SD-WAN besar yang diharapkan mencapai batas ini. Tidak ada solusi untuk mengatasinya, selain membuat beberapa jaringan hub dan spoke, masing-masing dengan gateway dan server rutenya sendiri.

VM yang berpartisipasi

Gateway Virtual Network dan Route Server mengonfigurasi rute yang mereka pelajari dari rekan jarak jauh mereka untuk semua VM di jaringan virtual mereka sendiri dan di jaringan virtual yang di-peering secara langsung. Untuk melindungi Route Server dari konsumsi sumber daya yang berlebihan karena pembaruan perutean ke VM, Azure menentukan batas jumlah VM yang dapat ada di satu hub dan jaringan spoke. Tidak ada solusi untuk mengatasi batas ini, selain membuat beberapa jaringan hub dan spoke, masing-masing dengan gateway dan server rutenya sendiri, di wilayah yang sama.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Federico Guerrini | Arsitek Solusi Cloud Senior
• Khush Kaviraj | Arsitek Solusi Cloud

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Kerangka Kerja Well-Architected Microsoft

Sumber daya terkait

• Menyambungkan jaringan lokal ke Azure menggunakan ExpressRoute
• Menyebarkan NVA yang sangat tersedia