Freigeben über


Informationen zu ExpressRoute-Gateways für virtuelle Netzwerke

Wenn Sie Ihr virtuelles Azure-Netzwerk und Ihr lokales Netzwerk über ExpressRoute verbinden möchten, 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, das es dem Netzwerkdatenverkehr aus Ihrem lokalen Netzwerk ermöglicht, das virtuelle Netzwerkgateway zu umgehen, um die Leistung zu verbessern.

Gatewaytypen

Beim Erstellen eines Gateways für virtuelle Netzwerke müssen mehrere Einstellungen angegeben werden. Eine dieser erforderlichen Einstellungen, -GatewayType, gibt an, ob das Gateway für ExpressRoute- oder für VPN-Datenverkehr verwendet wird. Die zwei Gatewaytypen sind:

  • Vpn – Wenn verschlüsselter Netzwerkdatenverkehr über das öffentliche Internet gesendet wird, verwenden Sie den Gatewaytyp „Vpn“. Dieser Gatewaytyp wird auch als VPN-Gateway bezeichnet. Bei Site-to-Site-, Point-to-Site- und VNet-zu-VNet-Verbindungen wird jeweils VPN Gateway verwendet.

  • ExpressRoute – Verwenden Sie den Gatewaytyp „ExpressRoute“, wenn Netzwerkdatenverkehr über eine private Verbindung gesendet wird. Dieser Gatewaytyp wird auch als ExpressRoute-Gateway bezeichnet und wird zum Konfigurieren von ExpressRoute verwendet.

Ein virtuelles Netzwerk kann pro Gatewaytyp immer nur über ein einzelnes virtuelles Netzwerkgateway verfügen. So können Sie beispielsweise über ein Gateway für virtuelle Netzwerke mit dem Wert „Vpn“ für -GatewayType und über ein Gateway für virtuelle Netzwerke mit dem Wert „ExpressRoute“ für -GatewayType verfügen.

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 wählen, werden dem Gateway mehr CPUs und eine höhere Bandbreite zugewiesen. Infolgedessen unterstützt das Gateway einen höheren Netzwerkdurchsatz im virtuellen Netzwerk.

Virtuelle ExpressRoute-Netzwerkgateways können folgende SKUs verwenden:

  • ERGwScale (Vorschau)
  • Standard
  • HighPerformance
  • UltraPerformance
  • ErGw1Az
  • ErGw2Az
  • ErGw3Az

Wenn Sie Ihr Gateway auf eine SKU mit höherer Kapazität aktualisieren möchten, können Sie das Tool für die nahtlose Gatewaymigration im Azure-Portal oder in PowerShell verwenden. Folgende Upgrades werden unterstützt:

  • Nicht VZ-fähige SKU mit Basic-IP zu nicht VZ-fähiger SKU mit Standard-IP
  • Nicht VZ-fähige SKU mit Basic-IP zu VZ-fähiger SKU mit Standard-IP
  • Nicht VZ-fähige SKU mit Standard-IP zu VZ-fähiger SKU mit Standard-IP

Weitere Informationen finden Sie unter Migrieren zu einem verfügbarkeitszonenfähigen Gateway.

Für alle anderen Herabstufungsszenarios müssen Sie das Gateway löschen und neu erstellen. Das Neuerstellen eines Gateways führt zu Ausfällen.

Gatewaysubnetz

Bevor Sie ein ExpressRoute-Gateway erstellen, müssen Sie ein Gatewaysubnetz erstellen. Das Gatewaysubnetz enthält die IP-Adressen, die von den VMs und Diensten des virtuellen Netzwerkgateways verwendet werden. 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 den Namen „GatewaySubnet“ aufweisen, damit es einwandfrei funktioniert. Wenn Sie das Gatewaysubnetz „GatewaySubnet“ genannt haben, erkennt Azure, dass die VMs und Dienste des virtuellen Gatewaynetzwerks in dieses Subnetz bereitgestellt werden sollen.

Hinweis

  • Benutzerdefinierte Routen mit einem 0.0.0.0/0-Ziel und 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. BGP-Routenverteilung sollte für das Gatewaysubnetz auf „Aktiviert“ festgelegt werden, um die Verfügbarkeit des Gateways zu gewährleisten. Wenn die BGP-Routenverteilung auf deaktiviert festgelegt 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 (/27, /26 usw.) zu erstellen. Wenn Sie 16 ExpressRoute-Leitungen mit Ihrem Gateway verbinden möchten, müssen Sie ein Gatewaysubnetz mit einer Größe von mindestens /26 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 Resource Manager-PowerShell-Beispiel ist ein Gatewaysubnetz mit dem Namen GatewaySubnet zu sehen. Sie erkennen, das mit der CIDR-Notation die Größe /27 angegeben wird. Dies ist für eine ausreichende Zahl von IP-Adressen für die meisten Konfigurationen, die derzeit üblich sind, groß genug.

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

Wichtig

Netzwerksicherheitsgruppen (NSGs) im Gateway-Subnetz 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 Was ist eine Netzwerksicherheitsgruppe (NSG)?.

Einschränkungen und Leistung des virtuellen Netzwerkgateways

