ExpressRoute Yönlendirmeyi En iyi Duruma Getirme

Birden çok ExpressRoute bağlantı hattına sahip olduğunuzda, Microsoft'a bağlanmak için birden fazla yolunuz vardır. Sonuç olarak, yetersiz yönlendirme olabilir, diğer bir deyişle, trafiğinizin Microsoft’a ulaşması ve Microsoft’un ağınıza ulaşması daha uzun bir yol alabilir. Ne kadar uzun ağ yolu, o kadar yüksek gecikme. Gecikme süresi, uygulama performansı ve kullanıcı deneyimi üzerinde doğrudan etkiye sahiptir. Bu makalede bu sorun gösterilmekte ve standart yönlendirme teknolojilerini kullanarak yönlendirmenin nasıl iyileştirileceğini açıklanmaktadır.

Microsoft ve Genel eşleme için yol seçimi

Microsoft veya Genel eşleme kullanırken bir veya daha fazla ExpressRoute bağlantı hattınız varsa trafiğin istenen yol üzerinden aktığından emin olmak önemlidir. İnternet yollarının bir Internet Exchange (IX) veya İnternet Servis Sağlayıcısı (ISS) kullandığından da emin olmanız gerekir. BGP, en uzun ön ek eşleşmesi (LPM) dahil olmak üzere birçok faktöre dayalı olarak en iyi yol seçim algoritmalarını kullanır. Microsoft veya Genel eşleme aracılığıyla Azure'ı hedefleyen trafiğin ExpressRoute yolundan geçtiğinden emin olmak için Yerel Tercih özniteliğini uygulamanız gerekir. Bu ayar, yolun her zaman ExpressRoute'ta tercih edilmesini sağlar.

Not

Varsayılan yerel tercih genellikle 100'dür. Daha yüksek yerel tercihler daha çok tercih edilir.

Aşağıdaki örnek senaryoyu göz önünde bulundurun:

Yukarıdaki örnekte, ExpressRoute yollarını tercih etmek için Yerel Tercih'i aşağıdaki gibi yapılandırın.

R1 perspektifinden Cisco IOS-XE yapılandırması:

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

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

• BGP 345 #router R1(yapılandırma)

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

• R1(yapılandırma yönlendiricisi)#neighbor 1.1.1.2 etkinleştirme

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

R1 perspektifinden Junos yapılandırması:

• user@R1# protokolleri ayarlama bgp group ibgp türü iç
• user@R1# protokolleri ayarlama bgp group ibgp local-preference 150

Müşteriden Microsoft’a yetersiz yönlendirme

Bir örnekle yönlendirme problemine daha yakından bir bakalım. Biri Los Angeles ve diğeri New York’ta olmak üzere ABD’de iki ofisiniz olduğunu düşünün. Ofisleriniz, kendi omurga ağınız veya hizmet sağlayıcınızın IP VPN’i olabilen bir Geniş Alan Ağı (WAN) üzerine bağlıdır. Biri ABD Batı ve diğeri ABD Doğu’da olmak üzere iki ExpressRoute devreniz vardır. Her ikisi de WAN'a bağlıdır. Belli ki, Microsoft ağına bağlanmak için iki yolunuz vardır.

Şimdi hem ABD Batı hem de ABD Doğu'da bir Azure App Service gibi bir Azure dağıtımınız olduğunu düşünün. Amacınız Los Angeles'taki kullanıcılarınızı Azure ABD Batı'ya ve New York'taki kullanıcılarınızı Azure ABD Doğu'ya bağlamaktır. Bu kurulumun nedeni, hizmet yöneticinizin en iyi deneyimler için her ofisteki kullanıcıların yakındaki Azure hizmetlerine erişip erişemediğini tanıtmış olmasıdır. Plan doğu yakası kullanıcıları için iyi çalışıyor ancak batı yakası kullanıcıları için uygun değil.

Sorunun nedeni her ExpressRoute bağlantı hattındadır. Hem Azure ABD Doğu 23.100.0.0/16'daki ön eki hem de Azure ABD Batı 13.100.0.0/16'daki ön eki şirket içine tanıtıyoruz. Hangi ön ekin hangi bölgeden olduğunu bilmiyorsanız, bunu farklı şekilde ele alamazsınız. WAN ağınız her iki önekin de ABD Batı’dan daha çok ABD Doğu’ya yakın olduğunu düşünebilir ve bu nedenle, iki ofis kullanıcılarını da ABD Doğu’daki ExpressRoute bağlantı hattına yönlendirebilir. Sonunda, Los Angeles ofisinde birçok mutsuz kullanıcınız var.

