Optymalizacja routingu usługi ExpressRoute
Jeśli masz wiele obwodów usługi ExpressRoute, masz więcej niż jedną ścieżkę łączenia z firmą Microsoft. W związku z tym może wystąpić routing nieoptymalny, tzn. ruch może użyć dłuższej ścieżki w celu dotarcia do firmy Microsoft lub z firmy Microsoft do sieci użytkownika. Im dłuższa ścieżka sieciowa, tym większe opóźnienie. Opóźnienie ma bezpośredni wpływ na wydajność aplikacji i środowisko użytkownika. W tym artykule przedstawiono ten problem i wyjaśniono, jak zoptymalizować routing przy użyciu standardowych technologii routingu.
Wybór ścieżki dla komunikacji równorzędnej firmy Microsoft
Należy upewnić się, że w przypadku korzystania z firmy Microsoft ruch przepływa przez żądaną ścieżkę, jeśli masz co najmniej jeden obwód usługi ExpressRoute. Należy również upewnić się, że ścieżki do Internetu korzystają z internetowego programu Internet Exchange (IX) lub usługodawcy internetowego (ISP). Protokół BGP wykorzystuje najlepszy algorytm wyboru ścieżki na podstawie wielu czynników, w tym najdłuższego dopasowania prefiksu (LPM). Aby upewnić się, że ruch przeznaczony dla platformy Azure przez firmę Microsoft przechodzi przez ścieżkę usługi ExpressRoute, musisz zaimplementować atrybut Preferencja lokalna. To ustawienie zapewnia, że ścieżka jest zawsze preferowana w usłudze ExpressRoute.
Uwaga
Domyślna preferencja lokalna to zazwyczaj 100. Wyższe preferencje lokalne są bardziej preferowane.
Rozważmy następujący scenariusz przykładowy:
W powyższym przykładzie, aby preferować ścieżki usługi ExpressRoute, skonfiguruj preferencję lokalną w następujący sposób.
Konfiguracja cisco IOS-XE z perspektywy R1:
R1(config)#route-map prefer-ExR permit 10
R1(config-route-map)#set preferencji lokalnej 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 aktywowanie
R1(config-router)#neighbor 1.1.1.2 route-map prefer-exR in
Konfiguracja junos z perspektywy R1:
- user@R1# zestaw protokołów bgp grupy ibgp typu wewnętrznego
- user@R1# zestaw protokołów bgp grupy ibgp preferencji lokalnej 150
Suboptymalny routing od klienta do firmy Microsoft
Przyjrzyjmy się problemowi z routingiem, korzystając z przykładu. Załóżmy, że masz dwa biura w USA: jedno w Los Angeles i jedno w Nowym Jorku. Biura są połączone za pośrednictwem sieci WAN, która może być Twoją siecią podstawową lub siecią IP VPN dostawcy usług. Dostępne są dwa obwody usługi ExpressRoute: jeden w zachodnich stanach USA i jeden we wschodnich stanach USA. Oba są również połączone w sieci WAN. Oczywiście masz dwie ścieżki połączenia z siecią firmy Microsoft.
Teraz wyobraź sobie, że masz wdrożenie platformy Azure, na przykład usługę aplikacja systemu Azure w regionie Zachodnie stany USA i Wschodnie stany USA. Twoim zamiarem jest połączenie użytkowników w Los Angeles z regionem Zachodnie stany USA platformy Azure i użytkownikami w Nowym Jorku z regionem Wschodnie stany USA platformy Azure. Przyczyną tej konfiguracji jest to, że administrator usługi anonsuje, że użytkownicy w każdym biurze uzyskują dostęp do pobliskich usług platformy Azure w celu uzyskania optymalnych środowisk. Plan działa dobrze dla użytkowników wschodniego wybrzeża, ale nie dla użytkowników zachodniego wybrzeża.
Przyczyną problemu jest w każdym obwodzie usługi ExpressRoute, anonsujemy do lokalnego prefiksu zarówno w regionie Wschodnie stany USA platformy Azure 23.100.0.0/16, jak i prefiks w regionie Zachodnie stany USA platformy Azure 13.100.0.0/16. Jeśli nie wiesz, który prefiks pochodzi z którego regionu, nie możesz go traktować inaczej. Sieć WAN może uznać, że oba prefiksy są bliżej wschodnich niż zachodnich stanów USA, i skierować obu użytkowników biura do obwodu usługi ExpressRoute we wschodnich stanach USA. W końcu masz wielu niezadowolonych użytkowników w biurze w Los Angeles.
Rozwiązanie: użyj społeczności BGP
Aby zoptymalizować routing dla użytkowników obu biur, trzeba wiedzieć, który prefiks odpowiada zachodnim, a który wschodnim stanom USA. Kodujemy te informacje przy użyciu wartości społeczności BGP. Do każdego regionu świadczenia usługi Azure przypisano unikatową wartość społeczności protokołu BGP, na przykład 12076:51004 Wschodnie 12076:51006 stany USA dla regionu Zachodnie stany USA. Skoro już wiesz, który prefiks odpowiada któremu regionowi świadczenia usługi Azure, możesz skonfigurować preferowany obwód usługi ExpressRoute. Ponieważ używamy protokołu BGP do wymiany informacji o routingu, możesz użyć preferencji lokalnej protokołu BGP, aby wpłynąć na routing.
W naszym przykładzie można przypisać wyższą wartość preferencji lokalnej na 13.100.0.0/16 w zachodnich niż we wschodnich stanach USA i podobnie wyższą wartość preferencji lokalnej na 23.100.0.0/16 we wschodnich niż w zachodnich stanach USA. Ta konfiguracja zapewnia, że gdy obie ścieżki do firmy Microsoft są dostępne, użytkownicy w Los Angeles pobiera obwód usługi ExpressRoute w regionie Zachodnie stany USA, aby nawiązać połączenie z platformą Azure US West, podczas gdy użytkownicy w Nowym Jorku korzystają z usługi ExpressRoute w regionie Wschodnie stany USA na platformie Azure wschodnie stany USA. Routing jest zoptymalizowany po obu stronach.
Uwaga
Ta sama technika, korzystając z preferencji lokalnych, może być stosowana do routingu z klienta do sieci wirtualnej platformy Azure podczas korzystania z prywatnej komunikacji równorzędnej. Firma Microsoft nie oznacza wartości społeczności protokołu BGP do prefiksów anonsowanych z platformy Azure do sieci. Jednak ponieważ wiesz, które z wdrożeń sieci wirtualnej znajduje się blisko którego z biura, możesz odpowiednio skonfigurować routery, aby preferować jeden obwód usługi ExpressRoute przez inny.
Suboptymalny routing od firmy Microsoft do klienta
W tym przykładzie mamy połączenia od firmy Microsoft, które mają dłuższą ścieżkę dotarcia do sieci. W tym przypadku używasz lokalnych serwerów programu Exchange i usługi Exchange Online w środowisku hybrydowym. Biura są połączone z siecią WAN. Prefiksy serwerów lokalnych są anonsowane w obu biurach do firmy Microsoft za pośrednictwem dwóch obwodów usługi ExpressRoute.
Usługa Exchange Online inicjuje połączenia z serwerami lokalnymi w przypadkach takich jak migracja skrzynki pocztowej. Połączenie z biurem w Los Angeles jest kierowane do obwodu usługi ExpressRoute w regionie Wschodnie stany USA przed przejściem przez cały kontynent z powrotem na zachodnie wybrzeże. Przyczyna tego problemu jest podobna do pierwszej. Bez żadnej wskazówki sieć firmy Microsoft nie może stwierdzić, który prefiks lokalny znajduje się w pobliżu wschodnich stanów USA i który z nich znajduje się w pobliżu zachodnich stanów USA. Czasami wybiera nieprawidłową ścieżkę do biura w Los Angeles.
Rozwiązanie: użyj dołączania ścieżki AS
Istnieją dwa rozwiązania tego problemu. Pierwszy to po prostu anonsowanie lokalnego prefiksu dla biura w Los Angeles 177.2.0.0/31 w obwodzie usługi ExpressRoute w regionie Zachodnie stany USA. Następnie anonsujesz prefiks lokalny dla biura w Nowym Jorku, 177.2.0.2/31 w obwodzie usługi ExpressRoute w regionie Wschodnie stany USA. W związku z tym istnieje tylko jedna ścieżka do połączenia firmy Microsoft z poszczególnymi biurami. Nie ma niejednoznaczności i routing jest zoptymalizowany. Dla tego projektu należy przemyśleć strategię pracy awaryjnej. Jeśli ścieżka do firmy Microsoft za pośrednictwem usługi ExpressRoute ulegnie awarii, upewnij się, że usługa Exchange Online nadal może łączyć się z serwerami lokalnymi.
Drugim rozwiązaniem jest dalsze anonsowanie obu prefiksów w obu obwodach usługi ExpressRoute i dodatkowo podawanie wskazówki z informacją, który prefiks jest blisko którego biura. Ponieważ firma Microsoft obsługuje ścieżkę AS BGP do wywołania, można skonfigurować ścieżkę AS dla prefiksu, aby wpłynąć na routing. W tym przykładzie można wydłużyć ścieżkę AS dla 172.2.0.0/31 w regionie Wschodnie stany USA, abyśmy preferowali obwód usługi ExpressRoute w regionie Zachodnie stany USA dla ruchu przeznaczonego dla tego prefiksu. Podobnie można wydłużyć ścieżkę AS dla 172.2.0.2/31 w regionie Zachodnie stany USA, aby preferować obwód usługi ExpressRoute w regionie Wschodnie stany USA. Routing zostaje zoptymalizowany dla obu biur. W tym projekcie jeśli jeden obwód usługi ExpressRoute zostanie uszkodzony, usługa Exchange Online może nadal uzyskać dostęp do użytkownika za pośrednictwem innego obwodu usługi ExpressRoute i sieci WAN.
Ważne
Usuwamy prywatne numery AS w ścieżce AS dla prefiksów odebranych w komunikacji równorzędnej firmy Microsoft podczas komunikacji równorzędnej przy użyciu prywatnego numeru AS. Aby wpłynąć na routing komunikacji równorzędnej dla komunikacji równorzędnej firmy Microsoft, musisz połączyć publiczne numery AS i dołączyć publiczne numery AS w ścieżce AS.
Uwaga
Chociaż przykłady podane tutaj dotyczą komunikacji równorzędnej firmy Microsoft, obsługujemy te same możliwości prywatnej komunikacji równorzędnej. Ponadto dołączanie ścieżki AS działa w obrębie pojedynczego obwodu usługi ExpressRoute i wpływa na wybór ścieżek podstawowej i pomocniczej.
Suboptymalny routing między sieciami wirtualnymi
Usługa ExpressRoute umożliwia skonfigurowanie usługi Virtual Network pod kątem komunikacji za pośrednictwem sieci wirtualnych przez połączenie ich z obwodem usługi ExpressRoute. W przypadku połączenia sieci wirtualnych z wieloma obwodami usługi ExpressRoute między sieciami wirtualnymi może wystąpić suboptymalny routing. Rozważmy przykład. Dostępne są dwa obwody usługi ExpressRoute: jeden w zachodnich stanach USA i jeden we wschodnich stanach USA. W każdym regionie znajdują się dwie sieci wirtualne. W jednej sieci wirtualnej są wdrożone serwery sieci Web, a w drugiej — serwery aplikacji. W celu zapewnienia nadmiarowości dwie sieci wirtualne w każdym regionie są połączone z lokalnym obwodem usługi ExpressRoute i zdalnym obwodem usługi ExpressRoute. Jak widać na poniższym diagramie, z każdej sieci wirtualnej istnieją dwie ścieżki do drugiej sieci wirtualnej. W ramach połączenia sieci wirtualnych nie wiadomo, który obwód usługi ExpressRoute jest lokalny, a który zdalny. Ponieważ routing equal-Cost-Multi-Path (ECMP) służy do równoważenia obciążenia ruchu między sieciami wirtualnymi, niektóre przepływy ruchu zajmują dłuższą ścieżkę i są kierowane do zdalnego obwodu usługi ExpressRoute.
Rozwiązanie: przypisanie wysokiej wagi połączeniu lokalnemu
Rozwiązanie jest proste. Ponieważ wiadomo, gdzie znajdują się sieci wirtualne i obwody, można określić preferowaną ścieżkę dla poszczególnych sieci wirtualnych. Na potrzeby tego przykładu połączeniu lokalnemu jest przypisywana wyższa waga niż połączeniu zdalnemu (zobacz przykład konfiguracji tutaj). Gdy sieć wirtualna odbiera prefiks innej sieci wirtualnej w wielu połączeniach, preferuje połączenie z najwyższą wagą do wysyłania ruchu przeznaczonego dla tego prefiksu.
Uwaga
Możesz również wpływać na routing z sieci wirtualnej do sieci lokalnej, jeśli masz wiele obwodów usługi ExpressRoute, konfigurując wagę połączenia zamiast stosowania dołączania ścieżki AS, technikę opisaną w drugim scenariuszu. Podczas określania trasy danych w przypadku wszystkich prefiksów waga połączenia ma zawsze pierwszeństwo przed długością ścieżki AS.
Następne kroki
- Dowiedz się więcej o projektowaniu usługi ExpressRoute pod kątem wysokiej dostępności.
- Dowiedz się więcej o projektowaniu usługi ExpressRoute na potrzeby odzyskiwania po awarii.