Featureunterstützung nach Gateway-SKU

In der folgenden Tabelle sind die Features aufgeführt, die für die einzelnen Gatewaytypen und die maximale Anzahl von ExpressRoute-Verbindungen unterstützt werden, die von jeder Gateway-SKU unterstützt werden.

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

Hinweis

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. Diese Werte sind von den folgenden Testbedingungen abgeleitet und stellen die maximalen Unterstützungsgrenzwerte dar. Die tatsächliche Leistung kann abhängig davon variieren, wie genau diese Testbedingungen vom Datenverkehr repliziert werden.

Testbedingungen

Gateway-SKU Datenverkehr aus der lokalen Umgebung Anzahl der vom Gateway angekündigten Routen Anzahl der vom Gateway erlernten Routen
Standard/ERGw1Az 1 GBit/s 500 4000
Hochleistung/ERGw2Az 2 GBit/s 500 9\.500
Höchstleistung/ErGw3Az 10 GBit/s 500 9\.500
ErGwScale (pro Skalierungseinheit) 1 GBit/s 500 4\.000

Hinweis

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.

Leistungsergebnisse

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 der VMs im virtuellen Netzwerk 1 Limit an Datenflüssen
Standard/ERGw1Az 1.000 100.000 2.000 200.000
Hochleistung/ERGw2Az 2\.000 200.000 4\.500 400.000
Höchstleistung/ErGw3Az 10.000 1\.000.000 11.000 1\.000.000
ErGwScale (pro Skalierungseinheit) 1.000 100.000 2.000 100.000 pro Skalierungseinheit

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.

Wichtig

  • Die Anwendungsleistung hängt von mehreren Faktoren ab, z. B. der End-to-End-Wartezeit und der Anzahl der Datenverkehrsflüsse, die die Anwendung öffnet. Die Zahlen in der Tabelle stellen die Obergrenze dar, die die Anwendung theoretisch in einer idealen Umgebung erzielen kann. Darüber hinaus führt Microsoft routinemäßige Host- und Betriebssystemwartung auf dem ExpressRoute Virtual Network Gateway aus, um die Zuverlässigkeit des Diensts aufrechtzuerhalten. Während eines Wartungszeitraums werden die Steuerungsebene und die 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 1400 Bytes. Ein Paket, das größer als 1400 Bytes ist, wird 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.

SKUs für zonenredundante Gateways

Sie können VPN- und ExpressRoute-Gateways auch in Azure-Verfügbarkeitszonen bereitstellen. Durch diese Konfiguration werden sie physisch und logisch in verschiedene Verfügbarkeitszonen unterteilt, wodurch Ihre lokale Netzwerkkonnektivität zu Azure vor Ausfällen auf Zonenebene geschützt wird.

Zonenredundante ExpressRoute-Gateway

Zonenredundante Gateways verwenden bestimmte neue Gateway-SKUs für ExpressRoute-Gateway.

  • ErGw1AZ
  • ErGw2AZ
  • ErGw3AZ
  • ErGwScale (Vorschau)

Die neuen Gateway-SKUs unterstützen zudem andere Bereitstellungsoptionen, die Ihre Anforderungen am besten zu erfüllen. Wenn Sie ein virtuelles Netzwerkgateway mit den neuen Gateway-SKUs erstellen, können Sie das Gateway in einer bestimmten Zone bereitstellen. Dieser Gatewaytyp wird als zonenbasiertes Gateway bezeichnet. Wenn Sie ein zonenbasiertes Gateway bereitstellen, werden alle Instanzen des Gateways in derselben Verfügbarkeitszone bereitgestellt.

Informationen zum Migrieren eines ExpressRoute-Gateways finden Sie unter Gatewaymigration.

Skalierbares ExpressRoute-Gateway (Vorschau)

Die SKU des virtuellen ErGwScale-Netzwerkgateways ermöglicht es Ihnen, 40-GBit/s-Konnektivität mit VMs und privaten Endpunkten im virtuellen Netzwerk zu erreichen. Mit dieser SKU können Sie eine minimale und maximale Skalierungseinheit für die Architektur des virtuellen Netzwerkgateways festlegen, die basierend auf der aktiven Bandbreite oder der Flow-Zahl automatisch skaliert wird. Sie können auch eine feste Skalierungseinheit festlegen, um eine konstante Konnektivität bei einem gewünschten Bandbreitenwert aufrechtzuerhalten.

Bereitstellung der Verfügbarkeitszone und regionale Verfügbarkeit

ErGwScale unterstützt sowohl zonale als auch zonenredundante Bereitstellungen in Azure-Verfügbarkeitszonen. Weitere Informationen zu diesen Konzepten sind in der Dokumentation Zonale und zonenredundante Dienste enthalten.

Die öffentliche Vorschau ist in den folgenden Regionen verfügbar:

  • Australien (Osten)
  • Brasilien Süd
  • Kanada, Mitte
  • East US
  • Asien, Osten
  • Frankreich, Mitte
  • Deutschland, Westen-Mitte
  • Indien, Mitte
  • Italien, Norden
  • Nordeuropa
  • Norwegen, Osten
  • Schweden, Mitte
  • Vereinigte Arabische Emirate, Norden
  • UK, Süden
  • USA, Westen 2
  • USA, Westen 3

