Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Zusammenfassung
Dieser Artikel hilft Ihnen, Azure ExpressRoute Konnektivität zu überprüfen und zu beheben. ExpressRoute erweitert ein lokales Netzwerk in die Microsoft Cloud über eine private Verbindung, die von einem Konnektivitätsanbieter erleichtert wird. ExpressRoute-Konnektivität umfasst drei verschiedene Netzwerkzonen:
- Kundennetzwerk
- Anbieternetzwerk
- Microsoft-Rechenzentrum
Hinweis
Im ExpressRoute Direct Connectivity-Modell können Sie direkt eine Verbindung mit dem Port für Microsoft Enterprise Edge (MSEE)-Router herstellen. Dieses Modell umfasst nur Ihr Netzwerk und die Microsoft-Netzwerkzonen.
Dieser Artikel hilft Ihnen, Konnektivitätsprobleme zu identifizieren und Unterstützung vom entsprechenden Team zu suchen, um sie zu beheben.
Von Bedeutung
Dieser Artikel hilft Ihnen bei der Diagnose und Behebung einfacher Probleme. Es ist kein Ersatz für den Microsoft-Support. Wenn Sie ein Problem nicht mithilfe dieser Anleitung lösen können, öffnen Sie ein Supportticket mit Microsoft-Support.
Überblick
Das folgende Diagramm zeigt die logische Konnektivität eines Kundennetzwerks mit dem Microsoft-Netzwerk über ExpressRoute.
Im Diagramm geben die Zahlen wichtige Netzwerkpunkte an:
- Computergerät des Kunden (z. B. server oder PC).
- Kunden-Randrouter (CEs).
- Provider-Edge-Router/-Switches (PEs), die den Kunden-Edge-Routern gegenüberstehen.
- PEs gegenüber Microsoft Enterprise Edge ExpressRoute-Routern (MSEEs), bezeichnet als PE-MSEEs.
- MSEEs.
- Virtuelles Netzwerkgateway.
- Ein Rechengerät im Azure-Virtuellen Netzwerk.
In diesem Artikel werden diese Netzwerkpunkte anhand ihrer zugeordneten Nummer referenziert.
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 Konnektivitätsmodelle sind Cloud-Exchange-Colocation, Punkt-zu-Punkt-Ethernet-Verbindung oder any-to-any (IPVPN).
Im Modell für direkte Konnektivität enthält die Architektur keine Netzwerkpunkte 3 und 4. Stattdessen sind CEs (2) über Dark Fiber direkt mit MSEEs verbunden.
Wenn Sie das Cloud-Exchange-Colocation-, das Point-to-Point-Ethernet- oder das Direktverbindungsmodell verwenden, bauen CEs (2) ein Border-Gateway-Protocol-(BGP-)Peering mit MSEEs (5) auf.
Wenn Sie das Any-to-Any-(IPVPN)-Konnektivitätsmodell verwenden, bauen PE-MSEEs (4) ein BGP-Peering mit MSEEs (5) auf. PE-MSEEs geben die von Microsoft erhaltenen Routen über das Netzwerk des IPVPN-Dienstanbieters an das Kundennetzwerk zurück weiter.
Hinweis
Für hohe Verfügbarkeit stellt Microsoft vollständig redundante parallele Konnektivität zwischen MSEE- und PE-MSEE-Paaren her. Sie sollten auch einen vollständig redundanten parallelen Netzwerkpfad zwischen dem Kundennetzwerk und PE/CE-Paaren erstellen. Weitere Informationen zur hohen Verfügbarkeit finden Sie unter Design für hohe Verfügbarkeit mit ExpressRoute.
Die folgenden Abschnitte stellen die logischen Schritte bei der Problembehandlung eines ExpressRoute-Schaltkreises dar.
Überprüfen der Schaltkreisbereitstellung und des Zustands
Die Bereitstellung eines ExpressRoute-Schaltkreises stellt eine redundante Layer 2-Verbindung zwischen CEs/PE-MSEEs (2/4) und MSEEs (5) her. Weitere Informationen zum Erstellen, Ändern, Bereitstellen und Überprüfen eines ExpressRoute-Schaltkreises finden Sie unter Erstellen und Ändern eines ExpressRoute-Schaltkreises.
Tipp
Mit einem Dienstschlüssel wird eine ExpressRoute-Verbindung eindeutig identifiziert. Wenn Sie Unterstützung von Microsoft oder einem ExpressRoute-Partner benötigen, um ein Problem zu beheben, stellen Sie den Dienstschlüssel bereit, um den Schaltkreis leicht zu identifizieren.
Überprüfung über das Azure-Portal
Wechseln Sie im Azure-Portal zur Seite für Ihren ExpressRoute-Schaltkreis. Der 
Abschnitt der Seite enthält die ExpressRoute Essentials, wie im folgenden Screenshot dargestellt:
In den ExpressRoute Essentials zeigt Circuit-Status den Status des Schaltkreises auf der Microsoft-Seite und Provider-Status an, ob der Dienstanbieter den Schaltkreis bereitgestellt hat.
Damit eine ExpressRoute-Verbindung betriebsbereit ist, muss Schaltkreisstatus auf Aktiviert und Anbieterstatus auf Bereitgestellt festgelegt sein.
Hinweis
Wenn Circuitstatus in Not enabled hängen bleibt, wenden Sie sich an Microsoft-Support. Wenn der Anbieterstatus in "Nicht bereitgestellt" hängen bleibt, wenden Sie sich an Ihren Dienstanbieter.
Überprüfung über PowerShell
Um alle ExpressRoute-Schaltkreise in einer Ressourcengruppe auflisten zu können, verwenden Sie den folgenden Befehl:
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Tipp
Um den Namen einer Ressourcengruppe zu finden, verwenden Sie den Get-AzResourceGroup Befehl, um alle Ressourcengruppen in Ihrem Abonnement auflisten zu können.
Um Details zu einem bestimmten ExpressRoute-Schaltkreis in einer Ressourcengruppe abzurufen, verwenden Sie den folgenden Befehl:
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 : []
Um zu bestätigen, dass ein ExpressRoute-Schaltkreis betriebsbereit ist, stellen Sie sicher, dass die folgenden Felder ordnungsgemäß festgelegt sind:
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Hinweis
Wenn Circuitstatus in Not enabled hängen bleibt, wenden Sie sich an Microsoft-Support. Wenn der Anbieterstatus in "Nicht bereitgestellt" hängen bleibt, wenden Sie sich an Ihren Dienstanbieter.
Überprüfen Sie die Peeringkonfiguration
Nachdem der Dienstanbieter den ExpressRoute-Schaltkreis bereitgestellt hat, können Sie mehrere Routingkonfigurationen erstellen, die externe BGP (eBGP) über den Schaltkreis zwischen CEs/MSEE-PEs (2/4) und MSEEs (5) verwenden. Jeder ExpressRoute-Schaltkreis kann eine oder beide der folgenden Peeringkonfigurationen aufweisen:
- Azure private Peering: für Datenverkehr zu privaten virtuellen Netzwerken in Azure
- Microsoft-Peering: für Datenverkehr zu öffentlichen Endpunkten von Plattformdiensten als Dienst (PaaS) und Software als Dienst (SaaS)
Weitere Informationen zum Erstellen und Ändern von Routingkonfigurationen finden Sie unter Erstellen und Ändern des Routings für einen ExpressRoute-Schaltkreis.
Überprüfung über das Azure-Portal
Hinweis
In einem IPVPN-Konnektivitätsmodell übernehmen Dienstanbieter die Verantwortung für die Konfiguration der Peerings (Layer 3-Dienste). Wenn das Peering im Portal leer ist, nachdem der Dienstanbieter ihn konfiguriert hat, versuchen Sie, die Schaltkreiskonfiguration mithilfe der Schaltfläche "Aktualisieren" im Portal zu aktualisieren. Mit diesem Vorgang wird die aktuelle Routingkonfiguration von Ihrem Schaltkreis abgerufen.
Im Azure-Portal können Sie den Status eines ExpressRoute-Schaltkreises auf seiner Seite überprüfen. Im Abschnitt werden die ExpressRoute-Peerings aufgelistet, wie im folgenden Screenshot dargestellt:
Im vorangegangenen Beispiel ist Azure Private Peering bereitgestellt, Azure Public- und Microsoft-Peerings sind jedoch nicht eingerichtet. Ein erfolgreich bereitgestellter Peeringkontext listet auch die primären und sekundären Punkt-zu-Punkt-Subnetze auf. Die /30-Subnetze werden für die Schnittstellen-IP-Adressen der MSEEs und CEs/PE-MSEEs verwendet. Die Auflistung gibt auch an, wer die Konfiguration zuletzt geändert hat.
Hinweis
Wenn beim Aktivieren eines Peerings ein Fehler auftritt, überprüfen Sie, ob die zugewiesenen primären und sekundären Subnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Überprüfen Sie außerdem, ob die Werte VlanId, AzureASN und PeerASN auf den MSEEs mit denen des verknüpften CE/PE-MSEE übereinstimmen.
Wenn Sie MD5-Hashing auswählen, stellen Sie sicher, dass der freigegebene Schlüssel für MSEE- und CE/PE-MSEE-Paare identisch ist. Aus Sicherheitsgründen werden bereits konfigurierte gemeinsam verwendete Schlüssel nicht angezeigt.
Informationen zum Ändern dieser Konfigurationen auf einem MSEE-Router finden Sie unter Erstellen und Ändern des Routings für einen ExpressRoute-Schaltkreis.
Hinweis
Bei einem /30-Subnetz, das der Schnittstelle zugewiesen ist, verwendet Microsoft die zweite verwendbare IP-Adresse für die MSEE-Schnittstelle. Stellen Sie sicher, dass Sie der gepaarten CE/PE-MSEE die erste nutzbare IP-Adresse zuweisen.
Überprüfung über PowerShell
Verwenden Sie die folgenden Befehle, um die Konfigurationsdetails für Azure privaten Peering abzurufen:
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Hier ist eine Beispielantwort für eine erfolgreich konfigurierte private Peering:
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
Ein erfolgreich aktivierter Peeringkontext listet die Präfixe der primären und sekundären Adresse auf. Die /30-Subnetze werden für die Schnittstellen-IP-Adressen der MSEEs und CEs/PE-MSEEs verwendet.
Verwenden Sie die folgenden Befehle, um die Konfigurationsdetails für Microsoft-Peering abzurufen:
$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. Hier ist eine Beispielantwort, wenn der angegebene Peering nicht innerhalb des Schaltkreises konfiguriert ist:
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 beim Aktivieren eines Peerings ein Fehler auftritt, überprüfen Sie, ob die zugewiesenen primären und sekundären Subnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Überprüfen Sie außerdem, ob die Werte VlanId, AzureASN und PeerASN auf den MSEEs mit denen des verknüpften CE/PE-MSEE übereinstimmen.
Wenn Sie MD5-Hashing auswählen, stellen Sie sicher, dass der freigegebene Schlüssel für MSEE- und CE/PE-MSEE-Paare identisch ist. Aus Sicherheitsgründen werden zuvor konfigurierte gemeinsam genutzte Schlüssel nicht angezeigt.
Informationen zum Ändern dieser Konfigurationen auf einem MSEE-Router finden Sie unter Erstellen und Ändern des Routings für einen ExpressRoute-Schaltkreis.
Hinweis
Bei einem /30-Subnetz, das der Schnittstelle zugewiesen ist, verwendet Microsoft die zweite verwendbare IP-Adresse für die MSEE-Schnittstelle. Stellen Sie sicher, dass Sie dem gekoppelten CE/PE-MSEE die erste verwendbare IP-Adresse zuweisen.
Ü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 Kartierung
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 zur Verwendung der Informationen zur Behandlung von Problemen mit Layer 2-Konnektivität finden Sie unter Getting ARP-Tabellen im Resource Manager Bereitstellungsmodell.
Validieren von BGP und Routen auf dem MSEE
Verwenden Sie den folgenden Befehl, um die Routingtabelle aus dem MSEE im primären Pfad für den privaten Routingkontext abzurufen:
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
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 eBGP-Peeringstatus zwischen einem MSEE und einem CE/PE-MSEE "Aktiv " oder "Idle" lautet, überprüfen Sie, ob die primären und sekundären Peersubnetze mit der Konfiguration auf dem verknüpften CE/PE-MSEE übereinstimmen. Stellen Sie sicher, dass die Werte VlanId, AzureASN und PeerASN auf den MSEEs korrekt sind und mit den Werten auf dem verknüpften CE/PE-MSEE übereinstimmen. Wenn Sie MD5-Hashing verwenden, muss der freigegebene Schlüssel für MSEE- und CE/PE-MSEE-Paare identisch sein. Konfigurationsänderungen auf einem MSEE-Router finden Sie unter Erstellen und Ändern des Routings für einen ExpressRoute-Schaltkreis.
Hinweis
Wenn bestimmte Ziele über einen Peering nicht erreichbar sind, überprüfen Sie die MSEE-Routentabelle auf den entsprechenden Peeringkontext. Wenn ein übereinstimmende Präfix vorhanden ist, stellen Sie sicher, dass keine Firewalls, Netzwerksicherheitsgruppen oder ACLs den Datenverkehr blockieren.
Beispielantwort für ein nicht vorhandenes Peering:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Bestätigen Sie den Verkehrsfluss
Verwenden Sie den folgenden Befehl, um Datenverkehrsstatistiken (Bytes in und aus) für einen Peeringkontext abzurufen:
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Beispielausgabe:
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Beispielausgabe für ein nicht vorhandenes Peering:
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Testen Sie die private Peering-Konnektivität
Testen Sie die private Peering-Konnektivität, indem Sie Pakete zählen, die an dem Microsoft-Edge Ihres ExpressRoute-Schaltkreises auf den MSEE-Geräten ankommen und den Microsoft-Edge verlassen. Dieses Diagnosetool verwendet eine ACL, um Pakete zu zählen, die bestimmte Regeln treffen und die Konnektivität bestätigen.
Test ausführen
Wählen Sie im Azure-Portal Diagnose aus, und lösen Sie Probleme aus Ihrem ExpressRoute-Schaltkreis.
Wählen Sie Konnektivitäts- und Leistungsprobleme aus.
Wählen Sie im Dropdownmenü "Informieren Sie uns mehr über das Problem, das Sie haben " die Option "Probleme mit privatem Peering" aus.
Erweitern Sie den Abschnitt "Private-Peering-Konnektivität testen ".
Führen Sie den PsPing-Test von Ihrer lokalen IP zu Ihrer Azure-IP durch und lassen Sie ihn während des Tests weiterlaufen.
Füllen Sie die Formularfelder mit den gleichen IP-Adressen aus, die in Schritt 5 verwendet werden, und wählen Sie dann "Absenden" aus, und warten Sie auf die Ergebnisse.
Interpretieren von Ergebnissen
Überprüfen Sie die Ergebnisse für die primären und sekundären MSEE-Geräte:
Übereinstimmungen, die auf beiden MSEEs gesendet und empfangen werden: Zeigt einen ordnungsgemäßen eingehenden und ausgehenden Datenverkehr an. Alle Verluste treten stromabwärts von den MSEEs auf.
Received matches but no sent matches: Datenverkehr erreicht Azure, kehrt jedoch nicht zurück. Überprüfen Sie Routingprobleme beim Rückgabepfad.
Sent-Übereinstimmungen, aber keine empfangenen Übereinstimmungen: Der Datenverkehr erreicht lokal, kehrt aber nicht zu Azure zurück. Arbeiten Sie mit Ihrem Anbieter zusammen, um das Problem zu lösen.
Ein MSEE zeigt keine Übereinstimmungen an, die andere zeigt gute Übereinstimmungen: Gibt an, dass ein MSEE keinen Datenverkehr empfängt oder übergibt. Möglicherweise ist sie offline.
Wenn Sie PsPing von lokal auf Azure testen, zeigen empfangene Ergebnisse Übereinstimmungen an, gesendete Ergebnisse zeigen jedoch keine Übereinstimmungen an: Dieses Ergebnis gibt an, dass der Datenverkehr zu Azure kommt, aber nicht zur lokalen Bereitstellung zurückkehrt. Überprüfen Sie auf Return-Path-Routing-Probleme. Werben Sie beispielsweise die entsprechenden Präfixe für Azure? Überschreibt eine benutzerdefinierte Route (UDR) Präfixe?
Wenn Sie PsPing von Azure auf lokale Systeme testen, zeigen gesendete Ergebnisse Übereinstimmungen, aber empfangene Ergebnisse zeigen keine Übereinstimmungen: Dieses Ergebnis gibt an, dass Datenverkehr in die lokale Umgebung kommt, aber nicht zu Azure zurückkehrt. Arbeiten Sie mit Ihrem Anbieter zusammen, um herauszufinden, warum datenverkehr nicht über Ihren ExpressRoute-Schaltkreis an Azure weitergeleitet wird.
Ein MSEE zeigt keine Übereinstimmungen an, aber die andere zeigt gute Übereinstimmungen: Dieses Ergebnis gibt an, dass ein MSEE keinen Datenverkehr empfängt oder übergibt. Es kann offline sein (z. BGP/ARP ist ausgefallen).
- 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 anzeigen.
- Führen Sie "Testen Sie Ihre private Peering-Konnektivität" mithilfe der eindeutigen /32 aus, die als lokale Zieladresse angekündigt wurde, und überprüfen Sie die Ergebnisse, um den Pfadstatus zu bestätigen.
Die Testergebnisse für jedes MSEE-Gerät 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
Überprüfen der Verfügbarkeit des virtuellen Netzwerkgateways
Das virtuelle ExpressRoute-Netzwerkgateway verwaltet die Konnektivität mit privaten Linkdiensten und privaten IPs in einem Azure virtuellen Netzwerk. Microsoft verwaltet diese Infrastruktur und kann Wartungsvorgänge durchführen, wodurch die Leistung reduziert werden kann.
So beheben Sie Verbindungsprobleme und prüfen auf kürzlich durchgeführte Wartungsarbeiten:
Wählen Sie im Azure-Portal Diagnose aus, und lösen Sie Probleme aus Ihrem ExpressRoute-Schaltkreis.
Wählen Sie Leistungsprobleme aus.
Warten Sie, bis die Diagnose ausgeführt wird, und interpretieren Sie die Ergebnisse.
Wenn während Wartungsarbeiten Paketverlust oder eine hohe Latenz auftreten, kann dies zu Verbindungsproblemen beitragen. Führen Sie die empfohlenen Schritte aus, und führen Sie ein Upgrade der SKU für virtuelle Netzwerke durch, um einen höheren Durchsatz zu unterstützen und zukünftige Probleme zu vermeiden.
Nächste Schritte
Weitere Informationen oder Hilfe finden Sie unter den folgenden Links: