Comment puis-je résoudre les problèmes de performances réseau Direct Connect ?

Résolution

Suivez ces instructions pour isoler et diagnostiquer les problèmes de performances du réseau et des applications.

Remarque : la bonne pratique consiste à configurer une machine de test dédiée sur site et avec un Amazon Virtual Private Cloud (Amazon VPC). Utilisez le type d'instance Elastic Compute Cloud (Amazon EC2) de taille C5 ou supérieure.

Problème de réseau ou d'application

Vous pouvez installer et utiliser l'outil iPerf3 pour évaluer la bande passante réseau et vérifier les résultats avec d'autres applications ou outils.

1.    Installation de Linux/REHEL :

$ sudo yum install iperf3 -y

Installation d'Ubuntu :

$ sudo apt install iperf3 -y

2.    Exécutez iPerf3 sur le client et le serveur pour mesurer le débit bidirectionnel de la même manière que ce qui suit :

Instances Amazon EC2 (seveur) :

$ iperf3 -s -V

Localhost sur site (client) :

$ iperf3 -c <private IP of EC2> -P 15 -t 15
$ iperf3 -c <private IP of EC2> -P 15 -t 15 -R

$ iperf3 -c <private IP of EC2> -w 256K
$ iperf3 -c <private IP of EC2> -w 256K -R

$ iperf3 -c <private IP of EC2> -u -b 1G -t 15
$ iperf3 -c <private IP of EC2> -u -b 1G -t 15 -R 

----------------
-P, --parallel n
    number of parallel client threads to run; It is critical to run multi-threads to achieve the max throughput.
-R, --reverse
    reverse the direction of a test. So the EC2 server sends data to the on-prem client to measure AWS -> on-prem throughput.
-u, --udp
    use UDP rather than TCP. Since TCP iperf3 does not report loss, UDP tests are helpful to see the packet loss along a path.

Exemples de résultats de test TCP :

[ ID] Interval          Transfer      Bitrate        Retry
[SUM] 0.00-15.00  sec  7.54 GBytes  4.32 Gbits/sec   18112   sender
[SUM] 0.00-15.00  sec  7.52 GBytes  4.31 Gbits/sec           receiver

Bitrate : débit ou vitesse de transmission mesuré.

Transfer : quantité totale de données échangées entre le client et le serveur.

Retry : le nombre de paquets retransmis. La retransmission est observée du côté de l'expéditeur.

Exemples de résultats de test UDP :

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5] 0.00-15.00  sec  8.22 GBytes   4.71 Gbits/sec  0.000 ms   0/986756 (0%)  sender
[  5] 0.00-15.00  sec  1.73 GBytes   989 Mbits/sec   0.106 ms   779454/986689 (79%)  receiver

La perte est de 0 % du côté de l'expéditeur car le nombre maximum de datagrammes UDP est envoyé.

Les datagrammes perdus/totaux du côté du récepteur indiquent le nombre de paquets perdus et le taux de perte. Dans cet exemple, 79 % du trafic réseau est perdu.

Remarque : si la connexion Direct Connect utilise un réseau privé virtuel Amazon (Amazon VPN) via une interface virtuelle publique (VIF), exécutez des tests de performances sans le VPN.

Vérifiez les métriques et les compteurs d'interface

Consultez Amazon CloudWatch Logs pour connaître les métriques suivantes :

• ConnectionErrorCount : appliquez la statistique de somme et notez que les valeurs non nulles indiquent des erreurs de niveau MAC sur l'appareil AWS.
• ConnectionLightLevelTX et ConnectionLightLevelRx : assurez-vous que les lectures du signal optique se situent dans la plage de -14,4 et 2,50 dBm.
• ConnectionBpsEgress, ConnectionBpsIngress, VirtualInterfaceBpsEgress et VirtualInterfaceBpsIngress : assurez-vous que le débit n'a pas atteint la bande passante maximale.

Pour plus d'informations, veuillez consulter la section Métriques et dimensions Direct Connect.

Si vous utilisez une interface virtuelle hébergée (VIF hébergée) qui partage la bande passante totale avec d'autres utilisateurs, vérifiez auprès du propriétaire Direct Connect l'utilisation de la connexion.

