Überlegungen zum Azure VMware Solution-Netzwerkdesign

Azure VMware Solution bietet eine private VMware-Cloudumgebung, auf die Benutzer und Anwendungen von lokalen und Azure-basierten Umgebungen oder Ressourcen zugreifen können. Netzwerkdienste wie Azure ExpressRoute und VPN-Verbindungen (Virtual Private Network) bieten die Konnektivität.

Es gibt mehrere Überlegungen zum Netzwerk, die Sie überprüfen müssen, bevor Sie Ihre Azure VMware-Lösungsumgebung einrichten. Dieser Artikel enthält Lösungen für Anwendungsfälle, die auftreten können, wenn Sie Azure VMware Solution zum Konfigurieren Ihrer Netzwerke verwenden.

Kompatibilität der Azure VMware-Lösung mit AS-Path Prepend

Azure VMware Solution enthält Überlegungen zur Verwendung von AS-Path Prepend für redundante ExpressRoute-Konfigurationen. Wenn Sie zwei oder mehr ExpressRoute-Pfade zwischen lokalem und Azure ausführen, sollten Sie die folgenden Anleitungen für die Einflussnahme des Datenverkehrs aus der Azure VMware-Lösung auf Ihren lokalen Standort über ExpressRoute GlobalReach berücksichtigen.

Durch asymmetrisches Routing können Konnektivitätsprobleme auftreten, wenn Azure VMware Solution den vorangestellten AS-Pfad nicht berücksichtigt und daher ECMP-Routing (Equal Cost MultiPath) verwendet, um Datenverkehr über beide ExpressRoute-Verbindungen an Ihre Umgebung zu senden. Dieses Verhalten kann zu Problemen mit zustandsbehafteten Firewall-Inspektionsgeräten führen, die sich hinter vorhandenen ExpressRoute-Schaltkreisen befinden.

Voraussetzungen

Berücksichtigen Sie für AS-Path Prepend die folgenden Voraussetzungen:

• Der wichtigste Punkt ist, dass Sie öffentliche autonome Systemnummern (Public Autonomous System Numbers, ASNs) voranstellen müssen, um zu beeinflussen, wie die Azure VMware Solution den Datenverkehr zurück zur lokalen Infrastruktur routet. Wenn Sie eine private ASN voranstellen, ignoriert Azure VMware Solution den vorangestellten Pfad, und das zuvor erwähnte ECMP-Verhalten tritt auf. Selbst wenn Sie lokal eine private BGP-ASN verwenden, ist es möglich, Ihre lokalen Geräte so zu konfigurieren, dass ausgehenden Routen eine öffentliche ASN vorangestellt wird, um die Kompatibilität mit Azure VMware Solution sicherzustellen.
• Entwerfen Sie Ihren Datenverkehrspfad für private ASNs nach der öffentlichen ASN, die von Azure VMware Solution berücksichtigt werden soll. Der Azure VMware Solution ExpressRoute-Schaltkreis entfernt keine privaten ASNs, die im Pfad vorhanden sind, nachdem der öffentliche ASN verarbeitet wurde.
• Beide oder alle Schaltkreise sind über die globale Reichweite von Azure ExpressRoute mit Azure VMware Solution verbunden.
• Die gleichen Netzwerkbereiche werden von zwei oder mehr Verbindungen angekündigt.
• Sie möchten AS-Path Prepend verwenden, um zu erzwingen, dass eine Azure VMware-Lösung einen Schaltkreis über eine andere vorziehen soll.
• Verwenden Sie öffentliche ASN-Nummern mit 2 Byte oder 4 Byte.

Reservierte private ASNs in Azure VMware Solution

Azure VMware Solution verwendet spezifische private autonome Systemnummern (ASNs) für die untere Netzwerkinfrastruktur. Um Konflikte zu vermeiden und eine nahtlose Netzwerkintegration sicherzustellen, sollten Kunden die folgenden ASNs nicht innerhalb ihrer Netzwerkkonfigurationen verwenden.

Reservierte ASNs für zugrundeliegende Netzwerke

Die folgenden ASNs sind für die interne Azure VMware-Lösungsinfrastruktur reserviert und sollten von Kunden vermieden werden:

• Tier-2 ASNs: 65300 – 65340

• Tier-1 ASNs: 65200 – 65240

• Transport-ASNs (T0-Gateways): 64513 (NSX Edges), 64600 – 64940

• Management ASNs: 65000 – 65412, 398656-398670, 400572-400581

