Comment puis-je résoudre les problèmes de perte de paquets pour ma connexion Direct Connect ?

Résolution

La perte de paquets se produit lorsque les paquets de données transmis n'arrivent pas à destination, ce qui entraîne des problèmes de performances réseau. La perte de paquets est causée par une faible puissance du signal à la destination, une utilisation excessive du système, une surcharge du réseau ou des erreurs de configuration des acheminements réseau.

Effectuez les vérifications suivantes pour vos périphériques réseau et votre connexion Direct Connect.

Consulter AWS Personal Health Dashboard pour la maintenance ou les événements planifiés

L'AWS Personal Health Dashboard affiche des informations pertinentes concernant les ressources en cours de maintenance et fournit également des notifications pour les activités. Pour plus d'informations, voir la rubrique Comment puis-je recevoir des notifications pour la maintenance planifiée ou les événements de Direct Connect ?

Vérifiez les métriques relatives au point de terminaison Direct Connect, à la passerelle client et à l'appareil intermédiaire (couche 1)

En ce qui concerne la passerelle client et les appareils intermédiaires, le problème peut être local par rapport au réseau sur site ou au chemin de transit vers AWS. Vérifiez les points suivants sur le nœud sur site et les appareils intermédiaires :

• Les journaux de la passerelle client enregistrent les volets d'interface
• Utilisation du processeur pour la passerelle client lorsque le problème s'est produit
• La lecture du signal lumineux sur l'appareil indique la fin de la connexion Direct Connect
• L'appareil auquel la connexion Direct Connect met fin en raison d'erreurs d’entrée, d'erreurs de cadrage incrémentiel, d'erreurs de redondance cyclique (CRC), de runts, de géants ou d'accélérateurs

Vérifiez les métriques de connexion Direct Connect (couche 1)

Vérifiez les métriques Direct Connect suivantes :

• ConnectionErrorCount : Appliquez la statistique de somme pour cette métrique. Notez que les valeurs différentes de zéro indiquent des erreurs de niveau MAC dans l'appareil AWS.
• ConnectionLightLevelTX et ConnectionLightLevelRX : Vérifiez le signal lumineux enregistré sur la connexion Direct Connect lorsque le problème s'est produit. La plage acceptable est comprise entre -14,4 et 2,50 dBm.
• ConnectionBPSegress et ConnectionBPSingress : Vérifiez le volume de trafic sur la connexion Direct Connect lorsque la perte de paquets s'est produite en raison de la surcharge sur la liaison. Si vous utilisez 100 % de la capacité de l'interface, vous pourrez subir des pertes de paquets et des excès de trafic.

Pour plus d'informations, consultez les Métriques de connexion Direct Connect.

Vérifier la présence d'un routage sous-optimal asymétrique (couche 3)

Le routage asymétrique survient lorsque le trafic réseau entre par une connexion et sort par une autre connexion. Ce routage peut entraîner la perte de paquets si le pare-feu sur site effectue une transmission de chemin inverse en unicast entraînant une baisse du trafic réseau.

• Si vous disposez d'une connexion Direct Connect redondante de secours ou d'une connexion AWS Site-to-Site VPN de secours, vérifiez tout routage asymétrique potentiel.
• Supposons que vous disposiez d'une connexion Site-to-Site VPN de secours et que vous annonciez des préfixes similaires sur les connexions Direct Connect et VPN. Dans ce cas, le trafic d'AWS sur site est acheminé via Direct Connect. Pour éviter un routage asymétrique, assurez-vous d'envoyer le trafic uniquement via Direct Connect du site vers AWS.
• Si vous disposez d'une connexion Direct Connect de secours, un routage asymétrique peut se produire en fonction de la manière dont vous publiez vos préfixes sur les deux connexions Direct Connect.
• Un routage sous-optimal avec le réseau local peut entraîner la perte de paquets.

Pour plus d'informations, consultez la rubrique Comment puis-je résoudre les problèmes de routage asymétrique lorsque je crée un VPN en tant que sauvegarde de Direct Connect dans une passerelle de transit ?

Route de traçage bidirectionnelle de bout en bout entre l'hôte sur site et l'hôte AWS (couche 3)

L'acheminement de traces en cours entre les hôtes détermine le chemin réseau emprunté dans les deux sens. Les résultats du traçage déterminent également si le routage est asymétrique, si la charge est équilibrée, etc.

1.Exécutez la commande suivante pour installer traceroute :

Linux :

sudo yum install traceroute

Ubuntu :

sudo apt-get install traceroute

2.Exécutez une commande similaire à la suivante pour le traceroute TCP :

sudo traceroute -T -p <destination Port> <IP of destination host>

Système d'exploitation Windows :

1. Téléchargez WinPcap et tracetcp.
2. Extrayez le fichier Tracetcp.
3. Copiez tracetcp.exe sur votre lecteur C.
4. Installez WinPcap.
5. Ouvrez l'invite de commande et WinPcap racine sur votre lecteur C à l'aide de la commande C:\Users\username>cd \.
6. Exécutez tracetcp à l'aide des commandes suivantes : tracetcp.exe hostname:port ou tracetcp.exe ip:port.

Test MTR bidirectionnel de bout en bout entre l'hôte sur site et l'hôte AWS (couche 3)

Les tests MTR sont similaires à traceroute pour permettre la découverte de chaque routeur dans le chemin de connexion réseau entre les hôtes. Les tests MTR fournissent également des informations sur chaque nœud du chemin, telles que la perte de paquets.

Vérifiez les résultats du MTR en ce qui concerne la perte de paquets et la latence du réseau. Un pourcentage de perte réseau à un saut peut indiquer un problème avec le routeur. Certains fournisseurs de services limitent le trafic ICMP utilisé par MTR. Pour déterminer si la perte de paquets est due à des limites de débit, passez en revue les sauts suivants. Si le saut suivant montre une perte de 0,0 %, cela peut indiquer une limitation du débit ICMP.

1.Exécutez la commande suivante pour installer MTR :

Amazon Linux/REHEL :

$ sudo yum install mtr -y

Ubuntu :

sudo apt install mtr -y

Système d'exploitation Windows :

Téléchargez et installez WinMTR.

Remarque : Pour le système d'exploitation Windows, WinMTR ne prend pas en charge le MTR basé sur TCP.

2.Pour l'orientation sur site vers AWS, exécutez MTR sur l'hôte local (basé sur ICMP et TCP) :

$ mtr -n -c 100 <private IP of EC2> --report
$ mtr -n -T -P <EC2 instance open TCP port> -c 100 <private IP of EC2> --report

3. Pour l'orientation AWS vers le site, exécutez MTR sur l'instance EC2 (basée sur ICMP et TCP) :

$ mtr -n -c 100 <private IP of the local host> --report
$ mtr -n -T -P <local host open TCP port> -c 100 <private IP of the local host> --report

Passer en revue la MTU du chemin entre l'hôte sur site et l'hôte AWS (couche 3)

L'unité de transmission maximale (MTU) est la taille du plus gros paquet autorisé transmis via la connexion réseau. Tout paquet supérieur à la taille de la MTU est supprimé sur l'interface. Par conséquent, une perte de paquets peut se produire si le paquet est volumineux.

La découverte MTU du chemin (PMTUD) détermine le chemin de la MTU. Pour plus d'informations, consultez Path MTU Discovery.

Vous pouvez vérifier le chemin MTU entre deux hôtes à l'aide de tracepath.

1.Pour l'itinéraire sur site vers AWS, exécutez tracepath sur le port 80 depuis l'hôte local :

$ tracepath -n -p 80 <EC2 private instance IP>

2.Pour le trajet entre AWS et le site, exécutez tracepath sur le port 80 à partir de l'instance EC2 :

$ tracepath -n -p 80 <private IP of local host>

Vérifiez les éventuels problèmes de routage avec BGP

La connexion Direct Connect utilise le protocole de passerelle frontière (BGP) du protocole de routage dynamique (BGP) pour le routage et la communication entre AWS et le site.

Vérifiez s'il y a des volets réguliers dans le BGP qui pourraient provoquer une perte intermittente de paquets.

Vérifiez l'âge de routage des routes apprises depuis AWS au réseau client sur le dispositif de passerelle client. Lorsque les routes sont actualisées sur le dispositif de passerelle client, l'âge de routage est mis à jour dans la table de routage du BGP. Vous pouvez vérifier ces informations pour savoir si la perte de paquets s'est produite brièvement lors de l'actualisation de la route.

Pour vérifier l'âge de routage sur un routeur Cisco, exécutez la commande suivante :

Router#sh ip bgp 1.1.1.1       
BGP routing table entry for 1.1.1.1/32, version 3
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  64512, (received & used)
    169.254.92.181 from 169.254.92.181 (169.254.92.181)
      Origin IGP, metric 100, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Mar 31 2023 08:08:00 UTC    >> Last time that the route was updated

-or-

Router#sh ip route | in 1.1.1.1
B    1.1.1.1 [20/100] via 169.254.92.181, 01:37:46   >> You can see the route age or when the route was last refreshed

Si vous utilisez une connexion hébergée, vérifiez auprès de votre partenaire ou fournisseur de services si la perte de paquets découle de sa maintenance.

Informations complémentaires

Bonnes pratiques en matière de configuration des interfaces réseau

Comment puis-je surveiller la perte de paquets et la latence depuis AWS vers un réseau sur site via une passerelle Internet ou une passerelle NAT ?

Résolution des problèmes liés à AWS Direct Connect

Comment puis-je résoudre les problèmes de performances du réseau Direct Connect ? Téléchargez WinPcap et tracetcp.