Integracja sdWAN z topologiami sieci piasty i szprych platformy Azure

Azure ExpressRoute

Azure VPN Gateway

Azure Virtual Network

Ten artykuł jest przeznaczony dla architektów sieci, którzy chcą zaprojektować zdefiniowane programowo sieci rozległe (SD-WANs) w celu łączenia obiektów lokalnych ze sobą i z platformą Azure. Opisuje ona architekturę, która umożliwia klientom platformy Azure korzystanie z istniejących inwestycji na platformie przez tworzenie wydajnych, globalnych nakładek SD-WAN na podstawie szkieletu firmy Microsoft.

Odpowiednie scenariusze

Zalecenia w tym artykule są niezależne od dostawcy i mają zastosowanie do dowolnej technologii SD-WAN firmy innej niż Microsoft, która spełnia dwa podstawowe wymagania wstępne:

Poleganie na protokołach tunelowania korzystających z protokołu TCP (Transmission Control Protocol) lub Protokołu UDP (User Datagram Protocol) jako podstawowego transportu, takiego jak protokół IPsec ESP w trybie tunelu z translatorem adresów sieciowych( NAT-Traversal).
Obsługa protokołu BGP (Border Gateway Protocol) w wersji 4 na potrzeby wymiany tras z jednostkami zewnętrznymi. Żadne założenia nie są stosowane w protokole routingu używanym przez urządzenia inne niż Microsoft SD-WAN do wymiany informacji o routingu między sobą.

Klienci, którzy przestrzegają tych zaleceń, mogą użyć wybranej technologii SD-WAN, aby osiągnąć następujące cele:

Zintegruj produkty SD-WAN w istniejącej sieci piasty i szprych platformy Azure, automatyzując wymianę tras między urządzeniami azure Virtual Network i SD-WAN.
Zoptymalizuj łączność (zarówno z platformą Azure, jak i lokalnymi centrami danych) dla gałęzi z lokalnymi przerwami w Internecie. Zasięg sieci szkieletowej firmy Microsoft w połączeniu z jego pojemnością, odpornością i zasadami routingu "zimnych ziemniaków" sugeruje, że może być używany jako nakładka o wysokiej wydajności dla globalnych sieci SD-WANs.
Użyj sieci szkieletowej firmy Microsoft dla całego ruchu między platformami Azure i platformy Azure (między regionami i lokalizacjami geograficznymi).
Użyj istniejących sieci mpLS (Multi-Protocol-Label-Switching) jako nakładek o wysokiej wydajności. Można go również użyć do zastąpienia istniejącej sieci MPLS w metodzie etapowej, która minimalizuje wpływ na firmę.

W poniższych sekcjach założono, że czytelnik zna podstawy paradygmatu SD-WAN oraz architekturę szkieletu firmy Microsoft. Sieć szkieletowa firmy Microsoft łączy ze sobą regiony platformy Azure i z publicznym Internetem.

Architektura

Organizacje z globalną obecnością i wieloregionowym śladem platformy Azure zwykle używają kombinacji usług łączności do implementowania sieci firmowych i łączenia się z siecią szkieletową firmy Microsoft:

Dedykowane usługi łączności, takie jak MPLS Internet-Protocol-Virtual-Private-Networks (IPVPNs), mogą być używane w największych lokacjach, takich jak centra danych lub centrala.
Duże lokacje mogą obejmować dedykowaną łączność z siecią szkieletową firmy Microsoft za pośrednictwem obwodów usługi ExpressRoute przy użyciu jednego z obsługiwanych modeli łączności. W szczególności lokacja może używać dedykowanych obwodów punkt-punkt do łączenia się z najbliższą lokalizacją komunikacji równorzędnej usługi ExpressRoute. Może również zastosować swoją sieci IPVPN MPLS w celu uzyskania dostępu do obwodów usługi ExpressRoute udostępnianych przez przewoźnika MPLS.
Biura oddziałów, które mają łączność z Internetem, mogą używać sieci VPN IPsec do łączenia się z najbliższym lokalnym centrum danych i korzystać z połączenia expressroute tego centrum danych w celu uzyskania dostępu do zasobów platformy Azure. Mogą też używać sieci VPN IPsec do bezpośredniego łączenia się z sieciami piasty i szprych platformy Azure.

Projekty SD-WAN mogą mieć różne zakresy pod względem tradycyjnych usług sieciowych, które mają zastąpić. Niektóre organizacje mogą chcieć trzymać się dedykowanych linków lub mpLS dla dużych obiektów i wdrożyć SD-WAN tylko w celu zastąpienia starszych internetowych sieci VPN protokołu IPsec w małych witrynach. Inne organizacje mogą chcieć rozszerzyć swoją sieć SD-WAN na lokacje połączone z usługą MPLS i użyć istniejącej sieci MPLS jako nakładki o wysokiej wydajności. Na koniec niektóre organizacje mogą chcieć odrzucić swoje adresy IPVP usługi MPLS. lub dowolną dedykowaną usługę łączności, aby objąć model SD-WAN. W ten sposób mogą oni tworzyć całą sieć firmową jako logiczną nakładkę na podstawie publicznych lub udostępnionych nakładek (publiczny Internet i szkielet firmy Microsoft).

