Mengoptimalkan Perutean ExpressRoute

Saat Anda memiliki beberapa sirkuit ExpressRoute, Anda memiliki lebih dari satu jalur untuk terhubung ke Microsoft. Akibatnya, perutean suboptimal dapat terjadi - yaitu, lalu lintas Anda mungkin membutuhkan jalur yang lebih panjang untuk menjangkau Microsoft, dan Microsoft ke jaringan Anda. Semakin panjang jalur jaringan, semakin tinggi latensinya. Latensi memiliki efek langsung pada performa aplikasi dan pengalaman pengguna. Artikel ini menggambarkan masalah ini dan menjelaskan cara mengoptimalkan perutean menggunakan teknologi perutean standar.

Pemilihan jalur untuk peering Microsoft dan Publik

Penting untuk memastikan bahwa saat menggunakan peering Microsoft atau Publik bahwa arus lalu lintas di atas jalur yang diinginkan jika Anda memiliki satu atau beberapa sirkuit ExpressRoute. Anda juga perlu memastikan jalur ke Internet menggunakan Internet Exchange (IX) atau Penyedia Layanan Internet (ISP). BGP menggunakan algoritma pemilihan jalur terbaik berdasarkan banyak faktor termasuk kecocokan awalan terpanjang (LPM). Untuk memastikan bahwa lalu lintas yang ditujukan untuk Azure melalui Peering Microsoft atau Publik melintasi jalur ExpressRoute, Anda harus menerapkan atribut Preferensi Lokal . Pengaturan ini memastikan bahwa jalur selalu lebih disukai di ExpressRoute.

Catatan

Preferensi lokal default biasanya 100. Preferensi lokal yang lebih tinggi lebih disukai.

Pertimbangkan skenario contoh berikut:

Dalam contoh di atas, untuk lebih memilih jalur ExpressRoute, konfigurasikan Preferensi Lokal sebagai berikut.

Konfigurasi Cisco IOS-XE dari perspektif R1:

• R1(config)#route-map prefer-ExR permit 10

• R1(config-route-map)#set local-preference 150

• R1(config)#router BGP 345

• R1(config-router)#neighbor 1.1.1.2 remote-as 12076

• R1(config-router)#neighbor 1.1.1.2 aktifkan

• R1(config-router)#neighbor 1.1.1.2 route-map prefer-ExR in

Konfigurasi Junos dari perspektif R1:

• user@R1# mengatur protokol bgp group ibgp jenis internal
• user@R1# mengatur protokol bgp group ibgp preferensi lokal 150

Perutean suboptimal dari pelanggan ke Microsoft

Mari kita lihat lebih dekat masalah perutean dengan contoh. Bayangkan Anda memiliki dua kantor di AS, satu di Los Angeles dan satu di New York. Kantor Anda terhubung di Wide Area Network (WAN), yang dapat berupa jaringan backbone Anda sendiri atau VPN IP penyedia layanan Anda. Anda memiliki dua sirkuit ExpressRoute, satu di US Barat dan satu di US Timur. Keduanya juga terhubung pada WAN. Tentu saja Anda memiliki dua jalur untuk terhubung ke jaringan Microsoft.

Sekarang bayangkan Anda memiliki penyebaran Azure, misalnya, Azure App Service di US Barat dan US Timur. Tujuan Anda adalah menghubungkan pengguna Anda di Los Angeles ke Azure US Barat dan pengguna Anda di New York ke Azure US Timur. Alasan pengaturan ini adalah karena admin layanan Anda mengiklankan bahwa pengguna di setiap kantor mengakses layanan Azure terdekat untuk pengalaman yang optimal. Rencana ini berhasil dengan baik untuk pengguna pantai timur tetapi tidak untuk pengguna pantai barat.

Penyebab masalah ada di setiap sirkuit ExpressRoute, kami beriklan ke lokal baik awalan di Azure US Timur 23.100.0.0/16 dan awalan di Azure US Barat 13.100.0.0/16. Jika Anda tidak tahu awalan mana yang berasal dari wilayah mana, Anda tidak dapat memperlakukannya secara berbeda. Jaringan WAN Anda mungkin berpikir bahwa kedua prefiks lebih dekat ke US Timur daripada US Barat dan karena itu merutekan kedua pengguna kantor ke sirkuit ExpressRoute di AS Timur. Pada akhirnya, Anda memiliki banyak pengguna yang tidak bahagia di kantor Los Angeles.