Vérifiez les points suivants sur le routeur et le pare-feu de l'emplacement Direct Connect :

• CPU, mémoire, utilisation des ports, chutes, rejets.
• Utilisez « show interfaces statistics » ou similaire pour vérifier les erreurs d'entrée et de sortie d'interface telles que CRC, trame, collisions et porteuse.
• Nettoyez ou remplacez le câble de raccordement à fibre optique et le module SFP pour les compteurs usés.

Consultez le AWS Personal Health Dashboard pour vous assurer que la connexion Direct Connect n'est pas en cours de maintenance.

Exécutez MTR de manière bidirectionnelle pour vérifier le chemin réseau

Vous pouvez utiliser la commande MTR Linux pour analyser les performances du réseau. Pour le système d'exploitation Windows, la bonne pratique consiste à activer WSL 2 afin de pouvoir installer MTR sur un sous-système Linux. Vous pouvez télécharger WinMTR depuis le site Web de SourceForge.

1.    Installation d'Amazon Linux/REHEL :

$ sudo yum install mtr -y

Installation d'Ubuntu :

$ sudo apt install mtr -y

2.    Pour la direction sur site—> 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 la direction AWS —> sur 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

Exemples de résultats de test MTR :

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

Chaque ligne d'un saut représente un périphérique réseau que le paquet de données transmet de la source à la destination. Pour plus d'informations sur la lecture des résultats des tests MTR, veuillez consulter le site Web ExaVault.

L'exemple suivant montre une connexion Direct Connect avec les pairs BGP 10.110.120.1 et 10.110.120.2. Le pourcentage de perte est observé aux 4e et 5e sauts de destination. Cela peut indiquer un problème avec la connexion Direct Connect ou le routeur distant 10.110.120.1. Le résultat TCP MTR indique un pourcentage de perte inférieur car TCP est priorisé par rapport à ICMP avec la connexion Direct Connect.

#ICMP based MTR results
$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 20:54:39 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.7   0.7   0.6   0.9   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  266.5 267.4 266.4 321.0   4.8
  4.|-- 10.110.120.1              54.5%   100  357.6 383.0 353.4 423.7  19.6
  5.|-- 192.168.52.10             47.5%   100  359.4 381.3 352.4 427.9  20.6

#TCP based MTR results
$ mtr -n -T -P 80 -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:03:48 2021
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               0.0%   100    0.9   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               0.0%   100  264.1 265.8 263.9 295.3   3.4
  4.|-- 10.110.120.1               8.0%   100  374.3 905.3 354.4 7428. 1210.6
  5.|-- 192.168.52.10             12.0%   100  400.9 1139. 400.4 7624. 1384.3

L'exemple suivant montre la perte de paquets du pare-feu local ou du périphérique NAT à 5 %. La perte de paquets a un impact sur tous les sauts suivants, y compris la destination.

$ mtr -n -c 100 192.168.52.10 --report
Start: Sat Oct 30 21:11:22 2021
HOST:                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.0.101.222               5.0%   100    0.8   0.7   0.7   1.1   0.0
  2.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  3.|-- 10.110.120.2               6.0%   100  265.7 267.1 265.6 307.8   5.1
  4.|-- 10.110.120.1               6.0%   100  265.1 265.2 265.0 265.4   0.0
  5.|-- 192.168.52.10              6.0%   100  266.7 266.6 266.5 267.2   0.0

Effectuez une capture de paquets et analysez les résultats

Faites une capture de paquets sur l'hôte local et l'instance EC2. Utilisez l'utilitaire tcpdump ou Wireshark pour obtenir le trafic réseau à des fins d'analyse. L'exemple de commande tcpdump suivant obtient l'horodatage et l'adresse IP de l'hôte :

tcpdump -i <network interface> -s0 -w $(date +"%Y%m%d_%H%M%S").$(hostname -s).pcap port <port>

Utilisez le calculateur de débit TCP sur le site Web Switch pour calculer la limite réseau, le produit de retard de bande passante et la taille du tampon TCP.

Pour plus d'informations, veuillez consulter la section Résolution des problèmes liés à AWS Direct Connect.

---

Informations connexes

Quelle est la différence entre une interface virtuelle et une connexion hébergée ?