Vérifier la connectivité ExpressRoute

Article
08/30/2023

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 généralement facilitée par un fournisseur de connectivité. La connectivité ExpressRoute implique traditionnellement 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). Le modèle de connectivité directe contient uniquement vos propres zones de réseau et celles de Microsoft.

Cet article vous aide à identifier l’existence d’un problème de connectivité. Vous pouvez par conséquent rechercher la prise en charge par l’équipe appropriée de la résolution du problème.

Important

Cet article a pour objet de vous aider à diagnostiquer et résoudre les problèmes simples. Il n’a pas pour objet de remplacer le support de Microsoft. Si vous ne pouvez pas résoudre un problème en suivant les instructions de cet article, 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 précédent, 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)
routeurs/commutateurs de périphérie du fournisseur qui collaborent avec des routeurs de périphérie du client
extension des PE qui rencontre les routeurs Microsoft Enterprise Edge ExpressRoute (MSEE). Cet article les appelle PE-MSEE.
MSEE.
Passerelle de réseau virtuel.
Appareil de calcul sur le réseau virtuel Azure.

Parfois, cet article fait référence à ces points réseau 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é ExpressRoute 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.

Notes

Pour une 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 plus d’informations sur la haute disponibilité, consultez l’article 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 plus d’informations sur la manière de créer, de modifier, de provisionner et de vérifier un circuit ExpressRoute, consultez l’article 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 d’assistance de la part de Microsoft ou d’un partenaire ExpressRoute pour résoudre un problème lié à ExpressRoute, entrez la clé de service afin d’identifier facilement le circuit.

Vérification par le biais du portail Azure

Dans le Portail Azure, ouvrez la page du 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 informations essentielles ExpressRoute, État du circuit indique l’état du circuit côté Microsoft. État du fournisseur indique si le circuit a été approvisionné ou non approvisionné côté fournisseur de service.

Pour qu'un circuit ExpressRoute soit opérationnel, État du circuit doit être Activé et État du fournisseur doit être Approvisionné.

Notes

Après la configuration d’un circuit ExpressRoute, si État du circuit est bloqué à un état Désactivé, contactez le Support Microsoft. Si État du fournisseur est bloqué à un état Non approvisionné, contactez votre fournisseur de services.

Vérification par le biais de PowerShell

Pour répertorier tous les circuits ExpressRoute dans un groupe de ressources, utilisez la commande suivante :

Get-AzExpressRouteCircuit -ResourceGroupName "Test-ER-RG"

Conseil

Si vous recherchez le nom d’un groupe de ressources, vous pouvez l’obtenir en utilisant la commande Get-AzResourceGroup pour répertorié tous les groupes de ressources dans votre abonnement.

Pour sélectionner 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, portez une attention particulière aux champs suivants :

CircuitProvisioningState         : Enabled
ServiceProviderProvisioningState : Provisioned

Notes

Valider la configuration du Peering

Une fois que le fournisseur de services a terminé l’approvisionnement du circuit ExpressRoute, plusieurs configuration de routage basées sur BGP (eBGP) peuvent être créées 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 : trafic vers des réseaux virtuels privés dans Azure
Peering Microsoft : trafic vers des points de terminaison publics de platform as a service (PaaS) et software as a service (SaaS)

Pour plus d’informations sur la création et la modification de la configuration de routage, consultez l’article 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). Dans un tel modèle, une fois que le fournisseur de services a configuré un peering et si le peering est vide dans le portail, essayez d’actualiser la configuration du circuit à l’aide du 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 la page de ce circuit. La section de la page répertorie les appairages d’ExpressRoute, tels qu’ils apparaissent dans la capture d’écran suivante :

Dans l’exemple précédent, le Peering privé Azure est provisionné, mais que les Peerings Microsoft et publics Azure ne sont pas provisionnés. Un contexte de Peering correctement approvisionné doit également répertorier les sous-réseaux point à point principaux et secondaires. Les sous-réseaux /30 sont utilisés pour l’adresse IP d’interface des MSEE et CE/PE-MSEE. Pour les Peerings approvisionnées, la liste indique également qui a modifié la configuration pour la dernière fois.

Notes

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 correctes sont utilisées sur des MSEE et que ces valeurs correspondent à celles utilisées sur le CE/PE-MSEE lié.

Si le code de hachage MD5 est choisi, la clé partagée doit être la même sur la paire MSEE et CE/PE-MSEE. Les clés partagées précédemment configurées ne sont pas affichées 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.

Notes

Sur un sous-réseau /30 attribué à l’interface, Microsoft choisit la deuxième adresse IP utilisable du sous-réseau pour l’interface MSEE. Par conséquent, assurez-vous que la première adresse IP utilisable du sous-réseau a été attribuée sur le CE/PE-MSEE homologué.

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 l’adresse 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 vous devez modifier l’une de ces configurations sur un routeur MSEE, consultez Créer et modifier le routage pour un circuit ExpressRoute.

Notes

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 obtenir 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 ******* -PeeringType AzurePrivatePeering -ResourceGroupName ****

Voici un 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##

Notes

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 de Peering principaux et secondaires attribués correspondent à la configuration sur le CE/PE-MSEE lié. Vérifiez également que les valeurs VlanId, AzureASN et PeerASN correctes sont utilisées sur des MSEE et que ces valeurs correspondent à celles utilisées sur le CE/PE-MSEE lié. Si le code de hachage MD5 est choisi, la clé partagée doit être la même sur la paire MSEE et CE/PE-MSEE. Si vous devez modifier l’une de ces configurations sur un routeur MSEE, consultez Créer et modifier le routage pour un circuit ExpressRoute.

