Freigeben über

Informationen zu ExpressRoute-Gateways für virtuelle Netzwerke

Um Ihr virtuelles Azure-Netzwerk (virtuelles Netzwerk) und Ihr lokales Netzwerk mithilfe von Azure ExpressRoute zu verbinden, müssen Sie zuerst ein virtuelles Netzwerkgateway erstellen. Ein Gateway für virtuelle Netzwerke dient zwei Zwecken: dem Austausch von IP-Routen zwischen den Netzwerken und der Weiterleitung des Netzwerkdatenverkehrs.

In diesem Artikel werden verschiedene Gatewaytypen, Gateway-SKUs und die geschätzte Leistung nach SKU erläutert. In diesem Artikel wird auch ExpressRoute FastPath erläutert, ein Feature, mit dem der Netzwerkdatenverkehr von Ihrem lokalen Netzwerk das Virtuelle Netzwerkgateway umgehen kann, um die Leistung zu verbessern.

Gateway-SKUs

Beim Erstellen eines Gateways des virtuellen Netzwerks müssen Sie die gewünschte Gateway-SKU angeben. Wenn Sie eine höhere Gateway-SKU auswählen, werden dem Gateway mehr CPUs und eine höhere Netzwerkbandbreite zugewiesen. Dadurch kann das Gateway einen höheren Netzwerkdurchsatz an das virtuelle Netzwerk bewältigen.

Virtuelle ExpressRoute-Netzwerkgateways können folgende SKUs verwenden:

  • ErGwScale (Vorschau): Weitere Informationen finden Sie unter ExpressRoute Scalable Gateway
  • Standard
  • HighPerformance
  • UltraPerformance
  • ErGw1Az
  • ErGw2Az
  • ErGw3Az

Sie können Ihr Gateway auf eine SKU mit höherer Kapazität innerhalb derselben SKU-Familie aktualisieren, d. h. ein nicht Az-fähiges oder Az-fähiges Gateway.

Sie können z. B. ein Upgrade durchführen:

  • Von einer nicht Az-fähigen SKU zu einer anderen nicht Az-fähigen SKU
  • Von einer Az-fähigen SKU zu einer anderen Az-fähigen SKU

Für alle anderen Downgradeszenarien müssen Sie das Gateway löschen und neu erstellen, was zu Ausfallzeiten führen kann.

Erstellen des Gatewaysubnetzes

Bevor Sie ein ExpressRoute-Gateway erstellen, müssen Sie ein Gatewaysubnetz erstellen. Die VMs und Dienste des Gateways für virtuelle Netzwerke verwenden IP-Adressen aus dem Gatewaysubnetz.

Bei der Erstellung des Gateways des virtuellen Netzwerks, werden Gateway-VMs für das Gatewaysubnetz bereitgestellt und mit den erforderlichen Einstellungen für das ExpressRoute-Gateway konfiguriert. Stellen Sie im Gatewaysubnetz nie etwas anderes bereit. Das Gatewaysubnetz muss als „GatewaySubnet“ bezeichnet werden, damit es ordnungsgemäß funktioniert. Dadurch wird Azure angewiesen, die VMs und Dienste des Gateways für virtuelle Netzwerke in diesem Subnetz bereitzustellen.

Note

  • Benutzerdefinierte Routen mit dem Ziel 0.0.0.0/0 und Netzwerksicherheitsgruppen (NSGs) im Gatewaysubnetz werden nicht unterstützt. Gateways mit dieser Konfiguration können nicht erstellt werden. Gateways benötigen für die ordnungsgemäße Funktion Zugriff auf die Verwaltungscontroller. Die Routenverteilung mit dem Border Gateway Protocol (BGP) sollte im Gatewaysubnetz aktiviert werden, um die Verfügbarkeit des Gateways sicherzustellen. Wenn die BGP-Routenverteilung deaktiviert ist, funktioniert das Gateway nicht.

  • Diagnose, Datenpfad und Steuerungspfad können betroffen sein, wenn sich eine benutzerdefinierte Route mit dem Subnetzbereich des Gateways oder dem öffentlichen IP-Bereich des Gateways überschneidet.

  • Es wird nicht empfohlen, Azure DNS Private Resolver in einem virtuellen Netzwerk einzusetzen, das über ein virtuelles ExpressRoute-Netzwerk-Gateway verfügt, und Wildcard-Regeln festzulegen, um alle Namensauflösungen an einen bestimmten DNS-Server zu leiten. Eine solche Konfiguration kann zu Konnektivitätsproblemen bei der Verwaltung führen.

