Überprüfen der ExpressRoute-Konnektivität
Dieser Artikel hilft Ihnen beim Überprüfen der Azure ExpressRoute-Konnektivität und beim Beheben von Problemen. ExpressRoute erweitert ein lokales Netzwerk über eine private Verbindung, die meistens von einem Konnektivitätsanbieter bereitgestellt wird, in die Microsoft Cloud. Die ExpressRoute-Konnektivität umfasst in der Regel drei verschiedene Netzwerkzonen:
- Kundennetzwerk
- Anbieternetzwerk
- Microsoft-Rechenzentrum
Hinweis
Über das direkte ExpressRoute-Konnektivitätsmodell können Sie eine direkte Verbindung mit dem Port des Microsoft Enterprise Edge(MSEE)-Routers herstellen. Daher umfasst das direkte Konnektivitätsmodell nur Netzwerkzonen für Sie und für Microsoft.
In diesem Artikel wird beschrieben, ob und wo ein Konnektivitätsproblem vorliegt. Dabei können Sie sich auch an das zuständige Team wenden, um Unterstützung zur Behebung eines Problems zu erhalten.
Wichtig
Dieser Artikel soll Ihnen helfen, einfache Probleme zu untersuchen und zu beheben. Er dient nicht als Ersatz für den Microsoft-Support. Wenn Sie ein Problem nicht mithilfe des Leitfadens in diesem Artikel lösen können, öffnen Sie ein Supportticket beim Microsoft-Support.
Überblick
Das folgende Diagramm zeigt die logische Verbindung eines Kundennetzwerks mit einem Microsoft-Netzwerk über ExpressRoute.
Im obigen Diagramm stehen die Zahlen für wichtige Netzwerkpunkte:
- Computegerät des Kunden (z. B. ein Server oder PC).
- Edge-Router des Kunden (CEs).
- Edge-Router/-Switches (PEs) des Anbieters mit Verbindung zu Edge-Routern des Kunden.
- PEs in Richtung Microsoft Enterprise Edge ExpressRoute-Routern (MSEEs). In diesem Artikel werden sie als PE-MSEEs bezeichnet.
- MSEEs.
- Gateway für virtuelle Netzwerke.
- Computegerät im virtuellen Azure-Netzwerk.
In diesem Artikel werden diese Netzpunkte manchmal mit der zugehörigen Nummer bezeichnet.
Je nach ExpressRoute-Konnektivitätsmodell können die Netzwerkpunkte 3 und 4 Switches (Layer-2-Geräte) oder Router (Layer-3-Geräte) sein. Die ExpressRoute-Konnektivitätsmodelle sind „Cloud Exchange-Zusammenstellung“, „Point-to-Point-Ethernet-Verbindung“ oder „Any-to-Any-Verbindung“ (IPVPN).
Im Modell der direkten Konnektivität gibt es die Netzpunkte 3 und 4 nicht. Stattdessen sind CEs (2) über Dark Fiber direkt mit MSEEs verbunden.
Wenn die Konnektivitätsmodelle „Cloud Exchange-Zusammenstellung“, „Point-to-Point-Ethernet“ oder „Direkte Konnektivität“ verwendet werden, richten die CEs (2) Border Gateway Protocol(BGP)-Peering mit MSEEs (5) ein.
Bei Verwendung des Any-to-Any-Konnektivitätsmodells (IPVPN) richten die PE-MSEEs (4) BGP-Peering mit MSEEs (5) ein. Von Microsoft empfangene Routen werden dann von PE-MSEEs über das Netzwerk des IPVPN-Dienstanbieters an das Kundennetzwerk zurückgegeben.
Hinweis
Um Hochverfügbarkeit zu gewährleisten, stellt Microsoft eine vollständig redundante parallele Konnektivität zwischen MSEE- und PE-MSEE-Paaren her. Es empfiehlt sich auch, zwischen dem Kundennetzwerk- und PE/CE-Paar einen vollständig redundanten parallelen Netzwerkpfad einzurichten. Weitere Informationen zur Hochverfügbarkeit finden Sie im Artikel Entwurf für Hochverfügbarkeit mit ExpressRoute.
Im Folgenden sind die logischen Schritte zur Problembehandlung der ExpressRoute-Verbindung aufgeführt.
Überprüfen von Verbindungsbereitstellung und -zustand
Beim Bereitstellen einer ExpressRoute-Verbindung werden redundante Layer-2-Verbindungen zwischen CEs/PE-MSEEs (2/4) und MSEEs (5) hergestellt. Weitere Informationen dazu, wie Sie eine ExpressRoute-Verbindung erstellen, ändern, bereitstellen und überprüfen, finden Sie im Artikel Erstellen und Ändern einer ExpressRoute-Verbindung.
Tipp
Mit einem Dienstschlüssel wird eine ExpressRoute-Verbindung eindeutig identifiziert. Falls Sie von Microsoft oder von einem ExpressRoute-Partnerunternehmen Hilfe beim Lösen eines ExpressRoute-Problems benötigen, sollten Sie den Dienstschlüssel angeben, um die Leitung eindeutig zu identifizieren.
Überprüfung über das Azure-Portal
Öffnen Sie im Azure-Portal die Seite der ExpressRoute-Verbindung. Im Abschnitt 
der Seite wird die ExpressRoute-Zusammenfassung aufgelistet, wie im folgenden Screenshot dargestellt:
Auf dem ExpressRoute-Blatt „Zusammenfassung“ ist unter Schaltkreisstatus der Status der Verbindung auf Microsoft-Seite angegeben. Unter Anbieterstatus ist angegeben, ob für die Verbindung auf Dienstanbieter-Seite „Bereitgestellt/Nicht bereitgestellt“ gilt.
Damit eine ExpressRoute-Verbindung betriebsbereit ist, muss Schaltkreisstatus auf Aktiviert und Anbieterstatus auf Bereitgestellt festgelegt sein.
Hinweis
Wenn Schaltkreisstatus nach der Konfiguration einer ExpressRoute-Verbindung immer noch den Status Nicht aktiviert aufweist, wenden Sie sich bitte an den Microsoft-Support. Weist dagegen Anbieterstatus immer noch den Status Nicht bereitgestellt auf, wenden Sie sich bitte an Ihren Dienstanbieter.
Überprüfung per PowerShell
Verwenden Sie den folgenden Befehl, um alle ExpressRoute-Verbindungen in einer Ressourcengruppe aufzulisten:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Tipp
Wenn Sie den Namen einer Ressourcengruppe suchen, können Sie ihn durch Auflisten aller Ressourcengruppen in Ihrem Abonnement ermitteln. Verwenden Sie dazu den Befehl Get-AzResourceGroup.
Verwenden Sie den folgenden Befehl, um eine bestimmte ExpressRoute-Verbindung in einer Ressourcengruppe auszuwählen:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Hier sehen Sie eine Beispielantwort:
Name : Test-ER-Ckt
ResourceGroupName : Test-ER-RG
Location : westus2
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt
Etag : W/"################################"
ProvisioningState : Succeeded
Sku : {
"Name": "Standard_UnlimitedData",
"Tier": "Standard",
"Family": "UnlimitedData"
}
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
ServiceProviderNotes :
ServiceProviderProperties : {
"ServiceProviderName": "****",
"PeeringLocation": "******",
"BandwidthInMbps": 100
}
ServiceKey : **************************************
Peerings : []
Authorizations : []
Achten Sie besonders auf die folgenden Felder, um zu überprüfen, ob eine ExpressRoute-Verbindung betriebsbereit ist:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Hinweis
Wenn Schaltkreisstatus nach der Konfiguration einer ExpressRoute-Verbindung immer noch den Status Nicht aktiviert aufweist, wenden Sie sich an den Microsoft-Support. Weist dagegen Anbieterstatus immer noch den Status Nicht bereitgestellt auf, wenden Sie sich an Ihren Dienstanbieter.
Überprüfen der Peeringkonfiguration
Nachdem der Dienstanbieter die Bereitstellung der ExpressRoute-Verbindung abgeschlossen hat, können über die ExpressRoute-Verbindung zwischen CEs/MSEE-PEs (2/4) und MSEEs (5) mehrere eBGP-basierte Routingkonfigurationen erstellt werden. Jede ExpressRoute-Verbindung kann eine oder beide der folgenden Peeringkonfigurationen haben:
- Privates Azure-Peering: Datenverkehr zu privaten virtuellen Netzwerken in Azure
- Microsoft-Peering: Datenverkehr zu öffentlichen Endpunkten von Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS)
Weitere Informationen dazu, wie Sie die Routingkonfiguration erstellen und ändern, finden Sie im Artikel Erstellen und Ändern des Routings für eine ExpressRoute-Verbindung.
Überprüfung über das Azure-Portal
Hinweis
Beim IPVPN-Konnektivitätsmodell übernehmen Dienstanbieter die Verantwortung für die Konfiguration der Peeringvorgänge (Layer-3-Dienste). Nachdem der Dienstanbieter das Peering konfiguriert hat und das Peering im Portal leer ist, sollten Sie bei einem solchen Modell versuchen, die Verbindungskonfiguration über die Schaltfläche „Aktualisieren“ im Portal zu aktualisieren. Durch diesen Vorgang wird von Ihrer Verbindung die aktuelle Routingkonfiguration abgerufen.
Im Azure-Portal können Sie den Status einer ExpressRoute-Verbindung auf der Seite für diese Verbindung überprüfen. Im Abschnitt der Seite werden die ExpressRoute-Peerings wie im folgenden Screenshot gezeigt aufgelistet:
Im vorherigen Beispiel wurde das private Azure-Peering bereitgestellt, öffentliche Azure-Peerings und Microsoft-Peerings wurden jedoch nicht bereitgestellt. Für einen erfolgreich bereitgestellten Peeringkontext wären auch die primären und sekundären Point-to-Point-Subnetze aufgelistet. Die /30-Subnetze werden für die Schnittstellen-IP-Adresse der MSEEs und CEs/PE-MSEEs verwendet. Für die bereitgestellten Peerings gibt die Liste auch an, wer die Konfiguration zuletzt geändert hat.
Hinweis
Wenn die Aktivierung eines Peerings fehlschlägt, sollten Sie überprüfen, ob die zugewiesenen primären und sekundären Subnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Überprüfen Sie auch, ob die Werte für VlanId, AzureASN und PeerASN auf den MSEEs richtig sind und ob diese Werte zu den Werten auf dem verknüpften CE/PE-MSEE passen.
Wenn MD5-Hashing gewählt wird, sollte der gemeinsam verwendete Schlüssel für MSEE- und CE/PE-MSEE-Paare gleich sein. Zuvor konfigurierte gemeinsam verwendete Schlüssel werden aus Sicherheitsgründen nicht angezeigt.
Wenn Sie die Konfiguration auf MSEE-Routern ändern müssen, helfen Ihnen die Informationen unter Erstellen und Ändern des Routings für eine ExpressRoute-Verbindung weiter.
Hinweis
Bei einem /30-Subnetz, das der Schnittstelle zugewiesen wird, wählt Microsoft die zweite verwendbare IP-Adresse des Subnetzes für die MSEE-Schnittstelle aus. Stellen Sie daher sicher, dass die erste verwendbare IP-Adresse des Subnetzes auf dem Peer-CE/PE-MSEE zugewiesen wurde.
Überprüfung per PowerShell
Verwenden Sie die folgenden Befehle, um die Konfigurationsdetails für das private Azure-Peering zu erhalten:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Eine Beispielantwort für ein erfolgreich konfiguriertes privates Peering lautet:
Name : AzurePrivatePeering
Id : /subscriptions/***************************/resourceGroups/Test-ER-RG/providers/***********/expressRouteCircuits/Test-ER-Ckt/peerings/AzurePrivatePeering
Etag : W/"################################"
PeeringType : AzurePrivatePeering
AzureASN : 12076
PeerASN : 123##
PrimaryPeerAddressPrefix : 172.16.0.0/30
SecondaryPeerAddressPrefix : 172.16.0.4/30
PrimaryAzurePort :
SecondaryAzurePort :
SharedKey :
VlanId : 200
MicrosoftPeeringConfig : null
ProvisioningState : Succeeded
Für einen erfolgreich aktivierten Peeringkontext wären die primären und sekundären Adresspräfixe aufgeführt. Die /30-Subnetze werden für die Schnittstellen-IP-Adresse der MSEEs und CEs/PE-MSEEs verwendet.
Verwenden Sie die folgenden Befehle, um die Konfigurationsdetails für das Microsoft-Peering zu erhalten:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Wenn ein Peering nicht konfiguriert ist, wird eine Fehlermeldung angezeigt. Eine Beispielantwort für den Fall, dass das angegebene Peering nicht in der Verbindung konfiguriert ist, lautet wie folgt:
Get-AzExpressRouteCircuitPeeringConfig : Sequence contains no matching element
At line:1 char:1
+ Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzExpr...itPeeringConfig], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteCircuitPeeringConfigCommand
Hinweis
Wenn die Aktivierung eines Peerings fehlschlägt, sollten Sie überprüfen, ob die zugewiesenen primären und sekundären Subnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Überprüfen Sie auch, ob die Werte für VlanId, AzureASN und PeerASN auf den MSEEs richtig sind und ob diese Werte zu den Werten auf dem verknüpften CE/PE-MSEE passen.
Wenn MD5-Hashing gewählt wird, sollte der gemeinsam verwendete Schlüssel für MSEE- und CE/PE-MSEE-Paare gleich sein. Zuvor konfigurierte gemeinsam verwendete Schlüssel werden aus Sicherheitsgründen nicht angezeigt.
Wenn Sie die Konfiguration auf MSEE-Routern ändern müssen, helfen Ihnen die Informationen unter Erstellen und Ändern des Routings für eine ExpressRoute-Verbindung weiter.
Hinweis
Bei einem/30-Subnetz, das der Schnittstelle zugewiesen wird, wählt Microsoft die zweite verwendbare IP-Adresse des Subnetzes für die MSEE-Schnittstelle aus. Stellen Sie daher sicher, dass die erste verwendbare IP-Adresse des Subnetzes auf dem Peer-CE/PE-MSEE zugewiesen wurde.
Überprüfen von ARP
Die Address Resolution Protocol (ARP)-Tabelle ermöglicht eine Zuordnung der IP-Adresse und MAC-Adresse für ein bestimmtes Peering. Die ARP-Tabelle für ein ExpressRoute-Verbindungspeering enthält die folgenden Informationen für jede (primäre und sekundäre) Schnittstelle:
- Zuordnung der IP-Adresse der lokalen Routerschnittstelle zur MAC-Adresse
- Zuordnung der IP-Adresse der ExpressRoute-Routerschnittstelle zur MAC-Adresse (optional)
- Alter der Zuordnung
ARP-Tabellen dienen zum Überprüfen der Layer-2-Konfiguration und Behandeln grundlegender Layer-2-Verbindungsprobleme.
Hinweis
Je nach Hardwareplattform können die ARP-Ergebnisse variieren und nur die lokale Schnittstelle anzeigen.
Informationen zum Anzeigen der ARP-Tabelle eines ExpressRoute-Peerings und Informationen zur Behandlung von Layer-2-Konnektivitätsproblemen finden Sie im Dokument Abrufen von ARP-Tabellen im Resource Manager-Bereitstellungsmodell.
Überprüfen von BGP und Routen auf dem MSEE
Verwenden Sie den folgenden Befehl, um die Routingtabelle vom MSEE unter dem primären Pfad für den privaten Routingkontext zu erhalten:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****
Hier sehen Sie eine Beispielantwort:
Network : 10.1.0.0/16
NextHop : 10.17.17.141
LocPrf :
Weight : 0
Path : 65515
Network : 10.1.0.0/16
NextHop : 10.17.17.140*
LocPrf :
Weight : 0
Path : 65515
Network : 10.2.20.0/25
NextHop : 172.16.0.1
LocPrf :
Weight : 0
Path : 123##
Hinweis
Wenn der Status eines eBGP-Peerings zwischen einem MSEE und einem CE/PE-MSEE Aktiv oder Im Leerlauf lautet, sollten Sie überprüfen, ob die zugewiesenen primären und sekundären Peersubnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Überprüfen Sie auch, ob die Werte für VlanId, AzureASN und PeerASN auf den MSEEs richtig sind und ob diese Werte zu den Werten auf dem verknüpften CE/PE-MSEE passen. Wenn MD5-Hashing gewählt wird, sollte der gemeinsam verwendete Schlüssel für MSEE- und CE/PE-MSEE-Paare gleich sein. Wenn Sie die Konfiguration auf MSEE-Routern ändern müssen, helfen Ihnen die Informationen unter Erstellen und Ändern des Routings für eine ExpressRoute-Verbindung weiter.
Hinweis
Falls bestimmte Ziele über ein Peering nicht erreichbar sind, sollten Sie die Routentabelle der MSEEs überprüfen, die zum jeweiligen Peeringkontext gehören. Wenn in der Routingtabelle ein übereinstimmendes Präfix (z. B. IP für Netzwerkadressenübersetzung) vorhanden ist, überprüfen Sie, ob Firewalls, Netzwerksicherheitsgruppen oder Zugriffssteuerungslisten (ACLs) auf dem Pfad den Datenverkehr blockieren.
Das folgende Beispiel zeigt die Reaktion auf den Befehl für den Fall, dass kein Peering vorhanden ist:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Bestätigen des Datenverkehrsflusses
Verwenden Sie den folgenden Befehl, um die Datenverkehrsstatistiken für den primären und sekundären Pfad – eingehende und ausgehende Byte – eines Peeringkontexts zu erhalten:
Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'
Dies ist ein Beispiel für die Befehlsausgabe:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Hier ist eine Beispielausgabe des Befehls für ein nicht vorhandenes Peering:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400
Testen der Konnektivität mit privatem Peering
Testen Sie die Konnektivität des privaten Peering, indem Sie auf MSEE-Geräten ein- und ausgehende Pakete am Microsoft-Edge der ExpressRoute-Verbindung zählen. Von diesem Diagnosetool wird eine Zugriffssteuerungsliste (Access Control List, ACL) auf die MSEE-Geräte angewendet, um die Anzahl der Pakete zu ermitteln, die bestimmte ACL-Regeln auslösen. Mit diesem Tool können Sie die Konnektivität überprüfen, indem Sie die folgenden Fragen beantworten:
- Werden meine Pakete an Azure gesendet?
- Werden sie zurück an die lokale Umgebung gesendet?
Ausführen eines Tests
Um auf dieses Diagnosetool zuzugreifen, wählen Sie im Azure-Portal für Ihre ExpressRoute-Verbindung die Option Probleme diagnostizieren und beheben aus.
Wählen Sie Konnektivität und Leistungsprobleme aus.
Wählen Sie in der Auswahlliste Erzählen Sie uns von dem aufgetretenen Problem. die Option Probleme mit dem privaten Peering aus.
Scrollen Sie nach unten zum Abschnitt Testen der Konnektivität mit privatem Peering, und erweitern Sie ihn.
Führen Sie den PsPing-Test von Ihrer lokalen IP-Adresse zu Ihrer Azure-IP-Adresse durch, und lassen Sie ihn während des Konnektivitätstests laufen.
Füllen Sie die Felder des Formulars aus. Achten Sie darauf, die gleichen lokalen und Azure-IP-Adressen einzugeben, die Sie in Schritt 5 verwendet haben. Wählen Sie dann Übermitteln aus, und warten Sie, bis die Ergebnisse geladen wurden.
Interpretieren von Ergebnissen
Wenn Ihre Ergebnisse bereit sind, verfügen Sie über zwei Sätze für die primären und sekundären MSEE-Geräte. Überprüfen Sie die Anzahl der Übereinstimmungen (eingehend und ausgehend), und interpretieren Sie die Ergebnisse anhand der folgenden Szenarien:
Sie sehen anhand der Ergebnisse, dass auf beiden MSEE-Geräten sowohl Pakete gesendet als auch empfangen werden: Dies weist auf fehlerfreien ein- und ausgehenden Datenverkehr auf den MSEEs für Ihre Verbindung hin. Sollten Pakete in der lokalen Umgebung oder in Azure verloren gehen, tritt dieser Verlust erst nach den MSEEs auf.
Wenn Sie PsPing von der lokalen IP-Adresse zur Azure-IP-Adresse testen, zeigen empfangene Ergebnisse Übereinstimmungen, aber gesendete Ergebnisse zeigen keine Übereinstimmungen: Dies weist darauf hin, dass Datenverkehr bei Azure eingeht, aber nicht zurück an die lokale Umgebung gesendet wird. Überprüfen Sie, ob Routingprobleme mit Rückgabepfaden auftreten. Beispiel: Kündigen Sie die richtigen Präfixe für Azure an? Überschreibt eine benutzerdefinierte Route (UDR) Präfixe?
Wenn Sie PsPing von der lokalen IP-Adresse zur Azure-IP-Adresse testen, zeigen gesendete Ergebnisse Übereinstimmungen, aber empfangene Ergebnisse zeigen keine Übereinstimmungen: Dieses Ergebnis weist darauf hin, dass Datenverkehr bei der lokale Umgebung eingeht, aber nicht zurück an Azure gesendet wird. Ermitteln Sie zusammen mit Ihrem Anbieter, warum Datenverkehr nicht über Ihre ExpressRoute-Verbindung an Azure geroutet wird.
Ein MSEE-Gerät zeigt keine Übereinstimmungen, das andere jedoch schon: Dies weist darauf hin, dass ein MSEE-Gerät keinen Datenverkehr sendet oder empfängt. Möglicherweise ist es offline (z. B. bei Ausfall von BGP/ARP).
- Sie können zusätzliche Tests ausführen, um den fehlerhaften Pfad zu bestätigen, indem Sie eine eindeutige lokale /32-Route über die BGP-Sitzung auf diesem Pfad ankündigen.
- Führen Sie „Testen der privaten Peeringkonnektivität“ mithilfe der eindeutigen /32 aus, die als lokale Zieladresse angekündigt wird, und überprüfen Sie die Ergebnisse, um die Integrität des Pfads zu bestätigen.
Ihre Testergebnisse für die einzelnen MSEE-Geräte sehen wie im folgenden Beispiel aus:
src 10.0.0.0 dst 20.0.0.0 dstport 3389 (received): 120 matches
src 20.0.0.0 srcport 3389 dst 10.0.0.0 (sent): 120 matches
Dieses Testergebnis hat die folgenden Eigenschaften:
- IP-Port: 3389
- Lokales IP-Adress-CIDR: 10.0.0.0
- CIDR für Azure-IP-Adresse: 20.0.0.0
Überprüfen der Verfügbarkeit des Gateways für virtuelle Netzwerke
Das virtuelle ExpressRoute-Netzwerkgateway vereinfacht Verwaltung und Konnektivität der Steuerschicht mit Diensten für private Verknüpfungen und private IPs, die in einem virtuellen Azure-Netzwerk bereitgestellt werden. Microsoft verwaltet die Infrastruktur des virtuellen Netzwerkgateways, die manchmal Wartungsarbeiten unterzogen wird.
Während eines Wartungszeitraums kann sich die Leistung des virtuellen Netzwerkgateways verringern. Gehen Sie wie folgt vor, um Konnektivitätsprobleme mit dem virtuellen Netzwerk zu beheben und zu erkennen, ob ein kürzlich aufgetretenes Wartungsereignis zu einer Kapazitätsreduzierung geführt hat:
Wählen Sie im Azure-Portal die Option Diagnose und Problemlösung für Ihre ExpressRoute-Verbindung.
Wählen Sie die Option Leistungsprobleme aus.
Warten Sie, bis die Diagnose ausgeführt wurde, und interpretieren Sie die Ergebnisse.
Wenn die Wartung Ihres virtuellen Netzwerkgateways während eines Zeitraums durchgeführt wurde, in dem Paketverluste oder Wartezeiten aufgetreten sind. Es ist möglich, dass die verringerte Kapazität des Gateways zu Konnektivitätsproblemen mit dem virtuellen Zielnetzwerk beigetragen hat. Führen Sie die folgenden empfohlenen Schritte aus. Zur Unterstützung eines höheren Netzwerkdurchsatzes und zur Vermeidung von Konnektivitätsproblemen während künftiger Wartungsereignisse sollten Sie ein Upgrade des SKU des Gateways für virtuelle Netzwerke in Betracht ziehen.
Nächste Schritte
Weitere Informationen oder Hilfe finden Sie unter den folgenden Links: