Auteur Sujet: Utiliser Iperf en tant qu'agent de supervision (Lu 6565 fois)

FMJ · « **le:** 29 mars 2016 à 10:27:40 »

Bonjour,

Je souhaiterais pouvoir superviser de façon distante un tronçon de liaison bien précis (en fait une liaison laser) avec iPerf :
> de façon continue pour le délai de transit, la gigue et les pertes
> de façon cyclique pour le débit
Pour mesurer les "vraies" perfs de cette liaison (en s'affranchissant de l'impact des équipements réseau adjacents), j'utiliserai 2 Raspberry situés en début et en fin de liaison.
Je souhaite collecter les données mesurées sur un serveur (dans un premier temps elles seront agrégées et mises en forme par le couple RDD-CACTI, puis sur un vrai serveur de supervision type Nagios dans un second temps).

Par contre je me pose la question de la commande distante d'Iperf et de la collecte des données,sachant qu'iPerf n'intègre pas un rôle d'agent de supervision, genre SNMP ?!

Pour la commande, on peut soit utiliser la crontab du raspberry client, soit utiliser le script IperfiT de Nicolargo.

Par contre pour la collecte je n'ai pas trouvé d'info sur la façon de convertir le format de résultat d'Iperf en données utilisables par RDD ?!

Merci d'avance pour votre aide.

kgersen · « **Réponse #1 le:** 29 mars 2016 à 11:05:45 »

Iperf2 a une option de sortie en CVS (-y)
IPerf3 a une option de sortie en JSON (-J)

Dans les 2 cas il faut s'interfacer avec RRD donc programmer.

Sinon les créateurs d'IPerf ont leur propre 'agent': bwclt voir http://software.internet2.edu/bwctl/
C'est utilisé par PerfSONAR, l'outil de mesure et test d'Internet d'ESNet: http://ps-dashboard.es.net/ ou http://stats.es.net/ServicesDirectory/

Au besoin leur code peut s'adapter a un cas simple d'une seule liaison. http://www.perfsonar.net/about/where-can-it-be-downloaded/
ou regarder dedans comment ils récupèrent et traitent les sorties d'IPerf.

FMJ · « **Réponse #2 le:** 29 mars 2016 à 11:38:39 »

Bonjour,

Merci beaucoup pour ces infos très intéressantes. Je vais les analyser et faire un retour.
Merci encore !

vivien · « **Réponse #3 le:** 29 mars 2016 à 12:50:55 »

Tu n'as pas précisé si tu souhaitais faire les tests en UDP ou TCP. La gigue c'est en UDP et le débit réel, c'est plus du TCP.

iperf2, même la dernière version 2.0.8b a des souci de stabilité, si tout ne se passe pas comme prévu, cela plante.
iperf3 est bien robuste et performant en TCP.

Par contre pour l'UDP, je n'arrive pas à avoir des choses intéressantes avec iperf3. Il y a une sorte de protocole TCP au dessus d'UDP et les débit ne montent pas dès que la latence augmente.

Bref, je conseille toujours iperf 2 en UDP. Si une personne arrive à faire des tests a très haut débit en UDP avec iperf3, je suis intéressé par la ligne de commande.

FMJ · « **Réponse #4 le:** 29 mars 2016 à 13:09:27 »

OK, merci pour la précision.
Par contre quel ordre de grandeur ton "très haut débit" ?

En fait, question test de débit je vais être limité par les Raspberry qui n'ont que des interfaces 100Mbit/s alors que la liaison laser est en Gigabit.
J'ai vu qu'il était possible de mettre des adaptateurs Ethernet en USB3 sur un port USB2 pour monter dans les 300Mbit/s. Mais je pense que je me contenterai de tests épisodiques à 100Mbit/s.... en attendant un Raspberry v4.
A noter également que j'ai vu des tests sur d'autres "low-cost single-boards" en Gigabit Ethernet qui réservent quelques surprises sur les débits réels. Avec de grosses disparités entre sens montant et sens descendant. Par contre les Raspeberry sont au taquet de leurs interfaces, dans les deux sens, ce que je confirme.
https://netbeez.net/2015/10/21/network-monitoring-with-iperf-raspberry-pi-vs-odroid-vs-banana-pi-vs-utilite/

Avant la mise en prod de cette liaison, je l'avais testée une semaine continue avec 2 PC classiques : les débits simultanés étaient de l'ordre de 920Mbit/s (dans les 2 sens donc).

Cela dit en passant, disposant de 2 liaisons laser en prod (avec historiquement 3 équipementiers différents), si l'on peut être en "à vue", pas distant de 10km et que le climat n'est pas équatorial, je conseillerais fortement cette solution de raccordement, infiniment moins chère qu'une solution opérée et beaucoup plus performante et stable qu'une solution hertzienne. Ce n'est pas très connu et c'est un tort !