Architektura opisana w tym artykule obsługuje wszystkie wymienione wcześniej zakresy i jest oparta na następujących zasadach:

Urządzenia SD-WAN są wdrażane jako wirtualne urządzenia sieciowe (WUS) w sieci piasty i szprych poszczególnych regionów platformy Azure oraz skonfigurowane jako koncentratory SD-WAN, które przerywają tunele z lokacji lokalnych.
Urządzenia SD-WAN na platformie Azure są skonfigurowane do ustanawiania tuneli ze sobą, tworząc w pełni zagęszczone nakładki piasty do koncentratora, które mogą efektywnie transportować ruch między regionami platformy Azure i przekazywać ruch między odległymi geograficznie lokacjami lokalnymi, na podstawie szkieletu firmy Microsoft.
Urządzenia SD-WAN są wdrażane we wszystkich lokacjach lokalnych objętych rozwiązaniem SD-WAN i skonfigurowanych do ustanawiania tuneli w urządzeniach WAN SD-WAN w najbliższych regionach świadczenia usługi Azure. Różne lokacje mogą używać różnych usług transportu jako nakładki dla tuneli, takich jak publiczny Internet, łączność usługi ExpressRoute itd.
Ruch z lokacji do dowolnego miejsca docelowego, niezależnie od tego, czy znajduje się na platformie Azure, czy w innej lokacji lokalnej, jest kierowany do urządzeń WAN SD-WAN w najbliższym regionie świadczenia usługi Azure. Następnie kieruje się przez nakładkę hub-to-hub.

Produkty SD-WAN mogą używać zastrzeżonych protokołów i funkcji do wykrywania, po dynamicznym ustanowieniu, bezpośrednie tunele między dwiema lokacjami mogą zapewnić lepszą wydajność niż przekazywanie ruchu za pośrednictwem urządzeń WAN SD-WAN na platformie Azure.

Architektura wysokiego poziomu globalnej sieci SD-WAN korzystająca z sieci szkieletowej firmy Microsoft, publicznego Internetu i dedykowanych połączeń ER jako nakładek pokazano na poniższej ilustracji.

Rysunek 1. Architektura wysokiego poziomu globalnej SD-WAN, która korzysta z sieci szkieletowej firmy Microsoft, publicznego Internetu i dedykowanych połączeń ER jako nakładek. linia przerywana pokazuje, jak ruch między dwoma lokacjami lokalnymi można kierować za pośrednictwem SD-WAN urządzeń WUS wdrożonych w regionach platformy Azure geograficznie blisko lokacji. Sieć szkieletowa firmy Microsoft ze względu na jego zasięg, pojemność i "zimne ziemniaki" zasady routingu mogą prowadzić do znacznie lepszej/przewidywalnej wydajności niż publiczny Internet, zwłaszcza w przypadku połączeń długodystansowych.

Produkty SD-WAN w sieciach piasty i szprych platformy Azure

Ta sekcja zawiera zalecenia dotyczące wdrażania urządzeń innych niż Microsoft SD-WAN CPE jako urządzeń WUS w istniejącej sieci piasty i szprych platformy Azure.

Wirtualne urządzenia WAN SD-WAN w sieci wirtualnej koncentratora

Piasta i szprycha to topologia zalecana przez firmę Microsoft do tworzenia skalowalnych sieci w regionie świadczenia usługi Azure przy użyciu sieci wirtualnych zarządzanych przez klienta. Sieć wirtualna piasty hostuje udostępnione składniki, takie jak urządzenia WUS firmy innej niż Microsoft i usługi natywne, które zapewniają funkcje sieciowe, takie jak zapora, równoważenie obciążenia i łączność z lokacjami lokalnymi za pośrednictwem sieci VPN lokacji 2 lokacji lub usługi ExpressRoute. Sieć wirtualna piasty jest naturalną lokalizacją dla urządzeń WAN SD-WAN, które ostatecznie są bramami firm innych niż Microsoft zapewniającymi dostęp do sieci zdalnych.

Urządzenia WAN SD-WAN powinny być wdrażane w sieciach wirtualnych koncentratora w następujący sposób:

Jeden pojedynczy kontroler interfejsu sieciowego (NIC) jest używany dla całego ruchu SD-WAN. Inne karty sieciowe, takie jak karta sieciowa zarządzania, można dodać, aby spełnić wymagania dotyczące zabezpieczeń i zgodności lub przestrzegać wytycznych dostawcy dotyczących wdrożeń platformy Azure.
Karta sieciowa używana do ruchu SD-WAN musi być dołączona do dedykowanej podsieci. Rozmiar podsieci musi być zdefiniowany na podstawie liczby urządzeń WAN SD-WAN wdrożonych w celu spełnienia wymagań dotyczących wysokiej dostępności i skalowania lub przepływności, omówionych w dalszej części tego artykułu.
Sieciowe grupy zabezpieczeń muszą być skojarzone z kartą sieciową ruchu SD-WAN bezpośrednio lub na poziomie podsieci. To skojarzenie umożliwia nawiązywanie połączeń ze zdalnych lokacji lokalnych za pośrednictwem portów TCP/UDP używanych przez rozwiązanie SD-WAN.
Przekazywanie IP musi być włączone na karcie sieciowej używanej dla ruchu SD-WAN.

