Entwurfsphase 1: Konnektivität mit lokalen Standorten
Die Konnektivität mit lokalen Rechenzentren ist der kritischste Entwurfsbereich für die Azure VMware Solution-Netztechnologie. Zu den wichtigsten Anforderungen, die berücksichtigt werden müssen, gehören Folgende:
- Hoher Durchsatz: Migrationen von lokalen vSphere-Umgebungen und Notfallwiederherstellungslösungen erfordern das schnelle Verschieben großer Datenmengen zwischen lokalen Standorten und privaten Azure VMware Solution-Clouds.
- Geringe Wartezeit: Verteilte Anwendungen erfordern möglicherweise eine tiefe Wartezeit für Verbindungen zwischen virtuellen Azure VMware Solution-VMs und lokalen Systemen.
- Leistungsvorhersage: Um vorhersehbaren Durchsatz und Wartezeit zu erzielen, benötigen unternehmenskritische Anwendungen, die in Azure VMware Solution bereitgestellt werden, möglicherweise dedizierte Konnektivitätsdienste (Azure ExpressRoute) zwischen lokalen Standorten und dem Microsoft-Netzwerk.
In diesem Artikel werden die Optionen beschrieben, die von der Azure VMware Solution für die Konnektivität mit lokalen Standorten unterstützt werden:
Die Optionen werden in der absteigenden Reihenfolge der Fähigkeit angezeigt, die zuvor aufgeführten wichtigsten Anforderungen zu erfüllen. Eine Option sollte nur verworfen und die nächste berücksichtigt werden, wenn sie mit den nicht verhandelbaren Einschränkungen eines bestimmten Szenarios in Konflikt steht.
Dieses Flussdiagramm fasst den Prozess für die Auswahl einer Hybridkonnektivitätsoption für Azure VMware Solution zusammen:
ExpressRoute Global Reach
ExpressRoute Global Reach ist die standardmäßige Hybridkonnektivitätsoption, die von Azure VMware Solution unterstützt wird. Sie bietet mit minimaler Komplexität eine Layer 3-Konnektivität zwischen einer privaten Azure VMware Solution-Cloud und einem Remotestandort, die mit einer kundenseitig verwalteten ExpressRoute-Verbindung verbunden ist. Sie können auch die kundenseitig verwaltete ExpressRoute-Verbindung verwenden, um eine Verbindung mit nativen Azure-Diensten herzustellen. Um die Sicherheit zu verbessern oder Bandbreite zu reservieren, können Sie auch eine separate kundenseitig verwaltete Verbindung bereitstellen, die ausschließlich für Azure VMware Solution-Datenverkehr dediziert ist.
Das folgende Diagramm zeigt eine Netzwerktopologie, die Global Reach für die Konnektivität mit lokalen Standorten verwendet. Datenverkehr zwischen privaten Azure VMware Solution-Clouds und lokalen Standorten durchläuft keine virtuellen Azure-Netzwerke.
Hinweis
Um maximale Ausfallsicherheit bereitzustellen, sollten zwei kundenseitig verwaltete ExpressRoute-Verbindungen an verschiedenen Peeringstandorten verwendet werden, um lokale Rechenzentren mit dem Microsoft-Backbone zu verbinden. In diesem Fall sollte jede kundenseitig verwaltete ExpressRoute-Verbindung über eine Global Reach-Verbindung zur privaten Azure VMware Solution-Cloud (und zu Azure Virtual Networks) verfügen. In diesem Artikel finden Sie Anleitungen zu robusten ExpressRoute-Implementierungen.
Anweisungen zum Verbinden einer privaten Azure VMware Solution-Cloud mit einer kundenseitig verwalteten ExpressRoute-Verbindung mithilfe von Global Reach finden Sie unter Peering lokaler Umgebungen mit Azure VMware Solution.
Global Reach-Konnektivität erfüllt die drei wichtigsten Anforderungen vollständig:
- Hoher Durchsatz: Mit ExpressRoute können Sie über dedizierte Leitungen eine Verbindung mit dem Microsoft-Netzwerk herstellen (bis zu 10 GBit/s für anbieterbasierte ExpressRoute oder 100 Gbps für ExpressRoute Direct).
- Tiefe Wartezeit: Mit Global Reach können Sie den Datenverkehr direkt vom Edge des Microsoft-Netzwerks an Azure VMware Solution vSphere-Cluster weiterleiten. Global Reach minimiert die Anzahl der Netzwerkhops zwischen lokalen Standorten und privaten Clouds.
- Vorhersehbare Leistung: Wenn Sie ExpressRoute Global Reach verwenden, wird der Datenverkehr über Links weitergeleitet, bei denen es keine Überlastungsprobleme gibt (bis zur maximalen bereitgestellten Kapazität). Daher bleibt die Round-Trip-Time (RTT) zwischen VMs, die auf Azure VMware Solution und lokalen Hosts ausgeführt werden, im Laufe der Zeit konstant.
Sie können Global Reach nicht in Szenarien verwenden, in denen eine oder mehrere der folgenden Einschränkungen gelten:
ExpressRoute Global Reach ist in der Azure-Region der privaten Azure VMware Solution-Cloud oder dem Meet-Me-Standort der kundenseitig verwalteten ExpressRoute-Verbindung nicht verfügbar. Für diese Einschränkung sind keine Problemumgehungen vorhanden. Aktuelle Informationen zur Verfügbarkeit von Global Reach finden Sie unter Infos zu ExpressRoute Global Reach.
Nicht verhandelbare Netzwerksicherheitsanforderungen sind vorhanden. Wenn ein Firewallgerät nicht auf der lokalen Seite der kundenseitig verwalteten ExpressRoute-Verbindung bereitgestellt werden kann, macht Global Reach alle Azure VMware Solution-Netzwerksegmente verfügbar, einschließlich Verwaltungsnetzwerke (vCenter Server und NSX-T-Verwaltung), für das gesamte Netzwerk, das mit der Verbindung verbunden ist. Das typischste Szenario, in dem dieses Problem auftritt, besteht darin, dass kundenseitig verwaltete ExpressRoute-Verbindungen über MPLS-Netzwerkdienste (auch als ExpressRoute Any-to-Any-Konnektivitätsmodell bezeichnet) implementiert werden. Dieses Szenario wird hier gezeigt:
Wenn ExpressRoute-Konnektivität über MPLS-IP-VPNs implementiert wird, ist es unmöglich, Firewalls an einem einzigen Ort bereitzustellen, um den gesamten Datenverkehr zu und von Azure VMware Solution zu prüfen. In der Regel stellen Organisationen, die MPLS-Netzwerke verwenden, Firewalls in großen Rechenzentren bereit, nicht in all ihren Standorten (die kleine Filialen, Büros oder Filialen sein können).
IPSec-VPNs
Sie können die Konnektivität zwischen privaten Azure VMware Solution-Clouds und lokalen Standorten implementieren, indem Sie den Datenverkehr über ein virtuelles Übertragungsnetzwerk in Azure routen. Das Übertragungsnetzwerk ist über die verwaltete ExpressRoute-Verbindung mit der privaten Azure VMware Solution-Cloud verbunden. Das virtuelle Übertragungsnetzwerk ist über ein IPSec-VPN mit dem lokalen Standort verbunden, wie hier gezeigt:
Sie können Sicherheitsrichtlinien für Verbindungen zwischen lokalen Standorten und der privaten Azure VMware Solution-Cloud (die gestrichelte Linie im Diagramm) erzwingen, indem Sie den Datenverkehr über eine Firewall weiterleiten, wenn das VPN-Gerät keine Firewallfeatures bereitstellt. Diese Konfiguration erfordert Azure Virtual WAN mit Routingabsicht, wie im Abschnitt Entscheiden, wo die virtuellen Geräte in Azure gehostet werden sollen in diesem Artikel beschrieben.
Bevor Sie die IPSec-Konnektivität zwischen lokalen Standorten und virtuellen Übertragungsnetzwerken implementieren, müssen Sie drei Entwurfsentscheidungen treffen:
- Ermitteln Sie, welcher Netzwerkdienst als Unterschicht für den IPSec-Tunnel verwendet werden soll. Die verfügbaren Optionen sind Internetkonnektivität, ExpressRoute Microsoft-Peering und privates ExpressRoute-Peering.
- Ermitteln Sie, wo die virtuellen Geräte gehostet werden sollen, die den IPSec-Tunnel auf der Azure-Seite beendet. Zu den verfügbaren Optionen gehören kundenseitig verwaltete virtuelle Netzwerke und Virtual WAN-Hubs.
- Ermitteln Sie, welches virtuelle Gerät den IPSec-Tunnel auf der Azure-Seite beendet. Die Auswahl des Geräts bestimmt auch die erforderliche Azure-Konfiguration für das Routing des Datenverkehrs zwischen dem IPSec-Tunnel und der verwalteten Azure VMware Solution-Verbindung. Die verfügbaren Optionen sind native Azure VPN Gateway- und IPSec-NVAs (Network Virtual Appliances, virtuelle Netzwerkgeräte) von Drittanbietern.
Dieses Flussdiagramm fasst den Entscheidungsprozess zusammen:
Die Kriterien für die Entscheidungsfindung werden in den folgenden Abschnitten beschrieben.
Auswählen eines Unterschicht-Netzwerkdiensts
Es wird dringend empfohlen, die drei Optionen für die VPN-Unterschicht in der hier dargestellten Reihenfolge zu berücksichtigen:
Internetverbindung. Die öffentliche IP-Adresse, die dem VPN-Gerät zugewiesen ist, das im virtuellen Übertragungsnetzwerk gehostet wird, dient als Remoteendpunkt des IPSec-Tunnels. Aufgrund der tieferen Komplexität und Kosten sollten Sie immer die Internetverbindung auf die Leistung testen und bewerten (erreichbarer IPSec-Durchsatz). Sie sollten diese Option nur verwerfen, wenn die beobachtete Leistung zu niedrig oder inkonsistent ist. Das folgenden Diagramm veranschaulicht diese Option.
ExpressRoute Microsoft-Peering. Diese Option bietet Layer 3-Konnektivität mit öffentlichen Azure-Endpunkten über dedizierte Links. Wie bei Internetverbindungen können Sie damit die öffentliche IP-Adresse eines VPN-Geräts erreichen, das als Remoteendpunkt des IPSec-Tunnels dient und im virtuellen Übertragungsnetzwerk gehostet ist. Sie sollten diese Option nur verwerfen, wenn die Routinganforderungen von Microsoft-Peering nicht erfüllt werden können. Das folgenden Diagramm veranschaulicht diese Option.
Privates ExpressRoute-Peering. Diese Option bietet Layer 3-Konnektivität zwischen einem lokalen Standort und virtuellen Azure-Netzwerken über dedizierte Links. Somit können Sie einen IPSec-Tunnel vom lokalen Standort zur privaten IP-Adresse eines VPN-Geräts einrichten, das in einem virtuellen Netzwerk gehostet wird. Privates ExpressRoute-Peering kann Bandbreitenbeschränkungen einführen, da sich das ExpressRoute-Gateway im Datenpfad befindet. Sie können ExpressRoute FastPath verwenden, um dieses Problem zu beheben. Privates Peering erfordert auch eine komplexere Routingkonfiguration auf der lokalen Seite. Es ist möglich, eine Standort-zu-Standort-VPN-Verbindung über privates ExpressRoute-Peering zu konfigurieren. Das folgenden Diagramm veranschaulicht diese Option.
Entscheiden, wo die virtuellen Geräte in Azure gehostet werden sollen
Zu den verfügbaren Optionen gehören kundenseitig verwaltete virtuelle Netzwerke und Virtual WAN-Hubs. Um diese Entscheidung zu treffen, sollten Sie die Merkmale der bereits vorhandenen Azure-Umgebung berücksichtigen (falls eine vorhanden ist), und wie Sie die Verringerung des Verwaltungsaufwands gegenüber Ihrer Fähigkeit zur Anpassung der Konfiguration auf bestimmte Anforderungen priorisieren möchten. Im folgenden finden Sie einige wichtige Überlegungen.
- Sie sollten bereits vorhandene Azure-Netzwerkinfrastruktur für die Azure VMware Solution-Konnektivität verwenden. Wenn bereits ein kundenseitig verwaltetes Hub-Spoke-Netzwerk in derselben Region wie die private Azure VMware Solution-Cloud vorhanden ist, sollten Sie die Geräte für die IPSec-Terminierung im vorhandenen Hub bereitstellen. Wenn ein Hub-Spoke-Netzwerk, das auf Virtual WAN basiert, in derselben Region wie die private Azure VMware Solution-Cloud vorhanden ist, sollten Sie den Virtual WAN-Hub für die IPSec-Terminierung verwenden.
- In einem kundenseitig verwalteten Hub-Spoke-Netzwerk den Datenverkehr zwischen einem IPSec-Tunnel und der verwalteten ExpressRoute-Leitung zu routen, müssen Sie eine Azure Route Server-Instanz im virtuellen Hubnetzwerk bereitstellen und sie für Branch-zu-Branch-Datenverkehr zulassen konfigurieren. Es ist nicht möglich, den Datenverkehr zwischen privaten Azure VMware Solution-Clouds und lokalen Standorten über Firewallgeräte zu leiten, die im virtuellen Netzwerk bereitgestellt werden.
- Virtual WAN-Hubs unterstützen nativ den Routingdatenverkehr zwischen dem IPSec-Tunnel, der mit der lokalen Site verbunden ist, und der von Azure VMware Solution verwalteten ExpressRoute-Leitung.
- Wenn Sie Virtual WAN verwenden, können Sie Routingabsicht und Routingrichtlinien für die Datenverkehrsüberprüfung konfigurieren. Sie können Azure Firewall oder Sicherheitslösungen von Drittanbietern verwenden, die von Virtual WAN unterstützt werden. Wir empfehlen Ihnen, die regionale Verfügbarkeit und Einschränkungen der Routingabsicht zu überprüfen.
Entscheiden, welches virtuelle Gerät den IPSec-Tunnel beendet
Der IPSec-Tunnel, der eine Verbindung mit dem lokalen Standort bereitstellt, kann vom Azure VPN Gateway oder von NVAs von Drittanbietern beendet werden. Um diese Entscheidung zu treffen, sollten Sie die Merkmale der bereits vorhandenen Azure-Umgebung berücksichtigen (falls eine vorhanden ist), und wie Sie die Verringerung des Verwaltungsaufwands gegenüber Ihrer Fähigkeit zur Anpassung der Konfiguration auf bestimmte Anforderungen priorisieren möchten. Im folgenden finden Sie einige wichtige Überlegungen.
Sowohl in Hub-Spoke-Netzwerken, die kundenseitig verwaltet sind wie auch in Hub-Spoke-Netzwerken, die auf Virtual WAN basieren, können Sie das Azure-VPN Gateway verwenden, um IPSec-Tunnel zu beenden, die mit lokalen Standorten verbunden sind. Da sie von der Plattform verwaltet sind, erfordern Azure VPN-Gateways minimalen Verwaltungsaufwand. Sie können bereits vorhandene Gateways auch dann verwenden, wenn sie andere Konnektivitätsszenarien unterstützen. Sie sollten diese Artikel lesen, um Informationen zu unterstützten Einstellungen und der erwarteten Leistung zu erhalten:
NVAs von Drittanbietern werden in der Regel verwendet, um Tunnel von lokalen Standorten in den folgenden Situationen zu beenden:
- Das NVA ist das Gerät am Kundenstandort (Customer Premises Equipment, CPE) einer SDWAN-Lösung, die sowohl in Azure als auch im lokalen Standort bereitgestellt wird.
- Das NVA ist eine Firewall, welche die erforderliche Sicherheitsrichtlinie für Verbindungen zwischen dem lokalen Standort und Azure VMware Solution erzwingt.
Die Verwendung von Drittanbietergeräten bietet möglicherweise mehr Flexibilität und Zugriff auf erweiterte Netzwerkfunktionen, die von nativen VPN-Gateways nicht unterstützt werden, erhöhen jedoch die Komplexität. Hohe Verfügbarkeit wird Ihre Verantwortung. Sie sollten mehrere Instanzen bereitstellen.
Übertragen über privates ExpressRoute-Peering
Privates ExpressRoute-Peering ist die häufigste Wahl für die Verbindung eines lokalen Standorts mit einem virtuellen Azure-Netzwerk (oder Hub-Spoke-Netzwerk) in Unternehmensszenarien. Das virtuelle Azure-Netzwerk oder das virtuelle Hubnetzwerk in Hub-Spoke-Topologien enthält ein ExpressRoute-Gateway, das mit einer Verbindung mit der ExpressRoute-Leitung konfiguriert ist. Diese Konfiguration bietet Layer 3-Konnektivität zwischen dem virtuellen Netzwerk (oder dem gesamten Hub-Spoke-Netzwerk) und dem Netzwerk des lokalen Standorts. Es stellt jedoch nicht nativ eine Layer 3-Konnektivität mit privaten Azure VMware Solution-Clouds bereit, die über eine verwaltete ExpressRoute-Leitung mit demselben virtuellen Netzwerk (oder einem virtuellen Hubnetzwerk) verbunden sind. (Siehe ExpressRoute Global Reach und private Azure VMware Solution-Clouds.)
Sie können diese Einschränkung umgehen, indem Sie mehr Routinggeräte im virtuellen Azure-Netzwerk bereitstellen. Auf diese Weise können Sie den Datenverkehr über Firewall-NVAs routen, die im virtuellen Netzwerk gehostet werden.
Übertragen über ExpressRoute private Peering mag wünschenswert erscheinen, aber es erhöht die Komplexität und wirkt sich auf die Leistung aus. Sie sollten dies nur berücksichtigen, wenn ExpressRoute Global Reach und IPSec-VPNs (in den vorherigen Abschnitten beschrieben) nicht anwendbar sind.
Es gibt zwei Implementierungsoptionen:
- Einzelnes virtuelles Netzwerk. Wenn Sie diese Option verwenden, werden die kundenseitig verwalteten und von Azure VMware Solution verwalteten Leitungen mit demselben ExpressRoute-Gateway verbunden.
- Virtuelles Hilfsnetzwerk für die Übertragung. Wenn Sie diese Option verwenden, wird die kundenseitig verwaltete ExpressRoute-Leitung, die Verbindungen zur lokalen Site bereitstellt, mit dem (in der Regel bereits vorhandenen) ExpressRoute-Gateway im virtuellen Hubnetzwerk verbunden. Die verwaltete Azure VMware Solution-Leitung ist mit einem anderen ExpressRoute-Gateway verbunden, das in einem virtuellen Hilfsnetzwerk für die Übertragung bereitgestellt wird.
Die folgenden Abschnitte enthalten Details zu den beiden Implementierungsoptionen, einschließlich:
- Kompromisse zwischen Leistung, Kosten (erforderliche Azure-Ressourcen) und Verwaltungsaufwand.
- Implementierung auf Steuerungsebenen (wie Routen zwischen dem lokalen Standort und der privaten Cloud ausgetauscht werden).
- Implementierung auf Datenebene (wie Netzwerkpakete zwischen dem lokalen Standort und der privaten Cloud weitergeleitet werden).
Einzelnes virtuelles Netzwerk
Wenn Sie den Ansatz für ein einzelnes virtuelles Netzwerk verwenden, werden sowohl die verwaltete Leitung der privaten Azure VMware Solution-Cloud als auch die kundeneigene Leitung mit demselben ExpressRoute-Gateway verbunden, in der Regel das Hubnetzwerk. Datenverkehr zwischen der privaten Cloud und dem lokalen Standort kann über Firewall-NVAs weitergeleitet werden, die im Hubnetzwerk bereitgestellt sind. Die einzelne virtuelle Netzwerkarchitektur wird hier gezeigt:
Die Steuerungsebene und die Datenebene werden wie hier beschrieben implementiert:
Steuerungsebene. Ein ExpressRoute-Gateway, das im virtuellen Azure-Netzwerk bereitgestellt wird, kann keine Routen zwischen der kundenseitig verwalteten Azure VMware Solution-Leitung und der kundenseitig verwalteten ExpressRoute-Leitung propagieren. Azure Route Server mit aktivierter Branch-to-Branch-Einstellung wird verwendet, um in beiden Leitungen Routen für Supernetzwerke einzufügen, die den Adressraum der privaten Azure VMware Solution-Cloud (Verwaltungsnetzwerke und Workloadsegmente) und den lokalen Adressraum enthalten.
Supernetzwerke müssen anstelle der exakten Präfixe, die diese Adressräume umfassen, angekündigt werden, da die exakten Präfixe bereits in die entgegengesetzte Richtung durch die private Azure VMware Solution-Cloud und den lokalen Standort angekündigt werden. Sie können Supernetzwerke so groß wie RFC 1918-Präfixe verwenden, wenn sie mit der Netzwerkkonfiguration der lokalen Standorte kompatibel sind. In den meisten Fällen sollten Sie stattdessen die kleinsten Supernetzwerke verwenden, die den Adressraum der privaten Azure VMware Solution-Cloud und den lokalen Adressraum enthalten. Dadurch werden die Risiken von Konflikten mit der Routingkonfiguration der lokalen Standorte minimiert.
Die Routen für die Supernetzwerke stammen von BGP-fähigen NVAs. Die NVAs sind so konfiguriert, um eine BPG-Sitzung mit dem Azure Route Server einzurichten. Die NVAs sind nur Teil der Kontrollebene und leiten nicht den tatsächlichen Datenverkehr zwischen dem lokalen Standort und der privaten Azure VMware Solution-Cloud weiter. Die Implementierung der Steuerungsebene wird durch die gestrichelten Linien in der vorherigen Abbildung dargestellt.
Datenebene. Die zuvor beschriebene Implementierung der Steuerungsebene zieht den folgenden Datenverkehr zum ExpressRoute-Gateway an:
- Datenverkehr vom lokalen Standort, der für die private Azure VMware Solution-Cloud bestimmt ist.
- Datenverkehr aus der privaten Azure VMware Solution-Cloud, der für den lokalen Standort bestimmt ist.
Wenn keine UDRs auf GatewaySubnet angewendet werden, fließt der Datenverkehr direkt zwischen dem lokalen Standort und der privaten Azure VMware Solution-Cloud. Sie können den Datenverkehr an einen zwischengeschalteten nächsten Hop weiterleiten, indem Sie UDRs auf GatewaySubnet anwenden. Firewall-NVAs, die Netzwerksicherheitsrichtlinien für Verbindungen zwischen lokalen Standorten und privaten Clouds erzwingen, sind ein typisches Beispiel. Die Implementierung der Datenebene wird durch die durchgezogene Linie in der vorherigen Abbildung dargestellt.
Virtuelles Hilfsnetzwerk
Sie können ein virtuelles Hilfsnetzwerk verwenden, um ein zweites ExpressRoute-Gateway zu hosten, das nur mit der verwalteten Leitung der privaten Azure VMware Solution-Cloud verbunden ist. Wenn Sie diesen Ansatz verwenden, stellen die verwaltete Leitung der privaten Cloud und die kundenseitig verwaltete Leitung eine Verbindung mit verschiedenen ExpressRoute-Gateways her. Zwei Azure Route Server-Instanzen werden verwendet, um die richtigen Routen für jede Leitung anzukündigen und die Routenverteilung zwischen der privaten Cloud und dem lokalen Standort zu steuern. Sie müssen keine Supernetzwerke ankündigen, wie sie dies für die Option für ein einzelnes virtuelles Netzwerk tun, die im vorherigen Abschnitt beschrieben ist. Der Verwaltungsaufwand für UDRs in GatewaySubnet wird ebenfalls reduziert. Mit diesem Ansatz können Sie den Datenverkehr zwischen der privaten Cloud und dem lokalen Standort über Firewall-NVAs im virtuellen Hubnetzwerk weiterleiten. Die Implementierung des virtuellen Hilfsnetzwerks wird im folgenden Diagramm gezeigt:
Die Steuerungsebene und die Datenebene werden wie hier beschrieben implementiert:
Steuerungsebene. Um die Routenverteilung zwischen der verwalteten Leitung der privaten Azure VMware Solution-Cloud und der kundeneigenen Leitung zu ermöglichen, benötigen Sie eine Azure Route Server-Instanz in jedem virtuellen Netzwerk. Da die beiden Azure Route Server-Instanzen keine BGP-Nachbarschaft herstellen können, sind BGP-fähige NVAs erforderlich, um Routen zwischen ihnen zu propagieren. Für hohe Verfügbarkeit sollten Sie mindestens zwei NVA-Instanzen bereitstellen. Sie können weitere Instanzen hinzufügen, um den Durchsatz zu erhöhen. Die BGP-fähigen NVAs müssen über zwei NICs verfügen, die an verschiedene Subnetze angefügt sind. BGP-Sitzungen zu den beiden Routenservern (im virtuellen Hilfsnetzwerk und dem virtuellen Hubnetzwerk) müssen über verschiedene NICs eingerichtet werden.
Routen, die von der privaten Azure VMware Solution-Cloud stammen und vom lokalen Standort stammen, werden über ExpressRoute-Leitungen gelernt. Ihre AS-Pfade enthalten ASN 65515 (ein Azure-reserviertes ASN, das von ExpressRoute-Gateways verwendet wird) und ASN 12076 (ein Microsoft-eigenes ASN, das von den Microsoft Enterprise-Edgeroutern an allen Peeringorten verwendet wird). Die BGP-fähigen NVAs müssen die AS-Pfade entfernen, um zu verhindern, dass Routen durch die BGP-Schleifenerkennung verworfen werden. Weitere Informationen zur erforderlichen BGP-Konfiguration finden Sie unter Implementieren der Expressroute-Konnektivität für AVS ohne Global Reach. Die Implementierung der Steuerungsebene wird durch die gestrichelten Linien im vorherigen Diagramm dargestellt.
Datenebene. Im virtuellen Hilfsnetzwerk wird der Datenverkehr zwischen der privaten Azure VMware Solution-Cloud und dem lokalen Standort über die BGP-fähigen NVAs weitergeleitet. Datenverkehr zu und von der privaten Azure VMware Solution-Cloud verlässt oder betritt die NVAs über die NIC, die für die BGP-Sitzung mit dem Routenserver des virtuellen Hilfsnetzwerks verwendet wird. Datenverkehr zu und vom lokalen Standort verlässt oder wechselt die NVAs über die NIC, die für die BGP-Sitzung mit dem Routenserver des virtuellen Hubnetzwerks verwendet wird. Diese NIC ist an ein Subnetz angefügt, das einer benutzerdefinierten Routentabelle zugeordnet ist, die Folgendes tut:
- Deaktiviert das Erlernen von BGP-Routen vom Routenserver (um Schleifen zu vermeiden).
- Fügt die Firewall des Hubnetzwerks in den Datenpfad ein.
Um sicherzustellen, dass Datenverkehr symmetrisch über die Hubfirewall geroutet wird, müssen UDRs für alle Präfixe, die in der privaten Azure VMware Solution-Cloud verwendet werden, im GatewaySubnet des Hubs konfiguriert werden. Weitere Informationen finden Sie unter Implementieren der Expressroute-Konnektivität für AVS ohne Global Reach. Die Implementierung der Datenebene wird durch die durchgezogene Linie im vorherigen Diagramm dargestellt.
Nächste Schritte
Erfahren Sie mehr über die Konnektivität zwischen Azure VMware Solution und virtuellen Azure-Netzwerken.