Auswirkungen der Verwendung reservierter ASNs

Die Verwendung einer der oben in Ihrer Umgebung aufgeführten ASNs kann zu BGP-Sitzungsfehlern, Netzwerkroutingkonflikten oder Dienstunterbrechungen führen. Stellen Sie sicher, dass ihre ASN-Zuordnungen nicht mit diesen reservierten Werten überlappen.

Verwaltung von VMs und Standardrouten vor Ort

Wenn Sie Datenverkehr ausschließlich über eine für Azure angekündigte Standardroute zurück an Ihre lokalen Netzwerke leiten, folgt Datenverkehr von vCenter Server- und NSX Manager-VMs für lokale Ziele mit privaten IP-Adressen nicht dieser Route.

Um vCenter Server und NSX Manager von der lokalen Bereitstellung aus zu erreichen, stellen Sie bestimmte Routen bereit, damit der Datenverkehr einen Rückweg zu diesen Netzwerken hat. Kündigen Sie beispielsweise die RFC1918-Zusammenfassungen an (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16).

Standardroute zur Azure VMware-Lösung für die Überprüfung des Internetdatenverkehrs

Für bestimmte Bereitstellungen ist es erforderlich, den gesamten ausgehenden Datenverkehr von Azure VMware Solution in Richtung Internet zu prüfen. Obwohl es möglich ist, virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) in der Azure VMware Solution zu erstellen, gibt es Anwendungsfälle, in denen diese Appliances bereits in Azure vorhanden sind und genutzt werden können, um den Internetdatenverkehr von der Azure VMware Solution zu prüfen. In diesem Fall kann eine Standardroute aus dem NVA in Azure eingefügt werden, um Datenverkehr von Azure VMware Solution zu gewinnen und den Datenverkehr zu prüfen, bevor er in das öffentliche Internet geht.

Das folgende Diagramm beschreibt eine grundlegende Hub-and-Spoke-Topologie, die mit einer Azure VMware Solution-Cloud und einem lokalen Netzwerk über ExpressRoute verbunden ist. Das Diagramm zeigt, wie die NVA in Azure die Standardroute (0.0.0.0/0) erstellt. Azure Route Server verteilt die Route über ExpressRoute an Azure VMware Solution.

Die Kommunikation zwischen Azure VMware Solution und dem lokalen Netzwerk erfolgt in der Regel über expressRoute Global Reach, wie in lokalen Peer-Umgebungen zu Azure VMware Solution beschrieben.

Konnektivität zwischen Azure VMware-Lösung und einem lokalen Netzwerk

Es gibt zwei Hauptszenarien für die Konnektivität zwischen Azure VMware Solution und einem lokalen Netzwerk über einen Drittanbieter-NVA:

• Organisationen müssen über eine NVA (in der Regel eine Firewall) Datenverkehr zwischen Azure VMware Solution und dem lokalen Netzwerk senden.
• ExpressRoute Global Reach ist in einer bestimmten Region nicht verfügbar, um die ExpressRoute-Schaltkreise von Azure VMware Solution und dem lokalen Netzwerk zu verbinden.

Es gibt zwei Topologien, die Sie anwenden können, um alle Anforderungen für diese Szenarien zu erfüllen: Supernet und virtuelles Transitspeichen-Netzwerk.

Supernetz-Design-Topologie

Wenn sowohl ExpressRoute-Schaltkreise (zu Azure VMware Solution als auch lokal) im selben ExpressRoute-Gateway beendet werden, können Sie davon ausgehen, dass das Gateway Pakete über sie weiterleiten wird. Ein ExpressRoute-Gateway ist jedoch nicht darauf ausgelegt. Sie müssen den Datenverkehr zurück an eine NVA leiten („hairpin“), die den Datenverkehr weiterleiten kann.

Es gibt zwei Anforderungen, um Netzwerkdatenverkehr zurück an eine NVA umleiten („hairpin“) zu können:

• Die NVA sollte ein Supernetz für die Azure VMware Solution- und lokalen Präfixe ankündigen.

  Sie können ein Supernet verwenden, das sowohl Azure VMware-Lösung als auch lokale Präfixe enthält. Sie können auch einzelne Präfixe für Azure VMware Solution und lokal verwenden (immer weniger spezifisch als die tatsächlichen Präfixe, die über ExpressRoute angekündigt wurden). Denken Sie daran, dass alle Supernetz-Präfixe, die für Route Server angekündigt sind, sowohl an Azure VMware Solution als auch an die lokale Infrastruktur weitergeleitet werden.

• UDRs im Gatewaysubnetz, die genau mit den Präfixen übereinstimmen, die von Azure VMware Solution und lokal angekündigt werden, führen dazu, dass Datenverkehr vom Gatewaysubnetz zurück zum NVA umgeleitet wird („hairpin“).

Diese Topologie führt zu einem hohen Verwaltungsaufwand für große Netzwerke, die sich im Laufe der Zeit ändern. Beachten Sie die folgenden Einschränkungen:

• Wann immer ein Workloadsegment in Azure VMware Solution erstellt wird, müssen möglicherweise UDRs hinzugefügt werden, um sicherzustellen, dass der Datenverkehr von Azure VMware Solution über das NVA geleitet wird.
• Wenn Ihre lokale Umgebung über eine große Anzahl von Routen verfügt, die sich ändern, muss die Konfiguration des Border Gateway Protocol (BGP) und der UDR im Supernet möglicherweise aktualisiert werden.
• Da ein einzelnes ExpressRoute-Gateway Netzwerkdatenverkehr in beide Richtungen verarbeitet, kann die Leistung eingeschränkt sein.
• Es gibt ein Azure Virtual Network Limit von 400 UDRs.

Das folgende Diagramm zeigt, wie die NVA Präfixe ankündigen muss, die allgemeiner (weniger spezifisch) sind und die Netzwerke aus der lokalen und Azure VMware-Lösung enthalten. Seien Sie mit diesem Ansatz vorsichtig. Die NVA könnte möglicherweise unerwünschten Datenverkehr anziehen, da es größere Reichweiten ankündigt (z. B. das gesamte 10.0.0.0/8-Netzwerk).

Virtuelle Spoke-Netzwerktopologie für den Transit

Statt weniger spezifische Routen zu propagieren, um Traffic zum ExpressRoute-Gateway anzuziehen, können in dieser Topologie zwei verschiedene NVAs in separaten virtuellen Netzwerken miteinander Routen austauschen. Die virtuellen Netzwerke können diese Routen über BGP und Azure Route Server an ihre jeweiligen ExpressRoute-Schaltkreise weitergeben. Jeder NVA verfügt über die vollständige Kontrolle darüber, welche Präfixe an jeden ExpressRoute-Schaltkreis verteilt werden.

Das folgende Diagramm zeigt, wie eine einzelne 0.0.0.0/0 Route an Azure VMware Solution angekündigt wird. Außerdem wird gezeigt, wie die einzelnen Azure VMware-Lösungspräfixe an das lokale Netzwerk weitergegeben werden.

Es gibt eine Alternative zur Verwendung eines Overlays. Wenden Sie sekundäre NICs im NVA an, die die Routen von Azure Route Server nicht erlernen. Konfigurieren Sie dann UDRs so, dass Azure Datenverkehr über diese NICs an die Remoteumgebung weiterleiten kann. Weitere Details finden Sie in Unternehmensweite Netzwerktopologie und Konnektivität für die Azure VMware-Lösung.

Für diese Topologie ist eine komplexe Ersteinrichtung erforderlich. Die Topologie funktioniert dann wie erwartet mit minimalem Verwaltungsaufwand. Die Einrichtungskomplexität umfasst Folgendes:

• Es gibt zusätzliche Kosten, um ein weiteres virtuelles Transitnetzwerk hinzuzufügen, das Azure Route Server, ein ExpressRoute-Gateway und eine andere NVA umfasst. Die NVAs müssen möglicherweise auch große VM-Größen verwenden, um die Durchsatzanforderungen zu erfüllen.
• Zwischen den beiden NVAs ist IPsec- oder VXLAN-Tunneln erforderlich, was bedeutet, dass sich die NVAs auch im Datenpfad befinden. Je nachdem, welche Art von NVA Sie verwenden, kann dies zu einer benutzerdefinierten und komplexen Konfiguration für diese NVAs führen.

Nächste Schritte

Berücksichtigen Sie nach dem Erlernen der Überlegungen zum Netzwerkdesign für Azure VMware Solution die folgenden Artikel:

• Azure VMware Solution – Netzwerk- und Interkonnektivitätskonzepte
• Planen der Azure VMware-Lösungsbereitstellung
• Lernprogramm: Prüfliste für die Netzwerkplanung für Azure VMware-Lösung