Usługa Azure Route Server w sieci wirtualnej koncentratora

Usługa Azure Route Server automatyzuje wymianę tras między urządzeniami WAN SD-WAN i stosem sieci zdefiniowanej przez oprogramowanie platformy Azure (SDN). Usługa Route Server obsługuje protokół BGP jako protokół routingu dynamicznego. Ustanowienie adjacencji BGP między usługą Route Server i wirtualnymi urządzeniami WAN SD-WAN:

Trasy dla wszystkich lokacji lokalnych połączonych z siecią SD-WAN są wstrzykiwane do tabel tras sieci wirtualnej i poznane przez wszystkie maszyny wirtualne platformy Azure.
Trasy dla wszystkich prefiksów adresów IP zawartych w przestrzeni adresowej sieci wirtualnych są propagowane do wszystkich lokacji połączonych ze standardem SD-WAN.

Serwer routingu powinien być skonfigurowany w następujący sposób.

Należy ją wdrożyć w dedykowanej podsieci w sieci wirtualnej koncentratora zgodnie z informacjami na temat tworzenia i konfigurowania serwera route server przy użyciu witryny Azure Portal.
Aby umożliwić automatyczną wymianę tras dla wszystkich sieci wirtualnych szprych, należy skonfigurować komunikację równorzędną sieci wirtualnych sieci wirtualnych będącej szprychą tak, aby korzystały z bramy sieci wirtualnej piasty i serwera Route Server. Szczegóły dostępne w często zadawanych pytaniach dotyczących usługi Azure Route Server.
W miarę dołączania serwerów Route Server i urządzeń WAN SD-WAN do różnych podsieci należy skonfigurować sesje protokołu BGP między serwerem Route Server i wirtualnymi urządzeniami sieciowymi SD-WAN z obsługą multihop protokołu eBGP. Można ustawić dowolną liczbę przeskoków z zakresu od 2 do maksymalnej obsługiwanej przez urządzenie WAN SD-WAN. Szczegółowe informacje na temat konfigurowania adjacencji protokołu BGP dla serwera Route Server są dostępne w temacie Tworzenie i konfigurowanie serwera route server przy użyciu witryny Azure Portal.
Dla punktów końcowych protokołu BGP uwidocznionych przez usługę Route Server należy skonfigurować dwie /32 trasy statyczne na urządzeniu WAN SD-WAN. Ta konfiguracja gwarantuje, że tabela tras urządzenia WUS zawsze zawiera trasy dla elementów równorzędnych protokołu BGP (bez bezpośredniego połączenia).

Usługa Route Server nie znajduje się w ścieżce danych. Jest to jednostka płaszczyzny sterowania. Propaguje trasy między urządzeniem WAN NVA sd-WAN a stosem SDN sieci wirtualnej, ale rzeczywiste przekazywanie ruchu między wirtualnym urządzeniem WAN SD-WAN a maszynami wirtualnymi w sieci wirtualnej odbywa się przez stos SDN platformy Azure, jak pokazano na poniższej ilustracji. Aby uzyskać to zachowanie routingu, usługa Route Server wprowadza wszystkie trasy, których uczy się z urządzeń WAN SD-WAN z następnym przeskokiem ustawionym na własny adres urządzenia WUS.

Usługa Route Server nie obsługuje teraz protokołu IPv6. Ta architektura dotyczy tylko protokołu IPv4.

Rysunek 2. Usługa Route Server obsługuje propagację tras między SD-WAN CPE a stosem SDN sieci wirtualnej, ale nie przekazuje ruchu między SD-WAN CPE a maszynami wirtualnymi w sieci wirtualnej.

Wysoka dostępność urządzeń WAN SD-WAN z serwerem Route Server

Serwer Route Server ma wbudowaną wysoką dostępność. Dwa węzły obliczeniowe są z powrotem jednym wystąpieniem usługi Route Server. Są one wdrażane w różnych strefach dostępności dla regionów obsługujących strefę dostępności lub w tym samym zestawie dostępności. Uwidaczniają dwa punkty końcowe protokołu BGP. Wysoka dostępność dla urządzeń WAN SD-WAN jest osiągana przez wdrożenie wielu wystąpień w różnych strefach dostępności, dla regionów, które je obsługują, lub w tym samym zestawie dostępności. Każde urządzenie WAN SD-WAN ustanawia dwie sesje protokołu BGP z obydwoma punktami końcowymi uwidocznianymi przez usługę Route Server.

Architektura opisana w tym artykule nie opiera się na usłudze Azure Load Balancers. W szczególności:

Żadne publiczne moduły równoważenia obciążenia nie udostępniają punktów końcowych tunelu SD-WAN. Każde urządzenie WAN SD-WAN uwidacznia własny punkt końcowy tunelu. Zdalne elementy równorzędne ustanawiają wiele tuneli, po jednym dla każdego wirtualnego urządzenia WAN SD-WAN na platformie Azure.
Żadne wewnętrzne moduły równoważenia obciążenia nie dystrybuują ruchu pochodzącego przez maszyny wirtualne platformy Azure do urządzeń WAN SD-WAN. Usługa Route Server i stos SDN platformy Azure obsługują routing wielościeżkowy (ECMP, Equal-Cost Multipath). Jeśli wiele urządzeń WUS skonfigurowało adjacencje protokołu BGP z usługą Route Server i ogłasza trasy dla tych samych miejsc docelowych (co w przypadku sieci zdalnych i lokacji połączonych z siecią SD-WAN) przy użyciu tego samego stopnia preferencji, Route Server:
- Wprowadza wiele tras dla tych miejsc docelowych w tabeli tras sieci wirtualnej.
- Ustawia każdą trasę tak, aby używała innego urządzenia WUS jako następnego przeskoku.

Następnie stos SDN dystrybuuje ruch do tych miejsc docelowych we wszystkich dostępnych następnego przeskoku.

Wynikowa architektura wysokiej dostępności jest pokazana na poniższej ilustracji:

Rysunek 3. Usługa Route Server obsługuje routing Equal-Cost wielościeżkowego (ECMP). Moduły równoważenia obciążenia platformy Azure nie są potrzebne, gdy wiele urządzeń WUS SD-WAN jest używanych do celów dostępności i/lub skalowalności.

N-aktywny a aktywny stand-by wysokiej dostępności

W przypadku korzystania z wielu urządzeń WAN WAN i komunikacji równorzędnej z serwerem Route Server protokół BGP powoduje przejście w tryb failover. Jeśli urządzenie WAN SD-WAN przechodzi w tryb offline, zatrzymuje anonsowanie tras do usługi Route Server. Trasy wyciągnięte z urządzenia, które zakończyły się niepowodzeniem, zostaną wycofane z tabeli tras sieci wirtualnej. W związku z tym, jeśli urządzenie WAN SD-WAN nie zapewnia już łączności z zdalnymi lokacjami SD-WAN z powodu błędu, w samym urządzeniu lub w podkładce, nie będzie już wyświetlane jako możliwy następny przeskok w kierunku lokacji zdalnych w tabeli tras sieci wirtualnej. Cały ruch przechodzi do pozostałych urządzeń w dobrej kondycji. Aby uzyskać więcej informacji na temat propagacji tras między SD-WAN urządzeniami WUS i usługą Route Server, zobacz Trasy anonsowane przez element równorzędny protokołu BGP do usługi Route Server.

Rysunek 4. Tryb failover oparty na protokołu BGP. Jeśli SD-WAN urządzenie WUS #0 przejdzie w tryb offline, sesje protokołu BGP z zamknięciem serwera route server. SD-WAN urządzenie WUS #0 jest usuwane z tabeli tras sieci wirtualnej jako możliwego następnego przeskoku dla ruchu wychodzącego z platformy Azure do lokacji lokalnej.

Tryb failover oparty na protokołu BGP i routing ECMP naturalnie umożliwiają architektury wysokiej dostępności n-aktywnej wysokiej dostępności z urządzeniami N współbieżnie przetwarzające ruch. Można jednak również użyć protokołu BGP, aby zaimplementować architektury aktywnej i pasywnej wysokiej dostępności: skonfiguruj pasywne urządzenie do ogłaszania trasy w usłudze Route Server z niższym stopniem preferencji niż jego aktywny element równorzędny. Usługa Route Server odrzuca trasy odebrane z urządzenia pasywnego, jeśli odbiera z aktywnego urządzenia wszystkie trasy dla tych samych miejsc docelowych o wyższym stopniu preferencji. A to plumbs tylko te ostatnie trasy w tabeli tras sieci wirtualnej.

Jeśli aktywne urządzenie ulegnie awarii lub wycofa niektóre z jego tras, serwer route server:

Wybiera odpowiednie trasy ogłoszone przez urządzenie pasywne.
Rozciągnie trasy w tabeli tras sieci wirtualnej.

Jedynymi atrybutami protokołu BGP, których urządzenia WAN SD-WAN mogą używać do wyrażania stopnia preferencji dla tras, które ogłaszają do usługi Route Server, jest ścieżka AS.

Zalecamy architektury wysokiej dostępności N-aktywne, ponieważ umożliwiają optymalne użycie zasobów (nie ma autonomicznych urządzeń WAN NVA) i skalowalności poziomej. Aby zwiększyć przepływność, wiele urządzeń WUS może działać równolegle, do maksymalnej liczby elementów równorzędnych BGP obsługiwanych przez usługę Route Server. Aby uzyskać więcej informacji, zobacz Komunikacja równorzędna BGP. Jednak model N-aktywnej wysokiej dostępności wymaga, aby urządzenia WAN SD-WAN działały jako bezstanowe, routery warstwy 3. Gdy istnieje wiele tuneli do lokacji, połączenia TCP mogą być kierowane asymetrycznie. Oznacza to, że przepływy ORIGINAL i REPLY tego samego połączenia TCP mogą być kierowane przez różne tunele i różne urządzenia WUS. Na poniższej ilustracji przedstawiono przykład asymetrycznie kierowanego połączenia TCP. Takie routingu asymetrie są możliwe w przypadku połączeń TCP zainicjowanych w sieci wirtualnej lub lokacji lokalnej.

