Faza projektowania 1: Połączenie ivity z lokacjami lokalnymi

Artykuł
09/30/2023

Połączenie ivity z lokalnymi centrami danych jest najbardziej krytycznym obszarem projektowania dla sieci usługi Azure VMware Solution. Kluczowe wymagania, które należy spełnić, obejmują:

Wysoka przepływność: migracje ze lokalnych środowisk vSphere i rozwiązań odzyskiwania po awarii wymagają szybkiego przenoszenia dużych ilości danych między lokacjami lokalnymi i chmurami prywatnymi rozwiązania Azure VMware Solution.
Małe opóźnienie: aplikacje rozproszone mogą wymagać małego opóźnienia dla połączeń między maszynami wirtualnymi usługi Azure VMware Solution i systemami lokalnymi.
Przewidywalność wydajności: aby osiągnąć przewidywalną przepływność i opóźnienie, aplikacje krytyczne dla działania firmy wdrożone w rozwiązaniu Azure VMware Solution mogą wymagać dedykowanych usług łączności (Azure ExpressRoute) między lokacjami lokalnymi i siecią firmy Microsoft.

W tym artykule opisano opcje obsługiwane przez rozwiązanie Azure VMware Solution na potrzeby łączności z lokacjami lokalnymi:

ExpressRoute Global Reach
Sieci VPN protokołu IPSec
Tranzyt za pośrednictwem prywatnej komunikacji równorzędnej usługi ExpressRoute

Opcje są prezentowane w celu zmniejszenia możliwości spełnienia kluczowych wymagań wymienionych wcześniej. Należy odrzucić opcję, a następnie rozważyć następną opcję tylko wtedy, gdy powoduje konflikt z nienegocjacyjnymi ograniczeniami określonego scenariusza.

Ten schemat blokowy zawiera podsumowanie procesu wybierania opcji łączności hybrydowej dla rozwiązania Azure VMware Solution:

ExpressRoute Global Reach

Usługa ExpressRoute Global Reach to domyślna opcja łączności hybrydowej obsługiwana przez rozwiązanie Azure VMware Solution. Zapewnia ona minimalną złożoność łączności warstwy 3 między chmurą prywatną usługi Azure VMware Solution a lokacją zdalną połączoną z obwodem usługi ExpressRoute zarządzanym przez klienta. Możesz również użyć obwodu usługi ExpressRoute zarządzanego przez klienta, aby nawiązać połączenie z usługami natywnymi platformy Azure. Aby zwiększyć przepustowość zabezpieczeń lub rezerw, można również wdrożyć oddzielny obwód zarządzany przez klienta przeznaczony wyłącznie dla ruchu usługi Azure VMware Solution.

Na poniższym diagramie przedstawiono topologię sieci, która używa usługi Global Reach do łączności z lokacjami lokalnymi. Ruch między chmurami prywatnymi rozwiązania Azure VMware Solution a lokacjami lokalnymi nie przechodzi przez sieci wirtualne platformy Azure.

Uwaga

Aby zapewnić maksymalną odporność, należy użyć dwóch obwodów usługi ExpressRoute zarządzanych przez klienta w różnych lokalizacjach komunikacji równorzędnej do łączenia lokalnych centrów danych z siecią szkieletową firmy Microsoft. W takim przypadku każdy obwód usługi ExpressRoute zarządzany przez klienta powinien mieć połączenie Global Reach z chmurą prywatną rozwiązania Azure VMware Solution (i sieciami wirtualnymi platformy Azure). Zapoznaj się z tym artykułem , aby uzyskać wskazówki dotyczące odpornych implementacji usługi ExpressRoute.

Aby uzyskać instrukcje dotyczące łączenia chmury prywatnej usługi Azure VMware Solution z obwodem usługi ExpressRoute zarządzanym przez klienta przy użyciu usługi Global Reach, zobacz Peer on-premises environments to Azure VMware Solution (Komunikacja równorzędna w środowiskach lokalnych z usługą Azure VMware Solution).