Solusi: gunakan Komunitas BGP

Untuk mengoptimalkan perutean untuk kedua pengguna office, Anda perlu mengetahui prefiks mana yang berasal dari Azure US Barat dan mana dari Azure US Timur. Kami menyandikan informasi ini dengan menggunakan nilai Komunitas BGP. Kami telah menetapkan nilai Komunitas BGP unik untuk setiap wilayah Azure, misalnya 12076:51004 untuk US Timur, 12076:51006 untuk US Barat. Sekarang setelah Anda mengetahui prefiks mana yang berasal dari wilayah Azure mana, Anda dapat mengonfigurasi sirkuit ExpressRoute mana yang harus dipilih. Karena kami menggunakan BGP untuk bertukar info perutean, Anda dapat menggunakan Preferensi Lokal BGP untuk memengaruhi perutean.

Dalam contoh kami, Anda dapat menetapkan nilai preferensi lokal yang lebih tinggi ke 13.100.0.0/16 di US Barat daripada di US Timur, dan demikian pula, nilai preferensi lokal yang lebih tinggi ke 23.100.0.0/16 di US Timur daripada di US Barat. Konfigurasi ini memastikan bahwa, ketika kedua jalur ke Microsoft tersedia, pengguna Anda di Los Angeles mengambil sirkuit ExpressRoute di US Barat untuk terhubung ke Azure US Barat sedangkan pengguna Anda di New York mengambil ExpressRoute di US Timur ke Azure US Timur. Perutean dioptimalkan di kedua sisi.

Catatan

Teknik yang sama, yaitu menggunakan Preferensi Lokal, dapat diterapkan untuk perutean dari pelanggan ke jaringan virtual Azure ketika menggunakan peering privat. Microsoft tidak menandai nilai komunitas BGP ke prefiks yang ditetapkan dari Azure ke jaringan Anda. Namun, karena Anda tahu penyebaran jaringan virtual mana yang dekat dengan kantor mana, Anda dapat mengonfigurasi router agar memilih satu sirkuit ExpressRoute daripada sirkuit lainnya.

Perutean suboptimal dari Microsoft ke Pelanggan

Dalam contoh ini, kami memiliki koneksi dari Microsoft yang membutuhkan jalur yang lebih panjang untuk menjangkau jaringan Anda. Dalam hal ini, Anda menggunakan server Exchange lokal dan Exchange Online di lingkungan hibrid. Kantor Anda terhubung ke WAN. Anda mengiklankan awalan server lokal Anda di kedua kantor Anda ke Microsoft melalui dua sirkuit ExpressRoute.

Exchange Online memulai koneksi ke server lokal dalam kasus seperti migrasi kotak surat. Koneksi ke kantor Los Angeles Anda dialihkan ke sirkuit ExpressRoute di US Timur sebelum melintasi seluruh benua kembali ke pantai barat. Penyebab masalahnya mirip dengan yang pertama. Tanpa petunjuk apa pun, jaringan Microsoft tidak dapat mengetahui awalan lokal mana yang dekat dengan US Timur dan mana yang dekat dengan US Barat. Jaringan ini kebetulan memilih jalan yang salah ke kantor Anda di Los Angeles.

Solusi: gunakan prepending AS PATH

Ada dua solusi untuk masalah ini. Yang pertama adalah Anda hanya mengiklankan awalan lokal Anda untuk kantor Los Angeles Anda 177.2.0.0/31 di sirkuit ExpressRoute di US Barat. Kemudian Anda mengiklankan awalan lokal Anda untuk kantor New York Anda, 177.2.0.2/31 di sirkuit ExpressRoute di US Timur. Akibatnya, hanya ada satu jalur bagi Microsoft untuk terhubung ke setiap kantor Anda. Tidak ada ambiguitas dan perutean yang dioptimalkan. Dengan desain ini, Anda perlu memikirkan strategi kegagalan Anda. Jika jalur ke Microsoft melalui ExpressRoute tidak berfungsi, Anda perlu memastikan bahwa Exchange Online masih dapat tersambung ke server lokal Anda.