Rysunek 5. Routing asymetryczny w architekturach aktywnej/aktywnej wysokiej dostępności. SD-WAN urządzenia WUS #0 i SD-WAN urządzenia WUS #1 ogłaszają tę samą trasę dla miejsca docelowego 192.168.1.0/24 (zdalna lokacja SD-WAN) o tej samej długości ścieżki AS do usługi Route Server. Przepływ ORIGINAL (z SD-WAN lokacji zdalnej do platformy Azure, czerwona ścieżka) jest kierowany przez tunel zakończony po stronie platformy Azure przez SD-WAN urządzenia WUS #1. Lokalny SD-WAN CPE wybiera ten tunel. Stos SDN platformy Azure kieruje przepływ ODPOWIEDZI (z platformy Azure do zdalnej lokacji SD-WAN, zielona ścieżka) do SD-WAN urządzenia WUS #0, który jest jednym z możliwych następnego przeskoku dla 192.168.1.0/24, zgodnie z tabelą tras sieci wirtualnej. Nie można zagwarantować, że następny przeskok wybrany przez stos SDN platformy Azure jest zawsze taki sam SD-WAN CPE, który otrzymał przepływ ORYGINALNY.

Aktywne i pasywne architektury wysokiej dostępności powinny być brane pod uwagę tylko wtedy, gdy urządzenia WAN SD-WAN na platformie Azure wykonują inne funkcje sieciowe, które wymagają routingu symetrii, takich jak zapory stanowe. Nie zalecamy tego podejścia ze względu na jego wpływ na skalowalność. Uruchamianie większej liczby funkcji sieciowych w wirtualnych urządzeniach sieciowych SD-WAN zwiększa zużycie zasobów. Jednocześnie aktywna i pasywna architektura wysokiej dostępności umożliwia jednoczesne przetwarzanie jednego ruchu sieciowego urządzenia WUS w dowolnym momencie. Oznacza to, że cała warstwa SD-WAN może być skalowana tylko w górę do maksymalnego obsługiwanego rozmiaru maszyny wirtualnej platformy Azure, a nie skalowana w poziomie. Uruchamianie stanowych funkcji sieciowych, które wymagają routingu symetrii na oddzielnych klastrach WUS, które opierają się na usługa Load Balancer w warstwie Standardowa dla n-aktywnej wysokiej dostępności.

Zagadnienia dotyczące łączności usługi ExpressRoute

Architektura opisana w tym artykule pozwala klientom w pełni objąć model SD-WAN i zbudować sieć firmową jako logiczną nakładkę na publiczny Internet i sieć szkieletową firmy Microsoft. Obsługuje również używanie dedykowanych obwodów usługi ExpressRoute do obsługi określonych scenariuszy opisanych w dalszej części.

Scenariusz nr 1: współistnienie usług ExpressRoute i SD-WAN

Rozwiązania SD-WAN mogą współistnieć z łącznością usługi ExpressRoute, gdy urządzenia SD-WAN są wdrażane tylko w podzestawie lokacji. Na przykład niektóre organizacje mogą wdrażać SD-WAN rozwiązania jako zamiennik tradycyjnych sieci VPN protokołu IPsec w witrynach tylko z łącznością internetową. Następnie używają usług MPLS i obwodów usługi ExpressRoute dla dużych lokacji i centrów danych, jak pokazano na poniższym rysunku.

Rysunek 6. SD-WAN rozwiązania mogą współistnieć z łącznością usługi ExpressRoute, gdy SD-WAN urządzenia CPE są wdrażane tylko w podzestawie lokacji.

Ten scenariusz współistnienia wymaga urządzeń WAN SD-WAN wdrożonych na platformie Azure w celu routingu ruchu między lokacjami połączonymi z siecią SD-WAN i lokacjami połączonymi z obwodami usługi ExpressRoute. Serwer route Server można skonfigurować tak, aby propagował trasy między bramami sieci wirtualnej usługi ExpressRoute i SD-WAN urządzeniami WUS na platformie Azure, włączając AllowBranchToBranch tę funkcję zgodnie z opisem w tym miejscu. Propagacja tras między bramą sieci wirtualnej usługi ExpressRoute a wirtualnymi urządzeniami WAN SD-WAN odbywa się za pośrednictwem protokołu BGP. Usługa Route Server ustanawia sesje protokołu BGP z obydwoma elementami równorzędnymi i propaguje je do każdej komunikacji równorzędnej tras poznanych z drugiej strony. Platforma zarządza sesjami protokołu BGP między usługą Route Server i bramą sieci wirtualnej usługi ExpressRoute. Użytkownicy nie muszą jawnie konfigurować ich, ale tylko włączyć flagę AllowBranchToBranch podczas wdrażania serwera Route Server.

