Vérifier la connectivité ExpressRoute
Cet article vous permet de vérifier et de résoudre les problèmes de connectivité Azure ExpressRoute. ExpressRoute étend un réseau local à Microsoft Cloud via une connexion privée facilitée par un fournisseur de connectivité. La connectivité ExpressRoute implique trois zones de réseau distinctes :
- Réseau client
- Réseau de fournisseur
- Centre de données Microsoft
Notes
Dans le modèle de connectivité ExpressRoute Direct, vous pouvez vous connecter directement au port des routeurs Microsoft Enterprise Edge (MSEE). Ce modèle inclut uniquement votre réseau et les zones de réseau Microsoft.
Cet article vous aide à identifier les problèmes de connectivité et à chercher de l’aide auprès de l’équipe appropriée pour les résoudre.
Important
Cet article a pour objet de vous aider à diagnostiquer et résoudre les problèmes simples. Il ne s’agit pas d’une substitution au support de Microsoft. Si vous ne pouvez pas résoudre un problème en utilisant cette aide, ouvrez un ticket de support avec Support Microsoft.
Vue d’ensemble
Le diagramme suivant illustre la connectivité logique d’un réseau de client vers un réseau Microsoft via ExpressRoute.
Dans le diagramme, les nombres indiquent les points clés de réseau :
- appareil de calcul du client (par exemple, un serveur ou un PC)
- routeurs de périphérie du client (CE)
- Des routeurs/commutateurs en périphérie (PE) du fournisseur accessibles aux routeurs en périphérie du client.
- Des PE accessibles aux routeurs ExpressRoute de Microsoft Enterprise Edge (MSEEs) appelés PE-MSEE.
- MSEE.
- Passerelle de réseau virtuel.
- Appareil de calcul sur le réseau virtuel Azure.
Ces points de réseau sont référencés dans cet article par le numéro qui leur est associé.
En fonction du modèle de connectivité ExpressRoute, les points réseau 3 et 4 peuvent être de commutateurs (appareils de couche 2) ou des routeurs (appareils de couche 3). Les modèles de connectivité sont la colocation d’échange de cloud, la connexion Ethernet point à point ou Any-to-Any (IPVPN).
Dans le modèle de connectivité directe, il n’existe pas de points réseau 3 et 4. Au lieu de cela, les CE (2) sont directement connectés aux MSEE via une fibre foncée.
Si le modèle de connectivité de colocation d’échange de cloud, Ethernet point à point ou de connectivité directe est utilisé, les CE (2) établissent le Peering BGP (Border Gateway Protocol) avec des MSEE (5).
Si le modèle de connectivité Any-to-any (IPVPN) est utilisé, les PE-MSEE (4) établissent un Peering BGP avec des MSEE (5). Les PE-MSEE propagent les itinéraires reçus de Microsoft vers le réseau du client par le biais du réseau de fournisseur de services IPVPN.
Remarque
Pour la haute disponibilité, Microsoft établit une connectivité parallèle entièrement redondante entre les paires MSEE et PE-MSEE. Un chemin d’accès réseau parallèle entièrement redondant est également recommandé entre le réseau du client et les paires PE-CE. Pour découvrir plus d’informations sur la haute disponibilité, consultez Conception pour la haute disponibilité avec ExpressRoute.
Les étapes suivantes représentent les étapes logiques dans le cadre de la résolution des problèmes d’un circuit ExpressRoute.
Vérification de l’approvisionnement et de l’état du circuit
L’approvisionnement d’un circuit ExpressRoute établit une connexion de couche 2 redondante entre les CE/PE-MSEE (2/4) et les MSEE (5). Pour découvrir plus d’informations sur la façon de créer, modifier, approvisionner et vérifier un circuit ExpressRoute, consultez Création et modification d’un circuit ExpressRoute.
Conseil
Une clé de service identifie un circuit ExpressRoute de façon unique. Si vous avez besoin de l’assistance de Microsoft ou d’un partenaire ExpressRoute pour résoudre un problème, entrez la clé de service afin d’identifier facilement le circuit.
Vérification par le biais du portail Azure
Dans le Portail Azure, naviguez jusqu’à votre circuit ExpressRoute. La section 
de la page répertorie les éléments principaux d’ExpressRoute, tels qu’ils apparaissent dans la capture d’écran suivante :
Dans les éléments principaux d’ExpressRoute, l’État du circuit indique l’état du circuit côté Microsoft. L’État du fournisseur indique si le circuit a été approvisionné par le fournisseur de services.
Pour qu'un circuit ExpressRoute soit opérationnel, État du circuit doit être Activé et État du fournisseur doit être Approvisionné.
Remarque
Si l’État du circuit est bloqué dans l’état Non activé, contactez le Support Microsoft. Si l’État du fournisseur est bloqué dans l’état Non approvisionné, contactez votre fournisseur de services.
Vérification par le biais de PowerShell
Pour répertorier tous les circuits ExpressRoute d’un groupe de ressources, utilisez la commande suivante :
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"
Conseil
Si vous souhaitez rechercher le nom d’un groupe de ressources, utilisez la commande Get-AzResourceGroup pour répertorier tous les groupes de ressources dans votre abonnement.
Pour obtenir des détails sur un circuit ExpressRoute spécifique dans un groupe de ressources, utilisez la commande suivante :
Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Voici un exemple de réponse :
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 : []
Pour vérifier si un circuit ExpressRoute est opérationnel, veillez à ce que les champs suivants soient correctement définis :
CircuitProvisioningState : Enabled
ServiceProviderProvisioningState : Provisioned
Remarque
Si l’État du circuit est bloqué dans l’état Non activé, contactez le Support Microsoft. Si l’État du fournisseur est bloqué dans l’état Non approvisionné, contactez votre fournisseur de services.
Valider la configuration du peering
Une fois que le fournisseur de services a approvisionné le circuit ExpressRoute, vous pouvez créer plusieurs configuration de routage en utilisant un BGP externe (eBGP) sur le circuit ExpressRoute entre des CE/MSEE-PR (2/4) et des MSEE (5). Chaque circuit ExpressRoute peut présenter l’une des configurations de Peering suivantes ou les deux :
- Peering privé Azure : pour le trafic vers des réseaux virtuels privés dans Azure
- Peering Microsoft : pour le trafic vers des points de terminaison publics de platform as a service (PaaS) et software as a service (SaaS)
Pour découvrir plus d’informations sur la création et la modification des configurations de routage, consultez Créer et modifier le routage pour un circuit ExpressRoute.
Vérification par le biais du portail Azure
Notes
Dans le modèle de connectivité IPVPN, les fournisseurs de services gèrent la responsabilité de la configuration des Peerings (services de couche 3). Si le Peering est vide dans le portail une fois configuré par le fournisseur de services, essayez d’actualiser la configuration du circuit en utilisant le bouton Actualiser sur le portail. Cette opération extraira la configuration de routage actuelle de votre circuit.
Dans le Portail Azure, vous pouvez vérifier l’état d’un circuit ExpressRoute sur sa page. La section répertorie les Peerings d’ExpressRoute, tels qu’ils apparaissent dans la capture d’écran suivante :
Dans l’exemple précédent, le Peering privé Azure est approvisionné, mais les Peerings Microsoft et publics Azure ne le sont pas. Un contexte de Peering correctement approvisionné répertorie également les sous-réseaux point à point principaux et secondaires. Les sous-réseaux /30 sont utilisés pour les adresses IP d’interface des MSEE et CE/PE-MSEE. La liste indique également qui a modifié la configuration.
Remarque
Si l’activation d’un Peering échoue, vérifiez que les sous-réseaux principaux et secondaires attribués correspondent à la configuration sur le CE/PE-MSEE lié. Vérifiez également que les valeurs VlanId, AzureASN et PeerASN sur les MSEE correspondent à celles sur le CE/PE-MSEE lié.
Si le code de hachage MD5 est choisi, vérifiez que la clé partagée est la même sur les paires MSEE et CE/PE-MSEE. Les clés partagées précédemment configurées ne s’affichent pas pour des raisons de sécurité.
Si vous devez modifier l’une de ces configurations sur un routeur MSEE, consultez Créer et modifier le routage pour un circuit ExpressRoute.
Remarque
Sur un sous-réseau /30 attribué à l’interface, Microsoft utilise la deuxième adresse IP utilisable pour l’interface MSEE. Veillez à ce que la première adresse IP utilisable soit attribuée au CE/PE-MSEE appairé.
Vérification par le biais de PowerShell
Pour obtenir les détails sur la configuration du Peering privé Azure, utilisez les commandes suivantes :
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "AzurePrivatePeering" -ExpressRouteCircuit $ckt
Voici un exemple de réponse pour un Peering privé correctement configuré :
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
Un contexte de Peering correctement activé répertorie les préfixes d’adresses principales et secondaires. Les sous-réseaux /30 sont utilisés pour les adresses IP d’interface des MSEE et CE/PE-MSEE.
Pour obtenir les détails sur la configuration du Peering Microsoft, utilisez les commandes suivantes :
$ckt = Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG" -Name "Test-ER-Ckt"
Get-AzExpressRouteCircuitPeeringConfig -Name "MicrosoftPeering" -ExpressRouteCircuit $ckt
Si aucun Peering n’est configuré, un message d’erreur s’affiche. Voici un exemple de réponse quand le Peering déclaré n’est pas configuré dans le circuit :
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
Remarque
Si l’activation d’un Peering échoue, vérifiez que les sous-réseaux principaux et secondaires attribués correspondent à la configuration sur le CE/PE-MSEE lié. Vérifiez également que les valeurs VlanId, AzureASN et PeerASN sur les MSEE correspondent à celles sur le CE/PE-MSEE lié.
Si le code de hachage MD5 est choisi, vérifiez que la clé partagée est la même sur les paires MSEE et CE/PE-MSEE. Les clés partagées précédemment configurées ne s’affichent pas pour des raisons de sécurité.
Si vous devez modifier l’une de ces configurations sur un routeur MSEE, consultez Créer et modifier le routage pour un circuit ExpressRoute.
Remarque
Sur un sous-réseau /30 attribué à l’interface, Microsoft utilise la deuxième adresse IP utilisable pour l’interface MSEE. Veillez à ce que la première adresse IP utilisable soit attribuée au CE/PE-MSEE appairé.
Validation d’ARP
La table ARP (Address Resolution Protocol) fournit un mappage de l’adresse IP et de l’adresse MAC d’un Peering en particulier. La table ARP d’un peering de circuit ExpressRoute fournit les informations suivantes pour chaque interface (principale et secondaire) :
- Mappage de l’adresse IP de l’interface du routeur local sur l’adresse MAC
- Mappage de l’adresse IP de l’interface du routeur ExpressRoute sur l’adresse MAC (facultatif)
- Âge du mappage
Les tables ARP permettent de valider la configuration de la couche 2 et de résoudre les problèmes de connectivité de base de la couche 2.
Remarque
Selon la plateforme matérielle, les résultats ARP peuvent varier et n’afficher que l’interface locale.
Pour plus d’informations sur l’affichage de la table ARP d’un Peering ExpressRoute et sur l’utilisation des informations pour résoudre les problèmes de connectivité de la couche 2, consultez Obtention de tables ARP dans le modèle de déploiement Resource Manager.
Validation de BGP et des itinéraires sur les MSEE
Pour récupérer la table de routage à partir du MSEE sur le chemin d’accès principal pour le contexte de routage privé, utilisez la commande suivante :
Get-AzExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName <CircuitName> -PeeringType AzurePrivatePeering -ResourceGroupName <ResourceGroupName>
Exemple de réponse :
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##
Remarque
Si l’état d’un Peering eBGP entre un MSEE et un CE/PE-MSEE est Actif ou Inactif, vérifiez que les sous-réseaux d’homologues primaires et secondaires correspondent à la configuration sur le CE/PE-MSEE lié. Vérifiez que les valeurs VlanId, AzureASN et PeerASN sont correctes sur les MSEE et correspondent à celles sur le CE/PE-MSEE lié. Si le code de hachage MD5 est utilisé, la clé partagée doit être la même sur les paires MSEE et CE/PE-MSEE. Pour les modifications apportées à la configuration sur un routeur MSEE, consultez Créer et modifier le routage pour un circuit ExpressRoute.
Remarque
Si certaines destinations ne sont pas accessibles sur un Peering, vérifiez la table de routage du MSEE pour obtenir le contexte de Peering correspondant. Si un préfixe correspondant est présent, veillez à ce qu’aucun pare-feu, groupe de sécurité réseau ou liste de contrôle d’accès (ACL) ne bloque le trafic.
Exemple de réponse pour un Peering inexistant :
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Confirmation du flux de trafic
Pour obtenir les statistiques (octets en entrée et en sortie) d’un contexte de Peering, utilisez la commande suivante :
Get-AzExpressRouteCircuitStats -ResourceGroupName <ResourceGroupName> -ExpressRouteCircuitName <CircuitName> -PeeringType 'AzurePrivatePeering'
Exemple de sortie :
PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
240780020 239863857 240565035 239628474
Exemple de sorite pour un Peering inexistant :
Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key <ServiceKey> is not found.
StatusCode: 400
Tester la connectivité de peering privé
Testez la connectivité de Peering privé en comptant les paquets arrivant et quittant la périphérie de Microsoft de votre circuit ExpressRoute sur les appareils MSEE. Cet outil de diagnostic utilise une liste de contrôle d’accès pour compter les paquets atteignant des règles spécifiques, ce qui confirme la connectivité.
Exécuter un test
Dans le Portail Azure, sélectionnez Diagnostiquer et résoudre les problèmes à partir de votre circuit ExpressRoute.
Sélectionnez Problèmes de performances et de connectivité.
Dans la liste déroulante Donnez-nous plus d’informations sur le problème que vous rencontrez, sélectionnez Problèmes avec le Peering privé.
Développez la section Tester la connectivité de Peering privé.
Exécutez le test PsPing à partir de votre adresse IP locale vers votre IP Azure et continuez à l’exécuter pendant le test.
Remplissez les champs du formulaire avec les mêmes adresses IP utilisées à l’étape 5, puis sélectionnez Envoyer et attendez les résultats.
Interpréter les résultats
Passez en revue les résultats pour les appareils MSEE principaux et secondaires :
Correspondances envoyées et reçues sur les deux MSEE : indique un trafic entrant et sortant sain. Toute perte est dans le sens descendant à partir des MSEES.
Correspondances reçues, mais aucune correspondance envoyée : le trafic atteint Azure, mais n’effectue pas de retour. Consultez les problèmes de routage de chemin de retour.
Correspondances envoyées, mais aucune correspondance reçue : le trafic atteint une zone locale, mais n’effectue pas de retour vers Azure. Collaborez avec votre fournisseur pour résoudre le problème.
Un appareil MSEE n’affiche aucune correspondance, tandis que l’autre indique de bonnes correspondances : indique qu’un MSEE ne reçoit pas de trafic, ni n’en transmet. Il est possible qu’il soit hors connexion.
Si les résultats de test PsPing sur site vers Azure reçus indiquent des correspondances, mais que les résultats envoyés n’indiquent aucune correspondance : cela indique que le trafic est entrant dans Azure, mais qu’il ne revient pas sur site. Recherchez les problèmes de routage de chemin de retour. Par exemple, publiez-vous les préfixes appropriés sur Azure ? L’itinéraire défini par l’utilisateur (UDR) remplace-t-il les préfixes ?
Si les résultats de test PsPing de Azure vers le site envoyés indiquent des correspondances, mais les résultats reçus n’indiquent pas de correspondances : cela indique que le trafic est entrant localement, mais qu’il ne revient pas vers Azure. Vous travaillez avec votre fournisseur pour déterminer pourquoi le trafic n’est pas acheminé vers Azure via votre circuit ExpressRoute.
Un périmètre MSEE n’affiche aucune correspondance, tandis que l’autre indique de bonnes correspondances : cela indique qu’un périmètre MSEE ne reçoit pas de trafic, ni n’en transmet. Il peut être hors connexion (par exemple, BGP/ARP vers interrompu).
- Vous pouvez exécuter des tests supplémentaires pour confirmer le chemin d’accès non sain en publiant un itinéraire local /32 unique sur la session BGP sur ce chemin.
- Exécutez « Tester votre connectivité de Peering privé » en utilisant l’itinéraire /32 unique publié comme adresse de destination locale et examinez les résultats pour confirmer l’intégrité du chemin d’accès.
Les résultats de test pour chaque appareil MSEE sont similaires à l’exemple ci-dessous :
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
Vérifier la disponibilité de la passerelle réseau virtuel
La passerelle de réseau virtuel ExpressRoute gère la connectivité vers des services de liaison privée et des adresses IP privées dans un réseau virtuel Azure. Microsoft gère cette infrastructure. Il est possible qu’il effectue une maintenance, ce qui réduit les performances.
Si vous souhaitez résoudre des problèmes de connectivité et consulter la récente maintenance :
Dans le Portail Azure, sélectionnez Diagnostiquer et résoudre les problèmes à partir de votre circuit ExpressRoute.
Sélectionnez Problèmes de performance.
Attendez que les diagnostics s’exécutent, puis interprétez les résultats.
Si la maintenance s’est produite pendant la latence ou la perte de paquets, il est possible qu’elle ait contribué aux problèmes de connectivité. Suivez les étapes recommandées et envisagez de mettre à niveau la référence SKU de la passerelle de réseau virtuel pour prendre en charge un débit plus élevé et éviter de futurs problèmes.
Étapes suivantes
Pour plus d’informations ou d'aide, consultez les liens suivants :