Comment utiliser iPerf pour tester et dépanner la perte de paquets UDP

Le contenu de cet article explique comment utiliser iPerf pour tester et résoudre les problèmes de perte de paquets UDP. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Utilisez iPerf pour tester et résoudre les problèmes de perte de paquets UDP

Description des phénomènes

Utilisez des canaux haut débit pour ouvrir le même région (Région Après avoir configuré deux instances ECS du type de réseau VPC sous Le taux montre une tendance à la hausse. Comme indiqué ci-dessous :

Analyse du problème

Supposons que les adresses IP privées de deux instances ECS de type réseau sont VPC ECS A (192.168.104.235) et ECS B (10.182.83.13) et utilisent Netcat (NC) pour surveiller et envoyer des paquets de données UDP, le schéma de liaison de communication entre l'instance ECS A et l'instance B du type de réseau est le suivant :

La direction du flux de données est :

ECS A(192.168.104.235)-> NC 1(100.105.59.3)-> VGW(10.141.166.253)-> NC 2(100.105.59.9)-> ECS B(10.182.83.13)

Nous devons dépanner et analyser son lien pour découvrir la cause ultime de la perte de paquets.

Solution

Remarque : Puisque seule la communication entre la source Netcat (c'est-à-dire NC 1) et la destination Netcat (c'est-à-dire NC 2) est vue, La capture et le dépannage des paquets doivent éviter les malentendus, c'est-à-dire juger arbitrairement que la perte de paquets est causée par une communication directe entre Netcat (NC).

Lors du dépannage, on constate que la capture du paquet eth0 à l'extrémité source est envoyée à VGW, mais lors de la capture du paquet à l'extrémité de destination, on constate que le shell encapsule l'IP NC 2 de destination , comme dans l'exemple :

 [Time ] 17:32:07.130844   Point: `input `
 [ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
 [IPv4 ] 100.105.59.3 -> 10.141.166.253
 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0xfe47
 [UDP  ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 1878597, tos: 0, tof: 0
 [IPv4 ] 192.168.104.235 -> 10.182.83.13
 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
 [UDP  ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
 [Time ] 17:32:07.130854   Point: `output`
 [ETHER] 24:4c:07:33:0e:02 -> 00:04:37:28:00:65, eth_type: 0x0800
 [IPv4 ] 100.105.59.3 -> 100.105.59.9
 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0x0000
 [UDP  ] sport: 46703, dport: 250, size: 1514, chksum: 0x0000
 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 2125861, tos: 0, tof: 0
 [IPv4 ] 192.168.104.235 -> 10.182.83.13
 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e
 [UDP  ] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa

Confirmez les données Une fois le paquet passé via VGW, les statistiques des informations de capture de paquets sont lancées :

ECS A reçoit le trafic UDP via iPerf : iperf -c 10.182.83.13 -u -b 600m

ECS B reçoit via iPerf : iperf -u -s

capture les paquets à l'intérieur de l'instance.

ECS A：sudo tcpdump -w ~/client.pcap -n -i eth0 src host 192.168.104.25 and src port 1234
ECS B：sudo tcpdump -w ~/server.pcap -n -i eth0 src host 192.168.104.25 and src port 1234

Capturez des paquets à deux emplacements NC eth0.

NC 1：sudo houyi-tcpdump -w /apsara/i-6we6pnh19n2q7srkgomd.pcap -nnK -i eth0
 udp and src inner_port 1234 and dst inner_host 10.182.83.13
NC 2：sudo houyi-tcpdump -B 4096 -w /apsara/i-6we53i9h3ducbju5rmuw.pap -nn -i eth0 
udp -K and src inner_host 192.168.104.235 and src inner_port 1234

Déployer des systèmes de flux dans ASW et LSW.

100.105.59.3:46728 -> 10.141.166.253:250

Remarque : Étant donné que le shell du paquet de destination encapsule automatiquement l'adresse IP NC 1 de destination, le format de message du paquet de données côté VGW est : 100.105.59.3:46728 ->

Analyse basée sur les résultats de capture de paquets.

Perte/envoi de paquets ECS A : 171/510203

Envoi de paquets NC 1 eth0 : 510204

Envoi de paquets de statistiques de flux ASW et LSW : 510204

Paquet NC 2 eth0 reçu : 510204

Paquet ECS B reçu : 510204, capture 507442, abandonné par le noyau 2162

L'analyse ci-dessus localise la perte de paquets dans la pile de protocole d'instance et ajuste l'UDP interne Tailles de tampon de l'instance. Ajustez la pile réseau (Pile). La taille du tampon UDF par défaut est 212992 (208 Ko) et vous pouvez l'ajuster à 2097152 (2 Mo).

/proc/sys/net/core/rmem_default #默认的接收数据包内存大小
/proc/sys/net/core/rmem_max #最大的接收数据包内存大小

Testez la perte de paquets UDP après ajustement.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!