Rysunek 7. Propagacja tras między bramą sieci wirtualnej usługi ExpressRoute a SD-WAN urządzeniami WUS odbywa się za pośrednictwem protokołu BGP. Usługa Route Server ustanawia sesje protokołu BGP zarówno z trasami, jak i propaguje trasy w obu kierunkach po skonfigurowaniu za pomocą polecenia "AllowBranchToBranch=TRUE". Serwer route Server działa jako refleksor trasy, czyli nie jest częścią ścieżki danych.

Ten scenariusz współistnienia sd-WAN i ExpressRoute umożliwia migracje z sieci MPLS do SD-WAN. Oferuje ona ścieżkę między starszymi lokacjami MPLS i nowo zmigrowanymi lokacjami SD-WAN, eliminując konieczność kierowania ruchu przez lokalne centra danych. Ten wzorzec może być używany nie tylko podczas migracji, ale także w scenariuszach wynikających z fuzji i przejęć firmy, zapewniając bezproblemowe połączenie różnych sieci.

Scenariusz nr 2: Usługa ExpressRoute jako podkładka SD-WAN

Jeśli lokacje lokalne mają łączność usługi ExpressRoute, możesz skonfigurować urządzenia SD-WAN w celu skonfigurowania tuneli do urządzeń WAN koncentratorów SD-WAN działających na platformie Azure na podstawie obwodu lub obwodów usługi ExpressRoute. Łączność usługi ExpressRoute można wykonać za pośrednictwem obwodów punkt-punkt lub sieci MPLS. Możesz użyć prywatnej komunikacji równorzędnej usługi ExpressRoute i komunikacji równorzędnej firmy Microsoft.

Prywatna komunikacja równorzędna

W przypadku korzystania z prywatnej komunikacji równorzędnej usługi ExpressRoute jako podkładki wszystkie lokalne lokacje SD-WAN ustanawiają tunele do koncentratorów SD-WAN na platformie Azure. W tym scenariuszu nie jest wymagana propagacja tras między urządzeniami WUS SD-WAN a bramą sieci wirtualnej usługi ExpressRoute (oznacza to, że serwer route server musi być skonfigurowany z flagą "AllowBranchToBranch" ustawioną na wartość false).

Takie podejście wymaga prawidłowej konfiguracji protokołu BGP na routerach po stronie klienta lub dostawcy, które przerywają połączenie usługi ExpressRoute. W rzeczywistości routery microsoft Enterprise Edge Routery (MSEE) ogłaszają wszystkie trasy dla sieci wirtualnych połączonych z obwodem (bezpośrednio lub za pośrednictwem komunikacji równorzędnej sieci wirtualnej). Jednak aby przekazywać ruch kierowany do sieci wirtualnych za pośrednictwem tunelu SD-WAN, lokacja lokalna powinna uczyć się tych tras z urządzenia SD-WAN — a nie obwodu ER.

W związku z tym routery po stronie klienta lub po stronie dostawcy, które przerywają połączenie usługi ExpressRoute, muszą odfiltrować trasy odebrane z platformy Azure. Jedynymi trasami skonfigurowanymi w nakładce powinny być te, które umożliwiają lokalnym urządzeniom SD-WAN dotarcie do urządzeń WAN koncentratora SD-WAN na platformie Azure. Klienci, którzy chcą używać prywatnej komunikacji równorzędnej usługi ExpressRoute jako nakładki SD-WAN, powinni sprawdzić, czy mogą odpowiednio skonfigurować swoje urządzenia routingu. Jest to szczególnie istotne dla klientów, którzy nie mają bezpośredniej kontroli nad swoimi urządzeniami brzegowymi dla usługi ExpressRoute. Przykładem jest to, że obwód usługi ExpressRoute jest dostarczany przez przewoźnika MPLS na podstawie usługi IPVPN.

Rysunek 8. Prywatna komunikacja równorzędna usługi ExpressRoute jako nakładka SD-WAN. W tym scenariuszu routery po stronie klienta i dostawcy odbierają trasy dla sieci wirtualnej, która kończy połączenie usługi ExpressRoute, w sesjach prywatnej komunikacji równorzędnej BGP ER i SD-WAN CPE. Tylko SD-WAN CPE powinny propagować trasy platformy Azure do sieci LAN lokacji.

Komunikacja równorzędna firmy Microsoft

Możesz również użyć komunikacji równorzędnej firmy Microsoft usługi ExpressRoute jako nakładki dla tuneli SD-WAN. W tym scenariuszu urządzenia WAN koncentratora SD-WAN na platformie Azure uwidaczniają tylko publiczne punkty końcowe tunelu, które są używane przez procesory SD-WAN w lokacjach połączonych z Internetem, jeśli istnieją, oraz przez procesory SD-WAN w lokacjach połączonych z usługą ExpressRoute. Mimo że komunikacja równorzędna firmy Microsoft w usłudze ExpressRoute ma bardziej złożone wymagania wstępne niż prywatna komunikacja równorzędna, zalecamy użycie tej opcji jako nakładki z powodu tych dwóch zalet:

Nie wymaga bram sieci wirtualnej usługi ExpressRoute w sieci wirtualnej koncentratora. Eliminuje złożoność, zmniejsza koszty i umożliwia SD-WAN skalowanie rozwiązania poza limity przepustowości samej bramy, gdy nie używasz usługi ExpressRoute FastPath.
Zapewnia czystą separację między trasami nakładki i nakładki. Te środowiska MSEE ogłaszają tylko publiczne prefiksy sieci Firmy Microsoft na brzegu klienta lub dostawcy. Możesz zarządzać tymi trasami w osobnym VRF i propagować je tylko do segmentu DMZ sieci LAN witryny. Urządzenia SD-WAN propagują trasy dla sieci firmowej klienta w nakładce, w tym trasy dla sieci wirtualnych. Klienci biorąc pod uwagę to podejście powinni sprawdzić, czy mogą odpowiednio skonfigurować swoje urządzenia routingu lub zażądać odpowiedniej usługi dla operatora MPLS.

Zagadnienia dotyczące usługi MPLS

Migracja z tradycyjnych sieci firmowych MPLS do bardziej nowoczesnych architektur sieci opartych na modelu SD-WAN wymaga znacznego nakładu pracy i znacznego czasu. Architektura opisana w tym artykule umożliwia etapowe migracje sd-WAN. W dalszej części omówiono dwa typowe scenariusze migracji.

Etapowe likwidowanie usługi MPLS

Klienci, którzy chcą utworzyć SD-WAN na podstawie publicznego Internetu i sieci szkieletowej firmy Microsoft, a także całkowicie zlikwidować nazwy IPVP usługi MPLS lub inne dedykowane usługi łączności, mogą korzystać z usługi ExpressRoute i SD-WAN scenariusz współistnienia opisany w poprzedniej sekcji podczas migracji. Umożliwia ona lokacjom połączonym ze standardem SD-WAN dostęp do witryn, które nadal są połączone ze starszymi usługami MPLS. Po przeprowadzeniu migracji lokacji do urządzeń SD-WAN i CPE można zlikwidować jego link MPLS. Lokacja może uzyskiwać dostęp do całej sieci firmowej za pośrednictwem tuneli SD-WAN do najbliższych regionów świadczenia usługi Azure.

Rysunek 9. Scenariusz "ExpressRoute i SD-WAN współistnienia" umożliwia stopniowe likwidowanie zabezpieczeń MPLS.

Po przeprowadzeniu migracji wszystkich lokacji można zlikwidować protokół IPVPN MPLS wraz z obwodami usługi ExpressRoute, które łączą ją z siecią szkieletową firmy Microsoft. Bramy sieci wirtualnej usługi ExpressRoute nie są już potrzebne i można je anulować. Koncentratory SD-WAN w każdym regionie stają się jedynym punktem wejścia do sieci piasty i szprych tego regionu.

Integracja z usługą MPLS

Organizacje, które nie ufają publicznym i udostępnionym sieciom w celu zapewnienia żądanej wydajności i niezawodności, mogą zdecydować się na użycie istniejącej sieci MPLS jako nakładki klasy korporacyjnej. Dostępne są dwie opcje:

Podzbiór witryn, takich jak centra danych lub duże biura oddziałów.
Podzbiór połączeń, zazwyczaj z opóźnieniem lub ruchem o krytycznym znaczeniu.

Scenariusz expressroute jako nakładka SD-WAN opisana wcześniej umożliwia integrację SD-WAN i MPLS. Komunikacja równorzędna firmy Microsoft usługi ExpressRoute powinna być preferowana przez prywatną komunikację równorzędną z opisanych wcześniej powodów. Ponadto w przypadku korzystania z komunikacji równorzędnej firmy Microsoft sieć MPLS i publiczny Internet stają się funkcjonalnie równoważne nakładki. Zapewniają one dostęp do wszystkich punktów końcowych tunelu SD-WAN udostępnianych przez urządzenia WAN koncentratora SD-WAN na platformie Azure. Zestaw SD-WAN CPE wdrożony w lokacji z łącznością internetową i MPLS może ustanowić wiele tuneli do koncentratorów SD-WAN na platformie Azure na obu nakładkach. Następnie mogą kierować różne połączenia przez różne tunele na podstawie zasad na poziomie aplikacji zarządzanych przez płaszczyznę sterowania SD-WAN.

Rysunek 10. Scenariusz "ExpressRoute jako nakładka SD-WAN" umożliwia integrację SD-WAN i MPLS.

Preferencja routingu usługi Route Server

