Zagadnienia dotyczące projektowania sieci usługi Azure VMware Solution

Rozwiązanie Azure VMware Solution oferuje prywatne środowisko chmury VMware, do którego użytkownicy i aplikacje mogą uzyskiwać dostęp z lokalnych i opartych na platformie Azure środowisk lub zasobów. Usługi sieciowe, takie jak Azure ExpressRoute i połączenia wirtualnej sieci prywatnej (VPN) zapewniają łączność.

Przed skonfigurowaniem środowiska usługi Azure VMware Solution należy zapoznać się z kilkoma zagadnieniami dotyczącymi sieci. Ten artykuł zawiera rozwiązania dla przypadków użycia, które mogą wystąpić podczas konfigurowania sieci przy użyciu rozwiązania Azure VMware Solution.

Zgodność rozwiązania Azure VMware z AS-Path Prepend

Usługa Azure VMware Solution zawiera uwagi dotyczące stosowania AS-Path Prepend dla nadmiarowych konfiguracji ExpressRoute. Jeśli korzystasz z co najmniej dwóch ścieżek usługi ExpressRoute między środowiskiem lokalnym i platformą Azure, zapoznaj się z poniższymi wskazówkami dotyczącymi wpływu na ruch z usługi Azure VMware Solution do lokalizacji lokalnej za pośrednictwem usługi ExpressRoute GlobalReach.

Ze względu na routing asymetryczny problemy z łącznością mogą wystąpić, gdy usługa Azure VMware Solution nie stosuje mechanizmu AS-Path Prepend i dlatego używa równego kosztu routingu wielościeżkowego (ECMP) w celu wysyłania ruchu do środowiska przez oba obwody usługi ExpressRoute. To zachowanie może powodować problemy z stanowymi urządzeniami inspekcji zapory umieszczonymi za istniejącymi obwodami usługi ExpressRoute.

Wymagania wstępne

W przypadku AS-Path Prepend należy wziąć pod uwagę następujące warunki wstępne:

• Kluczowym punktem jest to, że należy dodać jako prefiks Public numery systemów autonomicznych (ASN), aby wpłynąć na sposób, w jaki rozwiązanie Azure VMware kieruje ruch z powrotem do infrastruktury lokalnej. Jeśli użyjesz Private ASN do dodania prefiksu, rozwiązanie Azure VMware Solution zignoruje to działanie i wystąpi wcześniej opisane zachowanie ECMP. Nawet jeśli używasz prywatnego BGP ASN w lokalnej infrastrukturze, nadal można skonfigurować urządzenia w lokalnej infrastrukturze do korzystania z publicznego ASN podczas poprzedzania tras wychodzących, aby zapewnić zgodność z usługą Azure VMware Solution.
• Zaprojektuj ścieżkę ruchu dla prywatnych numerów ASN tak, aby następowała po publicznym numerze ASN, który zostanie rozpoznany przez Azure VMware Solution. Obwód usługi ExpressRoute rozwiązania Azure VMware nie usuwa żadnych prywatnych numerów ASN, które istnieją na ścieżce po przetworzeniu publicznego numeru ASN.
• Oba lub wszystkie obwody są połączone z rozwiązaniem Azure VMware Solution za pośrednictwem usługi Azure ExpressRoute Global Reach.
• Te same bloki sieciowe są ogłaszane z co najmniej dwóch łączy.
• Chcesz użyć funkcji AS-Path Prepend, aby wymusić, by rozwiązanie Azure VMware preferowało jeden obwód nad drugim.
• Użyj 2-bajtowych lub 4-bajtowych publicznych numerów ASN.

Zarezerwowane prywatne ASN w rozwiązaniu Azure VMware

Usługa Azure VMware Solution korzysta z określonych prywatnych numerów systemu autonomicznego (ASN) dla swojej infrastruktury sieciowej podkładowej. Aby zapobiec konfliktom i zapewnić bezproblemową integrację sieci, klienci nie powinni używać następujących numerów ASN w ramach konfiguracji sieci.

Zastrzeżone numery ASN dla sieci bazowych

Następujące ASN są zarezerwowane dla wewnętrznej infrastruktury usługi Azure VMware Solution i powinny być unikane przez klientów.

• Tier 2 ASN-y: 65300 – 65340

• ASN Tier-1: 65200 – 65240

• ASN transportowe (bramy T0): 64513 (krawędzie NSX), 64600 – 64940

• Zarządzanie numerami ASN: 65000 – 65412, 398656-398670, 400572-400581

Wpływ używania zarezerwowanych numerów ASN