Łączność Global Reach w pełni odpowiada trzem kluczowym wymaganiom:

Wysoka przepływność: usługa ExpressRoute umożliwia łączenie się z siecią firmy Microsoft z lokalizacji za pośrednictwem dedykowanych linii (do 10 Gb/s dla usługi ExpressRoute opartej na dostawcy lub 100 Gb/s dla usługi ExpressRoute Direct).
Małe opóźnienie: usługa Global Reach umożliwia kierowanie ruchu bezpośrednio z krawędzi sieci firmy Microsoft do klastrów VMware Solution vSphere platformy Azure. Usługa Global Reach minimalizuje liczbę przeskoków sieciowych między lokacjami lokalnymi i chmurami prywatnymi.
Przewidywalna wydajność: w przypadku korzystania z usługi ExpressRoute Global Reach ruch jest kierowany przez łącza, które nie napotykają problemów z przeciążeniem (do maksymalnej aprowizowanej pojemności). W związku z tym czas rundy (RTT) między maszynami wirtualnymi uruchomionymi na platformie Azure VMware Solution i hostami lokalnymi pozostaje stały w czasie.

Nie można używać usługi Global Reach w scenariuszach, w których obowiązują co najmniej jedno z następujących ograniczeń:

Usługa ExpressRoute Global Reach jest niedostępna w regionie świadczenia usługi Azure VMware Solution w chmurze prywatnej usługi Azure VMware Lub lokalizacji meet-me obwodu usługi ExpressRoute zarządzanego przez klienta. Nie istnieją obejścia tego ograniczenia. Aby uzyskać aktualne informacje o dostępności globalnej zasięgu usługi ExpressRoute, zobacz About ExpressRoute Global Reach (Informacje o globalnym zasięgu usługi ExpressRoute).
Nienegocjowalne wymagania dotyczące zabezpieczeń sieci istnieją. Jeśli nie można wdrożyć urządzenia zapory po stronie lokalnej obwodu usługi ExpressRoute zarządzanego przez klienta, użycie usługi Global Reach uwidacznia wszystkie segmenty sieci usługi Azure VMware Solution, w tym sieci zarządzania (vCenter Server i NSX-T), do całej sieci połączonej z obwodem. Najbardziej typowym scenariuszem, w którym pojawia się ten problem, jest to, że obwody usługi ExpressRoute zarządzane przez klienta są implementowane na podstawie usług sieciowych MPLS (nazywanych również modelem łączności typu dowolna-dowolna usługa ExpressRoute). Ten scenariusz jest pokazany tutaj:

Gdy łączność usługi ExpressRoute jest implementowana na podstawie adresów IPVP usługi MPLS, nie można wdrożyć zapór w jednej lokalizacji w celu sprawdzenia całego ruchu do i z usługi Azure VMware Solution. Zazwyczaj organizacje korzystające z sieci MPLS wdrażają zapory w dużych centrach danych, a nie we wszystkich swoich lokacjach (mogą to być małe oddziały, biura lub sklepy).

Sieci VPN protokołu IPSec

Łączność między chmurami prywatnymi rozwiązania Azure VMware Solution i lokacjami lokalnymi można zaimplementować, rozsyłając ruch przez tranzytową sieć wirtualną na platformie Azure. Sieć tranzytowa jest połączona z chmurą prywatną usługi Azure VMware Solution za pośrednictwem zarządzanego obwodu usługi ExpressRoute. Tranzytowa sieć wirtualna jest połączona z lokacją lokalną za pośrednictwem sieci VPN IPSec, jak pokazano poniżej:

Zasady zabezpieczeń dla połączeń między lokacjami lokalnymi i chmurą prywatną usługi Azure VMware Solution (linia przerywana na diagramie) można wymusić, rozsyłając ruch przez zaporę, jeśli urządzenie sieci VPN nie udostępnia funkcji zapory. Ta konfiguracja wymaga usługi Azure Virtual WAN z intencją routingu, jak opisano w sekcji Wybieranie miejsca hostowania urządzeń wirtualnych na platformie Azure w tym artykule.

Przed wdrożeniem łączności IPSec między lokacjami lokalnymi i tranzytowymi sieciami wirtualnymi należy podjąć trzy decyzje projektowe:

Ustal, która usługa sieciowa ma być używana jako nakładka tunelu IPSec. Dostępne opcje to łączność internetowa, komunikacja równorzędna firmy Microsoft usługi ExpressRoute i prywatna komunikacja równorzędna usługi ExpressRoute.
Określ, gdzie hostować urządzenia wirtualne, które kończą tunel IPSec po stronie platformy Azure. Dostępne opcje obejmują sieci wirtualne zarządzane przez klienta i koncentratory usługi Virtual WAN.
Określ, które urządzenie wirtualne kończy tunel IPSec po stronie platformy Azure. Wybór urządzenia określa również wymaganą konfigurację platformy Azure na potrzeby routingu ruchu między tunelem IPSec a obwodem zarządzanym usługi Azure VMware Solution. Dostępne opcje to natywna usługa Azure VPN Gateway i urządzenia wirtualne ipSec innych firm (wirtualne urządzenia sieciowe).

Ten schemat blokowy zawiera podsumowanie procesu podejmowania decyzji:

Kryteria podejmowania tych decyzji opisano w poniższych sekcjach.

Wybierz usługę sieciową nakładki

Zdecydowanie zalecamy rozważenie trzech opcji nakładki sieci VPN w przedstawionej tutaj kolejności:

Połączenie internetowe. Publiczny adres IP przypisany do urządzenia sieci VPN hostowanego w tranzytowej sieci wirtualnej służy jako zdalny punkt końcowy tunelu IPSec. Ze względu na niską złożoność i koszt należy zawsze testować i oceniać łączność z Internetem pod kątem wydajności (osiągalna przepływność protokołu IPSec). Należy odrzucić tę opcję tylko wtedy, gdy zaobserwowana wydajność jest zbyt niska lub niespójna. Na poniższym diagramie przedstawiono tę opcję.
Komunikacja równorzędna firmy Microsoft w usłudze ExpressRoute. Ta opcja zapewnia łączność warstwy 3 z publicznymi punktami końcowymi platformy Azure za pośrednictwem dedykowanych linków. Podobnie jak połączenia internetowe, umożliwia dotarcie do publicznego adresu IP urządzenia sieci VPN, które służy jako zdalny punkt końcowy tunelu IPSec i jest hostowane w tranzytowej sieci wirtualnej. Należy odrzucić tę opcję tylko wtedy, gdy nie można spełnić wymagań dotyczących routingu komunikacji równorzędnej firmy Microsoft. Na poniższym diagramie przedstawiono tę opcję.
Prywatna komunikacja równorzędna usługi ExpressRoute. Ta opcja zapewnia łączność warstwy 3 między lokacją lokalną a sieciami wirtualnymi platformy Azure za pośrednictwem dedykowanych linków. Dzięki temu można ustanowić tunel IPSec z lokacji lokalnej do prywatnego adresu IP urządzenia sieci VPN hostowanego w sieci wirtualnej. Prywatna komunikacja równorzędna usługi ExpressRoute może wprowadzać ograniczenia przepustowości, ponieważ brama usługi ExpressRoute znajduje się w ścieżce danych. Aby rozwiązać ten problem, możesz użyć usługi ExpressRoute FastPath . Prywatna komunikacja równorzędna wymaga również bardziej złożonej konfiguracji routingu po stronie lokalnej. Aby uzyskać więcej informacji, zobacz Konfigurowanie połączenia sieci VPN typu lokacja-lokacja za pośrednictwem prywatnej komunikacji równorzędnej usługi ExpressRoute. Na poniższym diagramie przedstawiono tę opcję.

Wybieranie miejsca hostowania urządzeń wirtualnych na platformie Azure

Dostępne opcje obejmują sieci wirtualne zarządzane przez klienta i koncentratory usługi Virtual WAN. Aby podjąć tę decyzję, należy wziąć pod uwagę cechy istniejącego wcześniej środowiska platformy Azure, jeśli istnieje, oraz sposób określania priorytetów w zakresie zmniejszania nakładu pracy związanych z zarządzaniem w porównaniu z możliwością dostosowania konfiguracji do określonych potrzeb. Poniżej przedstawiono niektóre kluczowe zagadnienia.

Należy użyć istniejącej infrastruktury sieciowej platformy Azure na potrzeby łączności z usługą Azure VMware Solution. Jeśli sieć piasty i szprych zarządzanej przez klienta już istnieje w tym samym regionie co chmura prywatna rozwiązania Azure VMware Solution, należy wdrożyć urządzenia zakończenia protokołu IPSec w istniejącym centrum. Jeśli sieć piasty i szprych oparta na usłudze Virtual WAN istnieje w tym samym regionie co chmura prywatna rozwiązania Azure VMware Solution, należy użyć koncentratora Virtual WAN w celu zakończenia działania protokołu IPSec.
W sieci piasty-szprych zarządzanej przez klienta, aby kierować ruch między tunelem IPSec i obwodem zarządzanym usługi ExpressRoute, należy wdrożyć wystąpienie usługi Azure Route Server w sieci wirtualnej koncentratora i skonfigurować je tak, aby zezwalać na ruch między oddziałami. Nie można kierować ruchu między chmurami prywatnymi rozwiązania Azure VMware Solution i lokacjami lokalnymi za pośrednictwem urządzeń zapory wdrożonych w sieci wirtualnej.
Koncentratory usługi Virtual WAN natywnie obsługują routing ruchu między tunelem IPSec połączonym z lokacją lokalną a zarządzanym obwodem usługi ExpressRoute rozwiązania Azure VMware Solution.
Jeśli używasz usługi Virtual WAN, możesz skonfigurować intencję routingu i zasady routingu na potrzeby inspekcji ruchu. Możesz użyć usługi Azure Firewall lub rozwiązań zabezpieczeń innych firm, które są obsługiwane przez usługę Virtual WAN. Zalecamy przejrzenie regionalnej dostępności i ograniczeń intencji routingu.

Wybieranie, które urządzenie wirtualne kończy tunel IPSec

Tunel IPSec, który zapewnia łączność z lokacją lokalną, może zostać przerwany przez usługę Azure VPN Gateway lub przez urządzenia WUS innych firm. Aby podjąć tę decyzję, należy wziąć pod uwagę cechy istniejącego wcześniej środowiska platformy Azure, jeśli istnieje, oraz sposób określania priorytetów w zakresie zmniejszania nakładu pracy związanych z zarządzaniem w porównaniu z możliwością dostosowania konfiguracji do określonych potrzeb. Poniżej przedstawiono niektóre kluczowe zagadnienia.

W obu sieciach piasty i szprych, które są sieciami zarządzanymi przez klienta i piastą i szprychami opartymi na usłudze Virtual WAN, można użyć usługi Azure VPN Gateway do przerwania tuneli IPSec połączonych z lokacjami lokalnymi. Ponieważ są zarządzane przez platformę, bramy sieci VPN platformy Azure wymagają minimalnego nakładu pracy w zakresie zarządzania. Możesz użyć wstępnie istniejących bram, nawet jeśli obsługują inne scenariusze łączności. Zapoznaj się z tymi artykułami, aby uzyskać informacje o obsługiwanych ustawieniach i oczekiwanej wydajności:
Urządzenia WUS innych firm są zwykle używane do kończenie tuneli z lokacji lokalnych w następujących sytuacjach:
- Urządzenie WUS jest urządzeniem CPE (sprzętem lokalnym klienta) rozwiązania SDWAN wdrożonego zarówno na platformie Azure, jak i w lokacji lokalnej.
- Urządzenie WUS to zapora, która wymusza wymagane zasady zabezpieczeń dla połączeń między lokacją lokalną a usługą Azure VMware Solution.