Çözüm: BGP Toplulukları’nı kullanın

Her iki ofis kullanıcıları için yönlendirmeyi en iyi hale getirmek için, hangi önekin Azure ABD Batı ve Azure ABD Doğu olduğunu bilmeniz gerekir. Bu bilgileri BGP Topluluğu değerlerini kullanarak kodlarız. Her Azure bölgesine( örneğin 12076:51004 ABD Doğu 12076:51006 , ABD Batı için) benzersiz bir BGP Topluluğu değeri atadık. Artık hangi önekin hangi Azure bölgesinden olduğunu bildiğinize göre, tercih edilmesi gereken ExpressRoute bağlantı hattını yapılandırabilirsiniz. Yönlendirme bilgilerini değiştirmek için BGP'yi kullandığımızdan, yönlendirmeyi etkilemek için BGP'nin Yerel Tercihi'ni kullanabilirsiniz.

Bizim örneğimizde, ABD Batı’daki 13.100.0.0/16 için ABD Doğu’dan daha yüksek bir yerel tercih değeri atayabilir ve benzer şekilde, ABD Doğu’daki 23.100.0.0/16 için ABD Batı’dan daha yüksek bir yerel tercih değeri atayabilirsiniz. Bu yapılandırma, Microsoft'un her iki yolu da kullanılabilir olduğunda, Los Angeles'taki kullanıcılarınızın Azure ABD Batı'ya bağlanmak için ABD Batı'daki ExpressRoute bağlantı hattını almasını sağlarken, New York'taki kullanıcılarınız ABD Doğu'daki ExpressRoute'u Azure ABD Doğu'ya götürür. Her iki tarafta da yönlendirme en iyi duruma getirilmiştir.

Not

Yerel Tercih'i kullanarak aynı teknik, özel eşleme kullanılırken müşteriden Azure sanal ağına yönlendirmeye uygulanabilir. Microsoft, BgP topluluk değerlerini Azure'dan ağınıza tanıtılan ön eklere etiketlemez. Ancak, sanal ağ dağıtımınızdan hangisinin ofisinizden hangisine yakın olduğunu bildiğinizden, yönlendiricilerinizi bir ExpressRoute bağlantı hattını diğerine tercih etmek üzere uygun şekilde yapılandırabilirsiniz.

Microsoft'tan müşteriye yetersiz yönlendirme

Bu örnekte, Ağınıza ulaşmak için Microsoft'tan daha uzun bir yol alan bağlantılarımız vardır. Bu durumda, karma bir ortamda şirket içi Exchange sunucularını ve Exchange Online kullanın. Ofisleriniz bir WAN’a bağlıdır. her iki ofisinizdeki şirket içi sunucularınızın ön eklerini iki ExpressRoute bağlantı hattı aracılığıyla Microsoft'a tanıtabilirsiniz.

Exchange Online, posta kutusu geçişi gibi durumlarda şirket içi sunuculara bağlantılar başlatır. Los Angeles ofisinizle bağlantı, tüm kıtayı batı yakasına geri dönmeden önce ABD Doğu'daki ExpressRoute bağlantı hattına yönlendirilir. Sorunun nedeni birinciye benzemektedir. Herhangi bir ipucu olmadan, Microsoft ağı hangi şirket içi ön ekin ABD Doğu'ya ve hangisinin ABD Batı'ya yakın olduğunu anlayamaz. Los Angeles’taki ofisiniz için yanlış yolu seçmiş olabilirsiniz.

Çözüm: AS YOLU eklenmesini kullanın

Bu sorunun iki çözümü vardır. İlki, ABD Batı'daki ExpressRoute bağlantı hattında Los Angeles office 177.2.0.0/31 için şirket içi ön ekinizi tanıtmanızdır. Ardından New York ofisinizin 177.2.0.2/31 olan şirket içi ön ekini ABD Doğu'daki ExpressRoute bağlantı hattında tanıtacaksınız. Sonuç olarak, Microsoft'un ofislerinizin her birine bağlanması için tek bir yol vardır. Belirsizlik yoktur ve yönlendirme iyileştirilmiştir. Bu tasarımla, yük devretme stratejinizi düşünmeniz gerekir. Microsoft'un ExpressRoute üzerinden giden yolu kapatıyorsa, Exchange Online şirket içi sunucularınıza hala bağlanaabildiğinden emin olmanız gerekir.

