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 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

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.

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 :

1. appareil de calcul du client (par exemple, un serveur ou un PC)
2. routeurs de périphérie du client (CE)
3. routeurs/commutateurs de périphérie du fournisseur qui collaborent avec des routeurs de périphérie du client
4. extension des PE qui rencontre les routeurs Microsoft Enterprise Edge ExpressRoute (MSEE). Cet article les appelle PE-MSEE.
5. MSEE.
6. Passerelle de réseau virtuel.
7. 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.

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.

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é.

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"

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

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

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.

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

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.

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

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

1. 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.

   

2. Sélectionnez Problèmes de performances et de connectivité.

   

3. Dans la liste déroulante Dites-nous en plus sur le problème que vous vivez, sélectionnez Problèmes avec le Peering privé.

   

4. Faites défiler l’affichage vers le bas jusqu’à la section Tester la connectivité du Peering privé et développez-la.

   

5. 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é.

6. 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 :

1. Sélectionnez Diagnostiquer et résoudre les problèmes à partir de votre circuit ExpressRoute dans le Portail Azure.

   

2. Sélectionnez l’option Problèmes de performance.

   

3. 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 :

• Support Microsoft
• Création et modification d’un circuit ExpressRoute
• Créer et modifier le routage pour un circuit ExpressRoute