Automatische Skalierung im Vergleich zu festen Skalierungseinheiten

Die Infrastruktur des virtuellen Netzwerk-Gateways skaliert automatisch zwischen der minimalen und der maximalen Skalierungseinheit, die Sie basierend auf der Bandbreitenauslastung oder der Flow-Zahl konfigurieren. Skalierungsvorgänge können bis zu 30 Minuten dauern. Wenn Sie eine feste Konnektivität mit einem bestimmten Bandbreitenwert erzielen möchten, können Sie eine feste Skalierungseinheit konfigurieren, indem Sie die minimale Skalierungseinheit und die maximale Skalierungseinheit auf denselben Wert festlegen.

Begrenzungen

  • Basic IP: ErGwScale unterstützt die Basic IP-SKU nicht. Sie müssen eine Standard IP-SKU verwenden, um ErGwScale zu konfigurieren.
  • Minimale und maximale Skalierungseinheiten: Sie können die Skalierungseinheit für ErGwScale zwischen 1-40 konfigurieren. Die minimale Skalierungseinheit darf nicht niedriger als 1 sein, und die maximale Skalierungseinheit darf nicht höher als 40 sein.
  • Migrationsszenarien: Sie können in der öffentlichen Vorschau nicht von Standard/ErGw1Az, HighPerf/ErGw2Az/UltraPerf/ErGw3Az zu ErGwScale migrieren.

Preisberechnung

ErGwScale ist während der öffentlichen Vorschau kostenlos. Informationen zu ExpressRoute-Preisen finden Sie unter Azure ExpressRoute-Preise.

Geschätzte Leistung pro Skalierungseinheit

Unterstützte Leistung pro Skalierungseinheit

Skalierungseinheit Bandbreite (GBit/s) Pakete pro Sekunde Verbindungen pro Sekunde Maximale VM-Verbindungen 1 Maximale Anzahl der Flows
1 - 10 1 100.000 7\.000 2,000 100.000
11-40 1 100.000 7\.000 1\.000 100.000

Beispielleistung mit Skalierungseinheit

Skalierungseinheit Bandbreite (GBit/s) Pakete pro Sekunde Verbindungen pro Sekunde Maximale VM-Verbindungen 1 Maximale Anzahl der Flows
10 10 1\.000.000 70.000 20.000 1\.000.000
20 20 2\.000.000 140.000 30.000 2\.000.000
40 40 4\.000.000 280 000 50.000 4\.000.000

1 Maximale VM-Verbindungen werden ab 10 Skalierungseinheiten anders skaliert. Die ersten 10 Skalierungseinheiten bieten Kapazität für 2.000 VMs pro Skalierungseinheit. Die Skalierungseinheiten 11 und höher bieten 1.000 mehr VM-Kapazität pro Skalierungseinheit.

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-Verbindung 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. Informationen zum Aktivieren dieses Datenverkehrs finden Sie unter Aktivieren oder Deaktivieren von VNet-zu-VNet- oder VNet-zu-Virtual WAN-Datenverkehr über ExpressRoute.

FastPath

Das virtuelle Netzwerkgateway ExpressRoute 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 aktiviert, sendet FastPath den Netzwerkdatenverkehr direkt an virtuelle Computer im virtuellen Netzwerk und umgeht dabei das Gateway.

Weitere Informationen zu FastPath, einschließlich Einschränkungen und Anforderungen, finden Sie unter Informationen zu 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.

Wichtig

  • Der Durchsatz und die Kapazität der 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 werden.
  • 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, MSEE) ü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.

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 eingehende und ausgehende Verbindungen über eine der Back-End-Instanzen der Gatewayinfrastruktur weitergeleitet. Während eines Wartungsereignisses werden Back-End-Instanzen der Infrastruktur des virtuellen Netzwerkgateways einzeln neu gestartet, was zu unterbrochenen Verbindungsproblemen führen kann.

Um Konnektivitätsprobleme mit privaten Endpunkten während der Wartungsarbeiten zu vermeiden oder zu minimieren, empfehlen wir, den TCP-Timeout-Wert für Ihre lokalen Anwendungen auf einen Wert zwischen 15 und 30 Sekunden einzustellen. 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 virtuelle Netzwerkgateways finden Sie auf den folgenden Seiten:

Klassisch Ressourcen-Manager
PowerShell PowerShell
REST-API REST-API

VNet-to-VNet-Konnektivität

Standardmäßig sind die Verbindungen zwischen virtuellen Netzwerken aktiviert, wenn Sie mehrere virtuelle Netzwerke mit demselben ExpressRoute-Schaltkreis verknüpfen. Microsoft empfiehlt, ihre ExpressRoute-Verbindung nicht für die Kommunikation zwischen virtuellen Netzwerken zu verwenden. Wir empfehlen Ihnen, stattdessen virtuelles Netzwerk-Peering zu verwenden. Weitere Informationen dazu, warum die Konnektivität zwischen VNets ü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.

Nächste Schritte