Bei der Gatewayerstellung geben Sie die Anzahl der im Subnetz enthaltenen IP-Adressen an. Die IP-Adressen im Gatewaysubnetz werden den Gatewaydiensten und -VMs zugeordnet. Einige Konfigurationen erfordern mehr IP-Adressen als andere.

Beziehen Sie sich beim Planen der Größe Ihres Gatewaysubnetzes auf die Dokumentation für die Konfiguration, die Sie erstellen möchten. Beispielsweise erfordert die Konfiguration für die parallele Ausführung von ExpressRoute/VPN Gateway ein größeres Subnetz als die meisten anderen Konfigurationen. Stellen Sie zusätzlich sicher, dass Ihr Gatewaysubnetz über genügend IP-Adressen verfügt, um eventuelle zukünftige Konfigurationen zu ermöglichen.

Es empfiehlt sich, ein Gatewaysubnetz mit /27 oder größer zu erstellen. Wenn Sie beabsichtigen, 16 ExpressRoute-Schaltkreise mit Ihrem Gateway zu verbinden, müssen Sie ein Gatewaysubnetz von /26 oder höher erstellen. Wenn Sie ein Gatewaysubnetz mit dualem Stapel erstellen, empfiehlt es sich, auch einen IPv6-Bereich von /64 oder größer zu verwenden. Diese Einrichtung ermöglicht die meisten Konfigurationen.

Im folgenden Azure Resource Manager-PowerShell-Beispiel wird ein Gatewaysubnetz mit dem Namen „GatewaySubnet“ gezeigt. Sie erkennen, das mit der CIDR-Notation (Classless Interdomain Routing) die Größe /27 angegeben wird. Dies ist für eine ausreichende Anzahl von IP-Adressen für die meisten derzeit üblichen Konfigurationen groß genug.

Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.3.0/27

Important

NSGs im Gatewaysubnetz werden nicht unterstützt. Das Zuordnen einer Netzwerksicherheitsgruppe zu diesem Subnetz könnte dazu führen, dass Ihr virtuelles Netzwerkgateway (VPN- und ExpressRoute-Gateways) nicht mehr wie erwartet funktioniert. Weitere Informationen zu Netzwerksicherheitsgruppen finden Sie unter Filtern des Netzwerkdatenverkehrs mit Netzwerksicherheitsgruppen.

Einschränkungen und Leistung des virtuellen Netzwerkgateways

Featureunterstützung nach Gateway-SKU

Die folgende Tabelle zeigt die Features, die von den einzelnen Gatewaytypen unterstützt werden, und die maximale Anzahl von ExpressRoute-Leitungsverbindungen, die jede Gateway-SKU unterstützt.

Gateway-SKU Koexistenz von VPN Gateway und ExpressRoute FastPath Maximale Anzahl von Leitungsverbindungen
Standard-SKU/ERGw1Az Yes No 4
Hochleistungs-SKU/ERGw2Az Yes No 8
Höchstleistungs-SKU/ErGw3AZ Yes Yes 16
ErGwScale (Vorschau) Yes Ja – mindestens 10 Skalierungseinheiten 4 – mindestens 1 Skalierungseinheit
8 – mindestens 2 Skalierungseinheiten
16 – mindestens 10 Skalierungseinheiten

Note

Die maximale Anzahl von ExpressRoute-Verbindungen vom gleichen Peeringstandort, die eine Verbindung mit demselben virtuellen Netzwerk herstellen können, beträgt 4 für alle Gateways.

Geschätzte Leistungen nach Gateway-SKU

In den folgenden Tabellen finden Sie eine Übersicht über die verschiedenen Arten von Gateways, ihre jeweiligen Einschränkungen und die erwarteten Leistungsmetriken.

Maximal unterstützte Grenzwerte

Diese Tabelle betrifft sowohl das Azure Resource Manager-Bereitstellungsmodell als auch das klassische Bereitstellungsmodell.

Gateway-SKU Megabits pro Sekunde Pakete pro Sekunde Unterstützte Anzahl von virtuellen Computern im virtuellen Netzwerk 1 Limit an Datenflüssen Anzahl der vom Gateway erlernten Routen
Standard/ERGw1Az 1,000 100,000 2,000 200,000 4,000
Hohe Leistung/ERGw2Az 2,000 200,000 4,500 400,000 9,500
Ultra Performance/ErGw3Az 10,000 1,000,000 11,000 1,000,000 9,500
ErGwScale (pro Skalierungseinheit 1-10) 1.000 pro Skalierungseinheit 100.000 pro Skalierungseinheit 2.000 pro Skalierungseinheit 100.000 pro Skalierungseinheit Insgesamt 9.500 pro Gateway
ErGwScale (pro Skalierungseinheit 11-40) 1.000 pro Skalierungseinheit 200.000 pro Skalierungseinheit 1.000 pro Skalierungseinheit 100.000 pro Skalierungseinheit Insgesamt 9.500 pro Gateway