Użycie dowolnej z nazw ASN wymienionych powyżej w danym środowisku może prowadzić do błędów sesji protokołu BGP, konfliktów routingu sieciowego lub przerw w działaniu usługi. Upewnij się, że przypisania ASN nie powielają się z tymi wartościami zarezerwowanymi.

Zarządzanie maszynami wirtualnymi i trasami domyślnymi ze środowiska lokalnego

Jeśli kierujesz z powrotem do sieci lokalnych przy użyciu tylko trasy domyślnej anonsowanej w kierunku platformy Azure, ruch z maszyn wirtualnych vCenter Server i NSX Manager używanych do miejsc docelowych lokalnych z prywatnymi adresami IP nie będzie podążał tą trasą.

Aby uzyskać dostęp do programu vCenter Server i menedżera NSX ze środowiska lokalnego, podaj określone trasy, aby umożliwić ruchowi powrót do tych sieci. Na przykład udostępniaj podsumowania RFC1918 (10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16).

Domyślna trasa do rozwiązania Azure VMware Solution na potrzeby inspekcji ruchu internetowego

Niektóre wdrożenia wymagają inspekcji całego ruchu wychodzącego z rozwiązania Azure VMware Solution do Internetu. Chociaż istnieje możliwość utworzenia wirtualnych urządzeń sieciowych (WUS) w rozwiązaniu Azure VMware Solution, istnieją przypadki użycia, w których te urządzenia już istnieją na platformie Azure i można je zastosować do inspekcji ruchu internetowego z usługi Azure VMware Solution. W takim przypadku można wstrzyknąć trasę domyślną z urządzenia NVA na platformie Azure w celu przyciągnięcia ruchu z usługi Azure VMware Solution i przeanalizowania ruchu przed jego wyjściem do publicznego Internetu.

Na poniższym diagramie opisano podstawową topologię piasty i szprych połączoną z chmurą rozwiązania Azure VMware Solution oraz z siecią lokalną za pośrednictwem usługi ExpressRoute. Na diagramie pokazano, jak wirtualne urządzenie sieciowe (NVA) na platformie Azure ustawia domyślną trasę sieciową (0.0.0.0/0). Usługa Azure Route Server propaguje trasę do usługi Azure VMware Solution za pośrednictwem usługi ExpressRoute.

Komunikacja między usługą Azure VMware Solution a siecią lokalną zwykle odbywa się za pośrednictwem usługi ExpressRoute Global Reach, jak opisano w Podłączanie środowisk lokalnych do rozwiązania Azure VMware.

Łączność między rozwiązaniem Azure VMware Solution i siecią lokalną

Istnieją dwa główne scenariusze dotyczące łączności między rozwiązaniem Azure VMware Solution a siecią lokalną za pośrednictwem wirtualnego urządzenia sieciowego (NVA) innej firmy:

• Organizacje muszą wysyłać ruch między usługą Azure VMware Solution i siecią lokalną za pośrednictwem urządzenia NVA (zwykle zapory sieciowej).
• Usługa ExpressRoute Global Reach nie jest dostępna w określonym regionie w celu połączenia obwodów usługi ExpressRoute rozwiązania Azure VMware Solution i sieci lokalnej.

Istnieją dwie topologie, które można zastosować, aby spełnić wszystkie wymagania dla tych scenariuszy: supernet oraz wirtualna sieć szprychy tranzytowej.

Topologia projektowania supersieci

Jeśli oba kręgi usługi ExpressRoute (do Azure VMware Solution oraz do sieci lokalnej) zostaną zakończone w tej samej bramie ExpressRoute, możesz założyć, że brama będzie routować pakiety pomiędzy nimi. Jednak brama usługi ExpressRoute nie jest w tym celu zaprojektowana. Musisz zawrócić ruch do urządzenia NVA, które może kierować ruchem.

Istnieją dwa wymagania dotyczące przekierowywania ruchu sieciowego do urządzenia NVA:

• NVA powinien rozgłaszać supernet dla rozwiązania Azure VMware i lokalnych prefiksów.

  Możesz użyć supersieci obejmującej zarówno rozwiązanie Azure VMware Solution, jak i prefiksy lokalne. Możesz też użyć indywidualnych prefiksów dla rozwiązania Azure VMware Solution i lokalnych systemów (zawsze mniej specyficznych niż rzeczywiste prefiksy anonsowane za pośrednictwem usługi ExpressRoute). Należy pamiętać, że wszystkie prefiksy supersieci anonsowane do usługi Route Server są propagowane zarówno do rozwiązania Azure VMware Solution, jak i lokalnego.