Notes

Si certaines destinations ne sont pas accessibles par le biais d’un Peering, vérifiez la table de route des MSEE pour le contexte de Peering correspondant. Si un préfixe correspondant (peut être une adresse IP de NAT) est présent dans la table de routage, vérifiez que des pare-feu, des groupes de sécurité réseau ou des listes de contrôle d’accès (ACL) sur le chemin d’accès bloquent le trafic.

L’exemple suivant montre la réponse de la commande pour un peering qui n’existe pas :

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Confirmation du flux de trafic

Pour obtenir les statistiques combinées du trafic de chemin d’accès primaire et secondaire (octets en entrée et en sortie) d’un contexte de Peering, utilisez la commande suivante :

Get-AzExpressRouteCircuitStats -ResourceGroupName $RG -ExpressRouteCircuitName $CircuitName -PeeringType 'AzurePrivatePeering'

Voici un exemple de sortie de la commande :

PrimaryBytesIn PrimaryBytesOut SecondaryBytesIn SecondaryBytesOut
-------------- --------------- ---------------- -----------------
     240780020       239863857        240565035         239628474

Voici un exemple de sortie de la commande d’un Peering inexistant :

Get-AzExpressRouteCircuitRouteTable : The BGP Peering AzurePublicPeering with Service Key ********************* is not found.
StatusCode: 400

Tester la connectivité de peering privé

Testez votre connectivité de Peering privé en comptant les paquets arrivant et quittant le périmètre Microsoft de votre circuit ExpressRoute, sur les appareils MSEE. Cet outil de diagnostic fonctionne en appliquant une liste de contrôle d’accès (ACL) au MSEE pour compter le nombre de paquets qui satisfont aux règles ACL spécifiques. Cet outil vous permet de confirmer la connectivité en répondant à des questions telles que :

Mes paquets atteignent-ils Azure ?
Vont-ils revenir sur site ?

Exécuter un test

Pour accéder à cet outil de diagnostic, sélectionnez Diagnostiquer et résoudre les problèmes à partir de votre circuit ExpressRoute dans le Portail Azure.
Sélectionnez Problèmes de performances et de connectivité.
Dans la liste déroulante Dites-nous en plus sur le problème que vous vivez, sélectionnez Problèmes avec le Peering privé.
Faites défiler l’affichage vers le bas jusqu’à la section Tester la connectivité du Peering privé et développez-la.
Exécutez le test PsPing à partir de votre adresse IP locale vers votre adresse IP Azure et continuez à l’exécuter pendant le test de connectivité.
Renseignez les champs du formulaire. Veillez à entrer les mêmes adresses IP locales et Azure que celles que vous avez utilisées à l’étape 5. Ensuite, sélectionnez Envoyer, puis attendez que vos résultats se chargent.

Interpréter les résultats

Lorsque vos résultats sont prêts, vous disposez de deux ensembles pour les appareils MSEE principal et secondaire. Examinez le nombre de correspondances et utilisez les scénarios suivants pour interpréter les résultats :

Vous voyez les correspondances de paquets envoyées et reçues sur les deux périmètres MSEE : cela indique un trafic sain entrant et sortant du périmètre MSEE sur votre circuit. Si la perte se produit en local ou dans Azure, elle se produit en aval du périmètre MSEE.
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é » à l’aide de 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

Ce résultat de test a les propriétés suivantes :

Port IP : 3389
CIDR d’adresse IP locale : 10.0.0.0
CIDR d’adresse IP Azure : 20.0.0.0

Vérifier la disponibilité de la passerelle réseau virtuel

La passerelle de réseau virtuel ExpressRoute facilite la gestion et la connectivité du plan de contrôle pour des services de liaison privée et des adresses IP privées déployés sur un réseau virtuel Azure. Microsoft gère l’infrastructure de passerelle de réseau virtuel qui fait parfois l’objet d’une maintenance.

Les périodes de maintenance peuvent limiter les performances de la passerelle de réseau virtuel. Pour résoudre les problèmes de connectivité au réseau virtuel et vérifier si une opération de maintenance récente est à l’origine d’une réduction de la capacité, procédez comme suit :

Sélectionnez Diagnostiquer et résoudre les problèmes à partir de votre circuit ExpressRoute dans le Portail Azure.
Sélectionnez l’option Problèmes de performance.
Attendez que les diagnostics s’exécutent et interprétez les résultats.

Si votre passerelle de réseau virtuel a fait l’objet d’une maintenance pendant une période où vous avez subi une latence ou une perte de paquets, il est possible que la capacité réduite de la passerelle ait contribué aux problèmes de connectivité que vous rencontrez avec le réseau virtuel ciblé. Suivez les étapes recommandées. Pour prendre en charge un débit réseau plus élevé et éviter les problèmes de connectivité lors des événements de maintenance futurs, envisagez de mettre à niveau la référence SKU de la passerelle réseau virtuel.

Étapes suivantes

Pour plus d’informations ou d'aide, consultez les liens suivants :

Partager via

Vérifier la connectivité ExpressRoute

Vue d’ensemble

Vérification de l’approvisionnement et de l’état du circuit

Vérification par le biais du portail Azure

Vérification par le biais de PowerShell

Valider la configuration du Peering

Vérification par le biais du portail Azure

Vérification par le biais de PowerShell

Validation d’ARP

Validation de BGP et des itinéraires sur les MSEE

Confirmation du flux de trafic

Tester la connectivité de peering privé

Exécuter un test

Interpréter les résultats

Vérifier la disponibilité de la passerelle réseau virtuel

Étapes suivantes

Commentaires

Ressources supplémentaires