Korzystanie z urządzeń innych firm może zapewnić większą elastyczność i dostęp do zaawansowanych funkcji sieciowych, które nie są obsługiwane przez natywne bramy sieci VPN, ale zwiększa złożoność. Wysoka dostępność staje się Twoim zadaniem. Należy wdrożyć wiele wystąpień.

Tranzyt za pośrednictwem prywatnej komunikacji równorzędnej usługi ExpressRoute

Prywatna komunikacja równorzędna usługi ExpressRoute jest najczęstszym wyborem w przypadku łączenia lokacji lokalnej z siecią wirtualną platformy Azure (lub siecią piasty i szprych) w scenariuszach przedsiębiorstwa. Sieć wirtualna platformy Azure lub sieć wirtualna piasty w topologiach piasty i szprych zawiera bramę usługi ExpressRoute skonfigurowaną przy użyciu połączenia z obwodem usługi ExpressRoute. Ta konfiguracja zapewnia łączność warstwy 3 między siecią wirtualną (lub całą siecią piasty i szprych) a siecią lokacji lokalnej. Jednak nie zapewnia natywnie łączności warstwy 3 z chmurami prywatnymi usługi Azure VMware Solution połączonymi z tą samą siecią wirtualną (lub siecią wirtualną piasty) za pośrednictwem zarządzanego obwodu usługi ExpressRoute. (Zobacz Chmury prywatne usługi ExpressRoute Global Reach i Azure VMware Solution).

To ograniczenie można obejść, wdrażając więcej urządzeń routingu w sieci wirtualnej platformy Azure. Dzięki temu można kierować ruch przez zapory urządzenia WUS hostowane w sieci wirtualnej.

Tranzyt przez prywatną komunikację równorzędną usługi ExpressRoute może wydawać się pożądany, ale zwiększa złożoność i wpływa na wydajność. Należy wziąć pod uwagę tylko wtedy, gdy sieci VPN global reach i IPSec usługi ExpressRoute (opisane w poprzednich sekcjach) nie mają zastosowania.

Dostępne są dwie opcje implementacji:

Pojedyncza sieć wirtualna. W przypadku korzystania z tej opcji obwody zarządzane przez klienta i zarządzane przez klienta usługi Azure VMware Solution są połączone z tą samą bramą usługi ExpressRoute.
Pomocnicza sieć wirtualna tranzytowa. W przypadku korzystania z tej opcji obwód usługi ExpressRoute zarządzany przez klienta, który zapewnia łączność z lokacją lokalną, jest połączony z (zazwyczaj istniejącą) bramą usługi ExpressRoute w sieci wirtualnej koncentratora. Obwód zarządzany usługi Azure VMware Solution jest połączony z inną bramą usługi ExpressRoute wdrożoną w pomocniczej sieci wirtualnej tranzytowej.

Poniższe sekcje zawierają szczegółowe informacje o dwóch opcjach implementacji, w tym:

Kompromisy między wydajnością, kosztami (wymaganymi zasobami platformy Azure) i kosztami zarządzania.
Implementacja płaszczyzny sterowania (sposób wymiany tras między lokacją lokalną a chmurą prywatną).
Implementacja płaszczyzny danych (sposób kierowania pakietów sieciowych między lokacją lokalną a chmurą prywatną).

Pojedyncza sieć wirtualna

W przypadku korzystania z podejścia z pojedynczą siecią wirtualną zarówno obwód zarządzany chmury prywatnej usługi Azure VMware Solution, jak i obwód należący do klienta są połączone z tą samą bramą usługi ExpressRoute, zazwyczaj siecią piasty. Ruch między chmurą prywatną a lokacją lokalną można kierować za pośrednictwem wirtualnych urządzeń WUS zapory wdrożonych w sieci koncentratora. W tym miejscu przedstawiono pojedynczą architekturę sieci wirtualnej:

Płaszczyzna sterowania i płaszczyzna danych są implementowane zgodnie z opisem w tym miejscu:

Płaszczyzna sterowania. Brama usługi ExpressRoute wdrożona w sieci wirtualnej platformy Azure nie może propagować tras między obwodem zarządzanym usługi Azure VMware Solution i obwodem usługi ExpressRoute zarządzanym przez klienta. Usługa Azure Route Server z włączonym ustawieniem odgałęzienia służy do wstrzykiwania tras w obu obwodach dla supersieci, które obejmują przestrzeń adresową chmury prywatnej usługi Azure VMware Solution (sieci zarządzania i segmenty obciążeń) oraz lokalną przestrzeń adresową.

Supersieci, zamiast dokładnych prefiksów składających się na te przestrzenie adresowe, należy ogłosić, ponieważ dokładne prefiksy są już ogłaszane w przeciwnym kierunku przez chmurę prywatną usługi Azure VMware Solution i lokację lokalną. Można używać supersieci tak dużych jak prefiksów RFC 1918, jeśli są one zgodne z konfiguracją sieci lokacji lokalnych. W większości przypadków należy użyć najmniejszych supersieci, które obejmują przestrzeń adresową chmury prywatnej usługi Azure VMware Solution i lokalną przestrzeń adresową. W ten sposób minimalizuje ryzyko konfliktów z konfiguracją routingu lokacji lokalnych.

Trasy dla supersieci pochodzą z urządzeń WUS obsługujących protokół BGP. Urządzenia WUS są skonfigurowane do ustanawiania sesji bpG z usługą Azure Route Server. Urządzenia WUS są tylko częścią płaszczyzny sterowania i nie kierują rzeczywistego ruchu między lokacją lokalną a chmurą prywatną usługi Azure VMware Solution. Implementacja płaszczyzny sterowania jest reprezentowana przez linie przerywane na poprzedniej ilustracji.
Płaszczyzna danych. Implementacja płaszczyzny sterowania, która została opisana wcześniej, przyciąga następujący ruch do bramy usługi ExpressRoute:
- Ruch z lokacji lokalnej przeznaczonej do chmury prywatnej usługi Azure VMware Solution.
- Ruch z chmury prywatnej usługi Azure VMware Solution przeznaczony do lokacji lokalnej.
Jeśli do podsieci GatewaySubnet nie zastosowano żadnych tras zdefiniowanych przez użytkownika, ruch przepływa bezpośrednio między lokacją lokalną a chmurą prywatną usługi Azure VMware Solution. Możesz kierować ruch do pośredniego następnego przeskoku, stosując trasy zdefiniowane przez użytkownika do podsieci GatewaySubnet. Typowym przykładem są zapory urządzenia WUS wymuszające zasady zabezpieczeń sieci na połączeniach między lokacjami lokalnymi i chmurami prywatnymi. Implementacja płaszczyzny danych jest reprezentowana przez linię ciągłą na powyższej ilustracji.

Pomocnicza sieć wirtualna

Możesz użyć pomocniczej sieci wirtualnej do hostowania drugiej bramy usługi ExpressRoute połączonej tylko z obwodem zarządzanym chmury prywatnej usługi Azure VMware Solution. Jeśli używasz tej metody, obwód zarządzany chmury prywatnej i obwód zarządzany przez klienta łączą się z różnymi bramami usługi ExpressRoute. Dwa wystąpienia usługi Azure Route Server służą do ogłaszania odpowiednich tras do każdego obwodu i kontrolowania propagacji trasy między chmurą prywatną a lokacją lokalną. Nie musisz ogłaszać supersieci, tak jak w przypadku pojedynczej opcji sieci wirtualnej opisanej w poprzedniej sekcji. Zmniejszenie obciążenia związanego z zarządzaniem trasami zdefiniowanymi przez użytkownika w podsieci GatewaySubnet. Takie podejście umożliwia kierowanie ruchu między chmurą prywatną a lokacją lokalną za pośrednictwem wirtualnych urządzeń WUS zapory w sieci wirtualnej koncentratora. Implementacja pomocniczej sieci wirtualnej jest pokazana na poniższym diagramie:

Płaszczyzna sterowania i płaszczyzna danych są implementowane zgodnie z opisem w tym miejscu:

Płaszczyzna sterowania. Aby włączyć propagację tras między obwodem zarządzanym chmury prywatnej usługi Azure VMware Solution i obwodem należącym do klienta, musisz mieć wystąpienie usługi Azure Route Server w każdej sieci wirtualnej. Ponieważ dwa wystąpienia usługi Azure Route Server nie mogą ustanowić sąsiedztwa protokołu BGP, do propagowania tras między nimi potrzebne są wirtualne urządzenia WUS obsługujące protokół BGP. W celu zapewnienia wysokiej dostępności należy wdrożyć co najmniej dwa wystąpienia urządzenia WUS. Możesz dodać więcej wystąpień, aby zwiększyć przepływność. Urządzenia WUS obsługujące protokół BGP muszą mieć dwie karty sieciowe dołączone do różnych podsieci. Sesje protokołu BGP w kierunku dwóch serwerów tras (w pomocniczej sieci wirtualnej i sieci wirtualnej koncentratora) muszą zostać ustanowione za pośrednictwem różnych kart sieciowych.

Trasy pochodzące z chmury prywatnej usługi Azure VMware Solution i lokacji lokalnej są zbierane za pośrednictwem obwodów usługi ExpressRoute. Ich ścieżki AS zawierają numer ASN 65515 (zastrzeżony numer ASN platformy Azure używany przez bramy usługi ExpressRoute) i numer ASN 12076 (należący do firmy Microsoft numer ASN używany przez routery brzegowe firmy Microsoft Enterprise we wszystkich lokalizacjach komunikacji równorzędnej). Urządzenia WUS obsługujące protokół BGP muszą usunąć ścieżki AS, aby zapobiec usuwaniu tras przez wykrywanie pętli BGP. Aby uzyskać więcej informacji na temat wymaganej konfiguracji protokołu BGP, zobacz Implementowanie łączności usługi ExpressRoute dla usługi AVS bez globalnego zasięgu. Implementacja płaszczyzny sterowania jest reprezentowana przez linie przerywane na powyższym diagramie.
Płaszczyzna danych. W pomocniczej sieci wirtualnej ruch między chmurą prywatną usługi Azure VMware Solution a lokacją lokalną jest kierowany przez urządzenia WUS z obsługą protokołu BGP. Ruch do i z chmury prywatnej usługi Azure VMware Solution opuszcza lub przechodzi do urządzeń WUS za pośrednictwem karty sieciowej używanej do sesji protokołu BGP z pomocniczym serwerem routingu sieci wirtualnej. Ruch do i z lokacji lokalnej opuszcza lub przechodzi do urządzeń WUS za pośrednictwem karty sieciowej używanej do sesji protokołu BGP z serwerem tras sieci wirtualnej koncentratora. Ta karta sieciowa jest dołączona do podsieci skojarzonej z niestandardową tabelą tras, która:
- Wyłącza uczenie tras protokołu BGP z serwera tras (aby uniknąć pętli).
- Wstawia zaporę sieci piasty do ścieżki danych.
Aby upewnić się, że ruch jest symetrycznie kierowany za pośrednictwem zapory koncentratora, trasy zdefiniowane przez użytkownika dla wszystkich prefiksów używanych w chmurze prywatnej usługi Azure VMware Solution muszą być skonfigurowane w podsieci GatewaySubnet centrum. Aby uzyskać więcej informacji, zobacz Implementowanie łączności usługi ExpressRoute dla usługi AVS bez usługi Global Reach. Implementacja płaszczyzny danych jest reprezentowana przez linię ciągłą na powyższym diagramie.

Następne kroki

Dowiedz się więcej o łączności między usługą Azure VMware Solution i sieciami wirtualnymi platformy Azure.

Połączenie ivity między usługą Azure VMware Solution i sieciami wirtualnymi platformy Azure

Share via