1 Die Werte in der Tabelle sind Schätzungen und variieren je nach CPU-Auslastung des Gateways. Wenn die CPU-Auslastung hoch ist und die Anzahl der unterstützten VMs überschritten wird, beginnt das Gateway mit dem Verwerfen von Paketen.

Note

ExpressRoute kann bis zu 11.000 Routen unterstützen, die Adressräume virtueller Netzwerke, lokale Netzwerke und relevante Verbindungen für das Peering virtueller Netzwerke umfassen. Um die Stabilität Ihrer ExpressRoute-Verbindung zu gewährleisten, sollten Sie nicht mehr als 11.000 Routen für ExpressRoute anzeigen. Die maximale Anzahl der vom Gateway angekündigten Routen beträgt 1.000.

Important

  • Die Anwendungsleistung hängt von mehreren Faktoren ab, z. B. der End-to-End-Latenz und der Anzahl der Datenverkehrsflüsse, die von der Anwendung geöffnet werden. Die Zahlen in der Tabelle stellen die Obergrenze dar, die die Anwendung theoretisch in einer idealen Umgebung erzielen kann. Darüber hinaus führen wir routinemäßige Host- und Betriebssystemwartungen bei ExpressRoute-Gateways für virtuelle Netzwerke aus, um die Zuverlässigkeit des Diensts aufrechtzuerhalten. Während eines Wartungszeitraums werden die Steuerungsebenen- und Datenpfadkapazität des Gateways reduziert.
  • Während eines Wartungszeitraums können zeitweilige Konnektivitätsprobleme mit privaten Endpunktressourcen auftreten.
  • ExpressRoute unterstützt eine maximale TCP- und UDP-Paketgröße von 1.400 Bytes. Pakete, die größer als 1.400 Bytes sind, werden fragmentiert.
  • Azure Route Server kann bis zu 4.000 VMs unterstützen. Dieser Grenzwert umfasst VMs in virtuellen Netzwerken, die per Peering miteinander verknüpft sind. Weitere Informationen finden Sie unter Einschränkungen für Azure Route Server.
  • Die Werte in der obigen Tabelle stellen die Grenzwerte für jede Gateway-SKU dar.

Automatisch zugewiesene öffentliche IP

Das Feature für die automatisch zugewiesene öffentliche IP vereinfacht die ExpressRoute-Gatewaybereitstellung, indem Microsoft die erforderliche öffentliche IP-Adresse in Ihrem Auftrag verwalten kann. Für PowerShell/CLI müssen Sie keine separate öffentliche IP-Ressource für Ihr Gateway erstellen oder verwalten.

Screenshot der Erstellung des virtuellen Netzwerkgateways für ExpressRoute.

Wichtige Vorteile:

  • Verbesserte Sicherheit: Die öffentliche IP wird intern von Microsoft verwaltet und steht Ihnen nicht offen, wodurch risiken im Zusammenhang mit offenen Verwaltungsports reduziert werden.
  • Reduzierte Komplexität: Sie müssen keine öffentliche IP-Ressource bereitstellen oder verwalten.
  • Optimierte Bereitstellung: Die Azure PowerShell und CLI werden während der Gatewayerstellung nicht mehr zur Eingabe einer öffentlichen IP aufgefordert.

Funktionsweise:

Wenn Sie ein ExpressRoute-Gateway erstellen, stellt Microsoft die öffentliche IP-Adresse in einem sicheren Back-End-Abonnement automatisch fest und verwaltet sie. Diese IP wird innerhalb der Gatewayressource gekapselt, sodass Microsoft Richtlinien wie Datenratenlimits erzwingen und die Auditierbarkeit verbessern kann.

Availability:

Die automatisch zugewiesene öffentliche IP ist für virtuelle WAN-Bereitstellungen (Virtual WAN, vWAN) oder erweiterte Zonen nicht verfügbar.

VNet-zu-VNet- und VNet-zu-Virtual WAN-Konnektivität

Standardmäßig ist die VNet-zu-VNet- und VNet-zu-Virtual WAN-Konnektivität über eine ExpressRoute-Leitung für alle Gateway-SKUs deaktiviert. Um diese Konnektivität zu aktivieren, müssen Sie das ExpressRoute-VNet-Gateway so konfigurieren, dass dieser Datenverkehr zugelassen wird. Weitere Informationen finden Sie unter Konnektivität zwischen virtuellen Netzwerken über ExpressRoute. Weitere Informationen zum Aktivieren dieses Datenverkehrs finden Sie unter Aktivieren oder Deaktivieren von VNet-zu-VNet- oder VNet-zu-Virtual WAN-Konnektivität über ExpressRoute.