• Trasy definiowane przez użytkownika w podsieci bramy, które dokładnie odpowiadają prefiksom ogłaszanym z usługi Azure VMware Solution i lokalnie, powodują ruch zawracający z podsieci bramy do wirtualnego urządzenia sieciowego (NVA).

Ta topologia powoduje duże obciążenie związane z zarządzaniem dużymi sieciami, które zmieniają się w czasie. Uwzględnij następujące ograniczenia:

• Za każdym razem, gdy w usłudze Azure VMware Solution tworzony jest segment obciążenia, może być konieczne dodanie User Defined Routes (tras zdefiniowanych przez użytkownika), aby zapewnić, że ruch z usługi Azure VMware Solution przechodzi przez NVA (Virtualne Urządzenie Sieciowe).
• Jeśli środowisko lokalne ma dużą liczbę tras, które się zmieniają, konieczne może być zaktualizowanie konfiguracji protokołu BGP (Border Gateway Protocol) i UDR w supersieci.
• Ponieważ jedna brama usługi ExpressRoute przetwarza ruch sieciowy w obu kierunkach, wydajność może być ograniczona.
• Istnieje limit 400 tras zdefiniowanych przez użytkownika w sieci wirtualnej Azure.

Na poniższym diagramie przedstawiono sposób, w jaki NVA musi anonsować prefiksy, które są bardziej ogólne (mniej specyficzne) i które obejmują sieci z infrastruktury lokalnej oraz Azure VMware Solution. Zachowaj ostrożność przy użyciu tego podejścia. Urządzenie NVA może przyciągać ruch, którego nie powinno, ponieważ reklamuje szersze obszary (na przykład całą 10.0.0.0/8 sieć).

Topologia wirtualnej sieci szprychowej tranzytu

W tej topologii, zamiast propagować mniej specyficzne trasy w celu przyciągnięcia ruchu do bramy ExpressRoute, dwa różne urządzenia NVA w oddzielnych sieciach wirtualnych mogą wymieniać między sobą trasy. Sieci wirtualne mogą propagować te trasy do odpowiednich obwodów usługi ExpressRoute za pośrednictwem protokołu BGP i usługi Azure Route Server. Każda NVA ma pełną kontrolę nad tym, które prefiksy są propagowane do każdego obwodu ExpressRoute.

Na poniższym diagramie pokazano, jak pojedyncza 0.0.0.0/0 trasa jest reklamowana w rozwiązaniu Azure VMware Solution. Pokazuje również, jak poszczególne prefiksy usługi Azure VMware Solution są rozgłaszane w sieci lokalnej.

Alternatywą jest użycie nakładki. Stosowanie pomocniczych kart sieciowych w wirtualnym urządzeniu sieciowym, które nie uczą się tras z usługi Azure Route Server. Następnie skonfiguruj UDR (trasy zdefiniowane przez użytkownika), aby platforma Azure mogła kierować ruch do środowiska zdalnego za pośrednictwem tych kart sieciowych (NICs). Więcej szczegółów można znaleźć w temacie Topologia sieci w skali przedsiębiorstwa i łączność dla usługi Azure VMware Solution.

Ta topologia wymaga złożonej konfiguracji początkowej. Topologia działa zgodnie z oczekiwaniami z minimalnym obciążeniem zarządzania. Złożoność konfiguracji obejmuje następujące elementy:

• Istnieje dodatkowy koszt dodania kolejnej tranzytowej sieci wirtualnej, która obejmuje usługę Azure Route Server, bramę usługi ExpressRoute i inny wirtualny sprzęt sieciowy. Urządzenia WUS mogą również wymagać użycia dużych maszyn wirtualnych w celu spełnienia wymagań dotyczących przepustowości.
• Tunelowanie protokołu IPsec lub VXLAN jest wymagane między dwoma wirtualnymi urządzeniami sieciowymi (NVA), co oznacza, że wirtualne urządzenia sieciowe (NVA) znajdują się również w ścieżce danych. W zależności od typu używanego NVA, może to prowadzić do niestandardowej i złożonej konfiguracji tych urządzeń.

Następne kroki

Po zapoznaniu się z zagadnieniami dotyczącymi projektowania sieci dla rozwiązania Azure VMware Solution rozważ zapoznanie się z następującymi artykułami:

• Koncepcje dotyczące sieci i interkoneksji w rozwiązaniu Azure VMware Solution
• Planowanie wdrożenia rozwiązania Azure VMware Solution
• Samouczek: lista kontrolna planowania sieci dla rozwiązania Azure VMware Solution