W obu scenariuszach MPLS opisanych w dwóch poprzednich sekcjach niektóre lokacje gałęzi mogą być połączone zarówno z protokołem IPVPN usługi MPLS, jak i z siecią SD-WAN. W związku z tym wystąpienia usługi Route Server wdrożone w sieciach wirtualnych koncentratora mogą poznać te same trasy z bram usługi ExpressRoute i urządzeń WAN SD-WAN. Preferencja routingu usługi Route Server umożliwia kontrolowanie, która ścieżka powinna być preferowana i spakowana do tabel tras sieci wirtualnych. Preferencja routingu jest przydatna, gdy nie można używać dołączania ścieżki AS. Przykładem są usługi MPLS IPVPN, które nie obsługują niestandardowych konfiguracji protokołu BGP na punktach publicznych, które przerywają połączenia usługi ExpressRoute.

Limity i zagadnienia dotyczące projektowania serwera Route Server

Usługa Route Server jest podstawą architektury opisanej w tym artykule. Propaguje trasy między urządzeniami WAN SD-WAN wdrożonym w sieciach wirtualnych i bazowym stosem SDN platformy Azure. Zapewnia ona oparte na protokole BGP podejście do uruchamiania wielu urządzeń WAN SD-WAN w celu zapewnienia wysokiej dostępności i skalowalności poziomej. Podczas projektowania dużych SD-WANs na podstawie tej architektury należy uwzględnić limity skalowalności serwera Route Server .

Poniższe sekcje zawierają wskazówki dotyczące maksymalnej skalowalności i sposobu radzenia sobie z poszczególnymi limitami.

Trasy anonsowane przez element równorzędny protokołu BGP do usługi Route Server

Usługa Route Server nie definiuje jawnego limitu liczby tras, które można anonsować do bram sieci wirtualnej usługi ExpressRoute po ustawieniu AllowBranchToBranch flagi. Jednak bramy usługi ExpressRoute dalej propagują trasy, z których się uczą, z usługi Route Server do obwodów usługi ExpressRoute, z którymi są połączone.

Istnieje limit liczby tras, które bramy usługi ExpressRoute mogą anonsować do obwodów usługi ExpressRoute za pośrednictwem prywatnej komunikacji równorzędnej, udokumentowanej w temacie Azure subscription and service limits, quotas, and constraints (Limity, przydziały i ograniczenia usługi Azure). Podczas projektowania rozwiązań SD-WAN na podstawie wskazówek zawartych w tym artykule należy upewnić się, że trasy SD-WAN nie powodują przekroczenia tego limitu. W przypadku trafienia sesje protokołu BGP między bramami usługi ExpressRoute i obwodami usługi ExpressRoute zostaną porzucone, a łączność między sieciami wirtualnymi i sieciami zdalnymi połączonymi za pośrednictwem usługi ExpressRoute zostanie utracona.

Łączna liczba tras anonsowanych do obwodów przez bramy usługi ExpressRoute jest sumą liczby tras poznanych z usługi Route Server oraz liczby prefiksów tworzących przestrzeń adresową sieci piasty i szprych. Aby uniknąć awarii z powodu porzuconych sesji protokołu BGP, zalecamy zaimplementowanie następujących środków zaradczych:

Użyj natywnych funkcji urządzeń SD-WAN, aby ograniczyć liczbę tras ogłoszonych na serwerze Route Server, jeśli funkcja jest dostępna.
Alerty usługi Azure Monitor umożliwiają proaktywne wykrywanie skoków liczby tras ogłoszonych przez bramy usługi ExpressRoute. Metryka do monitorowania nosi nazwę Liczba tras anonsowanych do komunikacji równorzędnej, zgodnie z opisem w temacie Monitorowanie usługi ExpressRoute.

Równorzędne obiekty równorzędne protokołu BGP

Usługa Route Server może ustanowić sesje protokołu BGP z maksymalną liczbą elementów równorzędnych BGP. Ten limit określa maksymalną liczbę urządzeń WAN SD-WAN, które mogą ustanowić adjacencje protokołu BGP z usługą Route Server, a zatem maksymalną zagregowaną przepływność, która może być obsługiwana we wszystkich tunelach SD-WAN. Oczekuje się, że tylko duże sieci SD-WAN osiągną ten limit. Nie istnieją obejścia, aby go przezwyciężyć, poza tworzeniem wielu sieci piasty i szprych, z których każdy ma własne bramy i serwery tras.

Uczestniczące maszyny wirtualne

Bramy sieci wirtualnej i serwer route server konfigurują trasy, które uczą się na podstawie zdalnych elementów równorzędnych dla wszystkich maszyn wirtualnych we własnej sieci wirtualnej i bezpośrednio równorzędnych sieciach wirtualnych. Aby chronić usługę Route Server przed nadmiernym zużyciem zasobów z powodu routingu aktualizacji maszyn wirtualnych, platforma Azure definiuje limit liczby maszyn wirtualnych, które mogą istnieć w jednej sieci piasty i szprych. Nie istnieją obejścia, aby przezwyciężyć ten limit, poza tworzeniem wielu sieci piasty i szprych, każdy z własnymi bramami i serwerami tras w tym samym regionie.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Federico Guerrini | Starszy architekt rozwiązań w chmurze
Khush Kaviraj | Architekt rozwiązań w chmurze

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Platforma Microsoft Well-Architected