İkinci çözüm, her iki ExpressRoute bağlantı hattında iki öneki de tanıtmaya devam etmeniz ve buna ek olarak, hangi önekin hangi ofisinize daha yakın olduğu ile ilgili bize ipucu vermenizdir. BGP AS Yolu eklenmesini desteklediğimizden, yönlendirmeyi etkilemek için önekiniz için AS Yolu’nu yapılandırabilirsiniz. Bu örnekte ABD Doğu'da AS PATH değerini 172.2.0.0/31 için uzatabilirsiniz, böylece bu ön eki hedefleyen trafik için ABD Batı'daki ExpressRoute bağlantı hattını tercih ederiz. Benzer şekilde ABD Batı'da 172.2.0.2/31 için AS PATH değerini uzatabilirsiniz, böylece ABD Doğu'daki ExpressRoute bağlantı hattını tercih edebiliriz. Her iki ofis için de yönlendirme en iyi duruma getirilmiştir. Bu tasarımla, bir ExpressRoute bağlantı hattı bozuk ise, Exchange Online başka bir ExpressRoute bağlantı hattı ve WAN’ınız aracılığıyla yine de size ulaşabilir.

Önemli

Özel BIR AS numarası kullanarak eşleme yaparken Microsoft Eşlemesi'nde alınan ön ekler için AS YOLUNDAki özel AS numaralarını kaldırırız. Microsoft Eşlemesi'nin yönlendirmesini etkilemek için genel bir AS ile eşlemeniz ve AS YOLU'na genel AS numaraları eklemeniz gerekir.

Not

Burada verilen örnekler Microsoft ve Ortak eşlemelere yöneliktir, ancak Özel eşleme için de aynı özellikleri destekleriz. Ayrıca AS Yolu ekleme, birincil ve ikincil yolların seçimini etkilemek için tek bir ExpressRoute devresi içinde çalışır.

Sanal ağlar arasında yetersiz yönlendirme

ExpressRoute ile Sanal Ağdan Sanal Ağa (aynı zamanda "VNet" olarak bilinir) iletişimi bir ExpressRoute devresine bağlayarak etkinleştirebilirsiniz. Birden fazla ExpressRoute devresine bağladığınızda, sanal ağlar arasında yetersiz yönlendirme gerçekleşebilir. Bir örnek düşünelim. Biri ABD Batı ve diğeri ABD Doğu’da olmak üzere iki ExpressRoute devreniz vardır. Her bölgede, iki sanal ağınız vardır. Web sunucularınız bir sanal ağa, uygulama sunucularınız diğerine dağıtılmaktadır. Artıklık için her bölgedeki iki sanal ağı hem yerel ExpressRoute devresine hem de uzak ExpressRoute devresine bağlarsınız. Aşağıdaki diyagramda da görüldüğü gibi, her sanal ağdan diğer sanal ağa giden iki yol vardır. Sanal ağlar, hangi ExpressRoute devresinin yerel, hangisinin uzak olduğunu bilmez. Sanal ağlar arası trafiğin yükünü dengelemek için Eşit Maliyetli Çoklu Yol (ECMP) yönlendirmesi kullanıldığından, bazı trafik akışları daha uzun yolu alır ve uzak ExpressRoute bağlantı hattına yönlendirilir.

Çözüm: yerel bağlantıya yüksek ağırlık atayın

Çözüm basittir. Sanal ağların ve bağlantı hatlarının nerede olduğunu bildiğiniz için, her bir sanal ağın hangi yolu tercih etmesi gerektiğini siz belirleyebilirsiniz. Özellikle bu örnek için, yerel bağlantıya atadığınız ağırlık, uzak bağlantıya atadığınız ağırlıktan daha yüksek olmalıdır (buradaki yapılandırma örneğine bakın). Bir sanal ağ birden çok bağlantıda diğer sanal ağın ön ekini aldığında, bu ön eki hedefleyen trafiği göndermek için en yüksek ağırlığa sahip bağlantıyı tercih eder.

Not

Ayrıca, birden çok ExpressRoute bağlantı hattınız varsa, ikinci senaryoda açıklanan bir teknik olan AS PATH önkoşulunu uygulamak yerine bir bağlantının ağırlığını yapılandırarak sanal ağdan şirket içi ağınıza yönlendirmeyi de etkileyebilirsiniz. Her ön ek için, trafiğin nasıl gönderileceğine karar verirken AS Yolu uzunluğundan önce mutlaka bağlantı ağırlığına bakmanız gerekir.

Sonraki adımlar

• ExpressRoute'u yüksek kullanılabilirlik için tasarlama hakkında bilgi edinin.
• Olağanüstü durum kurtarma için ExpressRoute tasarlama hakkında bilgi edinin.