FastPath

Das ExpressRoute-Gateway für virtuelle Netzwerke wurde entwickelt, um Netzwerkrouten auszutauschen und den Netzwerkdatenverkehr zu steuern. FastPath wurde entwickelt, um die Datenpfadleistung zwischen Ihrem lokalen und dem virtuellen Netzwerk zu verbessern. Wenn FastPath aktiviert ist, wird der Netzwerkdatenverkehr direkt an VMs im virtuellen Netzwerk gesendet und dabei das Gateway umgangen.

Weitere Informationen zu FastPath, einschließlich Einschränkungen und Anforderungen, finden Sie unter About FastPath.

Verbindung zu privaten Endpunkten

Das virtuelle Netzwerkgateway mit ExpressRoute unterstützt die Konnektivität mit privaten Endpunkten, die im gleichen virtuellen Netzwerk wie das virtuelle Netzwerkgateway und über das Peering virtueller Netzwerke bereitgestellt werden.

Important

  • Der Durchsatz und die Kapazität auf Steuerungsebene für Verbindungen mit privaten Endpunktressourcen können im Vergleich zu Verbindungen mit Ressourcen, die keine privaten Endpunkte sind, um die Hälfte reduziert sein.
  • Während eines Wartungszeitraums können zeitweilige Konnektivitätsprobleme mit privaten Endpunktressourcen auftreten.
  • Sie müssen sicherstellen, dass die lokale Konfiguration (einschließlich Router- und Firewalleinstellungen) korrekt ist, damit Pakete für das IP-5-Tupel über einen einzigen nächsten Hop (Microsoft Enterprise Edge-Router) übertragen werden, sofern kein Wartungsereignis vorliegt. Wenn Ihre lokale Firewall- oder Routerkonfiguration dazu führt, dass dasselbe IP-5-Tupel häufig zwischen den nächsten Hops wechselt, treten Konnektivitätsprobleme auf.
  • Stellen Sie sicher, dass Netzwerkrichtlinien (mindestens für UDR-Unterstützung) in den Subnetzen aktiviert sind, in denen private Endpunkte bereitgestellt werden

Private Endpunktkonnektivität und geplante Wartungsereignisse

Verbindungen mit privaten Endpunkten sind zustandsbehaftet. Wenn eine Verbindung mit einem privaten Endpunkt über das private ExpressRoute-Peering hergestellt wird, werden ein- und ausgehende Verbindungen über eine der Back-End-Instanzen der Gatewayinfrastruktur weitergeleitet. Während eines Wartungsereignisses werden Back-End-Instanzen der Infrastruktur des Gateways für virtuelle Netzwerke einzeln neu gestartet, was zu Problemen durch unterbrochene Verbindungen führen kann.

Um Konnektivitätsprobleme mit privaten Endpunkten während Wartungsarbeiten zu vermeiden oder zu minimieren, wird empfohlen, den TCP-Timeout-Wert für Ihre lokalen Anwendungen auf einen Wert zwischen 15 und 30 Sekunden festzulegen. Testen und konfigurieren Sie den optimalen Wert auf der Grundlage Ihrer Anwendungsanforderungen.

REST-APIs und PowerShell-Cmdlets

Zusätzliche technische Ressourcen und spezielle Syntaxanforderungen beim Verwenden von REST-APIs und PowerShell-Cmdlets für Konfigurationen für Gateways für virtuelle Netzwerke finden Sie auf den folgenden Seiten:

Classic Ressourcen-Manager
PowerShell PowerShell
REST-API REST-API

VNet-zu-VNet-Konnektivität

Standardmäßig sind die Verbindungen zwischen virtuellen Netzwerken aktiviert, wenn Sie mehrere virtuelle Netzwerke mit demselben ExpressRoute-Schaltkreis verknüpfen. Es wird empfohlen, Ihre ExpressRoute-Leitung nicht für die Kommunikation zwischen virtuellen Netzwerken zu verwenden. Sie sollten stattdessen das Peering virtueller Netzwerke verwenden. Weitere Informationen dazu, warum die VNet-zu-VNet-Konnektivität über ExpressRoute nicht empfohlen wird, finden Sie unter Konnektivität zwischen virtuellen Netzwerken über ExpressRoute.

Peering in virtuellen Netzwerken

Ein virtuelles Netzwerk mit einem ExpressRoute-Gateway kann Peering virtueller Netzwerke mit bis zu 500 anderen virtuellen Netzwerken nutzen. Das Peering virtueller Netzwerke ohne ExpressRoute-Gateway kann eine höhere Peeringeinschränkung aufweisen.

Verwandte Inhalte