Solusi kedua adalah Anda terus menetapkan kedua prefiks di kedua sirkuit ExpressRoute, dan selain itu Anda memberi kami petunjuk prefiks mana yang dekat dengan salah satu kantor Anda. Karena kami mendukung prepending BGP AS Path, Anda dapat mengonfigurasi AS Path agar prefiks Anda memengaruhi perutean. Dalam contoh ini, Anda dapat memperpanjang AS PATH untuk 172.2.0.0/31 di US Timur sehingga kami lebih suka sirkuit ExpressRoute di US Barat untuk lalu lintas yang ditujukan untuk awalan ini. Demikian pula Anda dapat memperpanjang AS PATH untuk 172.2.0.2/31 di US Barat sehingga kami lebih suka sirkuit ExpressRoute di US Timur. Perutean dioptimalkan untuk kedua kantor. Dengan desain ini, jika satu sirkuit ExpressRoute rusak, Exchange Online masih dapat menjangkau Anda melalui sirkuit ExpressRoute lain dan WAN Anda.

Penting

Kami menghapus nomor AS pribadi di AS PATH untuk prefiks yang diterima di Microsoft Peering saat melakukan serekan menggunakan nomor AS pribadi. Anda perlu melakukan serekan dengan AS publik dan menambahkan nomor AS publik di AS PATH untuk memengaruhi perutean pada Microsoft Peering.

Catatan

Meskipun contoh yang diberikan di sini adalah untuk serekan Microsoft dan Publik, kami mendukung kemampuan yang sama untuk serekan Privat. Selain itu, prepending AS Path bekerja dalam satu sirkuit ExpressRoute, untuk memengaruhi pemilihan jalur utama dan sekunder.

Perutean suboptimal antara jaringan virtual

Dengan ExpressRoute, Anda dapat mengaktifkan komunikasi Virtual Network ke Virtual Network (yang juga dikenal sebagai "VNet") dengan menautkannya ke sirkuit ExpressRoute. Saat Anda menautkannya ke beberapa sirkuit ExpressRoute, perutean suboptimal dapat terjadi di antara VNet. Mari lihat contoh berikut. Anda memiliki dua sirkuit ExpressRoute, satu di US Barat dan satu di US Timur. Di setiap wilayah, Anda memiliki dua VNet. Server web Anda disebarkan di satu server VNet dan aplikasi di server lain. Untuk redundansi, Anda menautkan dua VNet di setiap wilayah ke sirkuit ExpressRoute lokal dan sirkuit ExpressRoute jarak jauh. Seperti yang dapat dilihat dalam diagram berikut, dari setiap VNet ada dua jalur ke VNet lainnya. VNet tidak tahu sirkuit ExpressRoute mana yang lokal dan mana yang jarak jauh. Karena perutean Equal-Cost-Multi-Path (ECMP) digunakan untuk menyeimbangkan beban lalu lintas antar-VNet, beberapa arus lalu lintas mengambil jalur yang lebih panjang dan dirutekan di sirkuit ExpressRoute jarak jauh.

Solusi: tetapkan bobot tinggi ke koneksi lokal

Solusinya sederhana. Karena Anda tahu di mana VNet dan sirkuit berada, Anda dapat memberi tahu kami jalur mana yang harus dipilih setiap VNet. Khusus untuk contoh ini, Anda menetapkan bobot yang lebih tinggi ke koneksi lokal daripada koneksi jarak jauh (lihat contoh konfigurasi di sini). Ketika VNet menerima awalan VNet lain pada beberapa koneksi, VNet lebih suka koneksi dengan bobot tertinggi untuk mengirim lalu lintas yang ditujukan untuk prefiks tersebut.

Catatan

Anda juga dapat memengaruhi perutean dari VNet ke jaringan lokal Anda, jika Anda memiliki beberapa sirkuit ExpressRoute, dengan mengonfigurasi bobot koneksi alih-alih menerapkan prepending AS PATH, teknik yang dijelaskan dalam skenario kedua. Untuk setiap prefiks, kita akan selalu melihat bobot koneksi terlebih dulu sebelum panjang AS Path ketika memutuskan cara mengirim lalu lintas.

Langkah berikutnya

• Pelajari tentang merancang ExpressRoute untuk ketersediaan tinggi.
• Pelajari tentang merancang ExpressRoute untuk pemulihan bencana.