vivien · « **Réponse #5 le:** 29 mars 2016 à 13:25:09 »

J’envoie 250 Mb/s en UDP depuis une ligne FTTH 1 Gb/s down et 250 Mb/s up, voici les copies d'écran sur le serveur qui reçois les flux.

On es sur le port UDP 5001 pour les deux tests, donc la différence (les pertes de paquets) sont liée à iPerf3.

iPerf2 :
$ iperf -s -u -i 1 ------------------------------------------------------------ Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 194.158.xxx.xxx port 5001 connected with 5.51.xxx.xxx port 41097 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0- 1.0 sec 25.7 MBytes 215 Mbits/sec 0.096 ms 2906/21208 (14%) [ 3] 0.0- 1.0 sec 8 datagrams received out-of-order [ 3] 1.0- 2.0 sec 29.7 MBytes 249 Mbits/sec 0.094 ms 1/21206 (0.0047%) [ 3] 1.0- 2.0 sec 1 datagrams received out-of-order [ 3] 2.0- 3.0 sec 29.6 MBytes 249 Mbits/sec 0.059 ms 0/21145 (0%) [ 3] 3.0- 4.0 sec 29.6 MBytes 248 Mbits/sec 0.090 ms 2/21123 (0.0095%) [ 3] 3.0- 4.0 sec 2 datagrams received out-of-order [ 3] 4.0- 5.0 sec 29.6 MBytes 248 Mbits/sec 0.066 ms 2/21130 (0.0095%) [ 3] 4.0- 5.0 sec 2 datagrams received out-of-order [ 3] 5.0- 6.0 sec 29.5 MBytes 247 Mbits/sec 0.046 ms 1/21015 (0.0048%) [ 3] 5.0- 6.0 sec 1 datagrams received out-of-order [ 3] 6.0- 7.0 sec 29.6 MBytes 248 Mbits/sec 0.050 ms 1/21107 (0.0047%) [ 3] 6.0- 7.0 sec 1 datagrams received out-of-order [ 3] 7.0- 8.0 sec 29.6 MBytes 248 Mbits/sec 0.047 ms 1/21128 (0.0047%) [ 3] 7.0- 8.0 sec 1 datagrams received out-of-order [ 3] 8.0- 9.0 sec 29.6 MBytes 248 Mbits/sec 0.078 ms 2/21098 (0.0095%) [ 3] 8.0- 9.0 sec 2 datagrams received out-of-order [ 3] 0.0-10.0 sec 292 MBytes 245 Mbits/sec 0.085 ms 2905/211083 (1.4%) [ 3] 0.0-10.0 sec 21 datagrams received out-of-order

iPerf3 :
$ iperf3 -s -i 1 -p 5001 ----------------------------------------------------------- Server listening on 5001 ----------------------------------------------------------- Accepted connection from 5.51.xxx.xxx, port 48632 [ 5] local 194.158.xxx.xxx port 5001 connected to 5.51.xxx.xxx port 43710 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 6.43 MBytes 53.9 Mbits/sec 0.812 ms 2602/3425 (76%) [ 5] 1.00-2.00 sec 7.42 MBytes 62.3 Mbits/sec 0.726 ms 2972/3922 (76%) [ 5] 2.00-3.00 sec 7.14 MBytes 59.9 Mbits/sec 0.686 ms 2885/3799 (76%) [ 5] 3.00-4.00 sec 7.26 MBytes 60.9 Mbits/sec 0.924 ms 2890/3819 (76%) [ 5] 4.00-5.00 sec 7.38 MBytes 61.9 Mbits/sec 1.114 ms 2850/3794 (75%) [ 5] 5.00-6.00 sec 7.41 MBytes 62.1 Mbits/sec 0.862 ms 2791/3739 (75%) [ 5] 6.00-7.00 sec 7.14 MBytes 59.9 Mbits/sec 1.080 ms 2882/3796 (76%) [ 5] 7.00-8.00 sec 7.25 MBytes 60.8 Mbits/sec 0.841 ms 2899/3827 (76%) [ 5] 8.00-9.00 sec 7.38 MBytes 61.9 Mbits/sec 0.732 ms 2984/3929 (76%) [ 5] 9.00-10.00 sec 7.30 MBytes 61.3 Mbits/sec 0.768 ms 2772/3707 (75%) [ 5] 10.00-10.03 sec 0.00 Bytes 0.00 bits/sec 0.768 ms 0/0 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-10.03 sec 0.00 Bytes 0.00 bits/sec 0.768 ms 28527/37757 (76%)