Contents

Pratiques de diagnostic réseau
Tests automatisés de réseau

Pratiques de diagnostic réseau

Voir aussi ConnexionInternet/DiagnostiquesBureau pour les spécificités du bureau.

Diagnostics de base

Ces tests visent à assurer l'utilisateur d'une connexion à l'internet.

Charger une page web

Bien que l'internet ne se limite pas au web, charger une page web comme http://google.com/ ou http://yahoo.com/ est une excellente façon de tester, qualitativement, la disponibilité du réseau. Le chargement d'une page web ne signifie cependant pas que tout l'internet fonctionne ou est disponible. Charger la page web du site ou du serveur que l'on tente de rejoindre est évidemment une meilleure façon de vérifier la disponibilité du site, mais encore une fois, ce n'est pas tous les sites qui ont des pages web (par exemple, certains offrent seulement des services de courriels).

Connectivité générale: commande ping

Ping doit fonctionner, normalement, pour rejoindre un site connu. Commencer par une IP (au lieu d'un nom de domaine) permet de facilement tester la connectivité en bypassant le DNS:

anarcat@mumia [~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=61.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=47.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=56.4 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 47.567/55.088/61.264/5.678 ms

Ici, l'opérateur a testé la connectivité avec l'adresse 8.8.8.8, qui a répondu aux trois requêtes (64 bytes from ... ) avant que l'opérateur termine le test avec control-c (^C). Une fois interrompu, ping affiche des informations de performance, démontrant la latence du lien.

Une addresse non-fonctionnelle donnerait une sortie du genre:

anarcat@mumia [~]$ ping 8.1.2.3
PING 8.1.2.3 (8.1.2.3) 56(84) bytes of data.

Puis plus rien...

Un autre exemple, qui se manifeste sur les réseaux locaux:

anarcat@mumia [~]$ ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
From 192.168.0.125 icmp_seq=1 Destination Host Unreachable
From 192.168.0.125 icmp_seq=2 Destination Host Unreachable

Adresses de test

L'idée est d'apprendre au moins une addresse par coeur pour pouvoir tester lorsque le DNS est down:

8.8.8.8: pratique et facile à se rappeler, mais pas toujours disponible
199.58.80.33: serveur principal de Koumbit

Outil web

Utile pour les machines avec des ips publics.

http://www.just-ping.com/index.php?vh=199.58.80.33 (lien ping sur homere.koumbit.net)

Connectivité locale: tester la passerelle

Si les addresses de test ne fonctionnent pas, il faut vérifier que la connexion locale fonctionne bien. Décrouvrir la passerelle dépend de votre plateforme, mais dans un terminal unix, la commande route -n ou netstat -rn suffisent. Exemple:

anarcat@mumia [~]$ netstat -rn
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic   MSS Fenêtre irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth1

Ici, la passerelle est 192.168.0.1. D'autres outils offrent également des informations de connectivité, généralement sur l'icône de connectivité de votre bureau favori.

On peut tester la connectivité avec ping:

anarcat@mumia [~]$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.12 ms

Ici, la passerelle répond bien. Si la passerelle ne répond pas, le problème de connectivité est local et doit être résolu à ce niveau. Renouveler son adresse IP (son "bail" avec le ServeurDhcp) peut résoudre le problème. Sinon il est également possible d'entamer une ConfigurationRéseauStatique.

Si la passerelle répond mais pas les IPs de tests, de deux choses l'une, soit:

le réseau local n'est pas connecté à internet, ou;
l'IP de test n'est pas disponible.

Dans le cas #1, il faut évidemment résoudre les problèmes de connectivités locaux, qui varient alors énormément dépendemment du lien physique.

Dans le cas #2, il faut évidemment tester une autre adresse.

Disponibilité DNS

Si tous les tests PING fonctionnent mais que les pages web ne fonctionnent toujours pas, il est également possible qu'il y ait un problème au niveau du DNS. On peut donc alors simplement tester la résolution de domaines, avec la commande ping encore une fois, car ping doit résoudre les noms de domaines qu'on lui fournit avant de faire un ping.

Exemple de DNS fonctionnel

anarcat@mumia [~]$ ping koumbit.net
PING koumbit.net (199.58.80.33) 56(84) bytes of data.

Exemple de DNS non-fonctionnel

anarcat@mumia [~]$ ping hjlkdsajflds
ping: unknown host hjlkdsajflds

On peut alors tester un autre serveur DNS. La commande shell pour ce faire est host ou dig (qui donne plus de résultats). Exemple:

anarcat@mumia [~]$ host koumbit.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

koumbit.net has address 209.44.112.66
koumbit.net mail is handled by 5 mail.koumbit.net.

Ici, on demande au serveur 8.8.8.8 l'addresse IP du domaine koumbit.net. Le serveur répond correctement. Si le serveur local ne répond pas correctement, il est possible de modifier les serveurs DNS par défaut en éditant /etc/resolv.conf sous UNIX.

Contourner un problème avec la coupure d'un seul serveur DNS

Si un seul de vos serveurs DNS est brisé dans votre configuration (suite à vos tests) vous pouvez le retirer de votre /etc/resolv.conf ou encore ajouter cette ligne pour forcer libc à essayer l'autre serveur de nom:

options timeout:1 attempts:1 rotate

Disponibilité de port

Si tous les diagnostics ci-haut fonctionnent bien mais que le site web ou le courriel sont toujours non-disponible, il est possible qu'un filtre existe entre vous et le site en question. C'est généralement le courriel qui est bloqué de cette façon, mais différents réseaux vont avoir différentes politiques régissant le traffic permis. De plus, certains endroits du réseaux peuvent être non-joignables de différentes façons.

Donc, en bref, même si le DNS (du UDP) et l'IP fonctionnent, il est possible que le courriel ou le web (du TCP) ne fonctionnent pas.

Il est possible de tester si un "port" (web ou email) est ouvert avec la commande "telnet" ou "netcat".

Exemple d'un port web ouvert

anarcat@mumia [~]$ telnet koumbit.net 80
Trying 199.58.80.33...
Connected to koumbit.net (199.58.80.33).
Escape character is '^]'.
^]
telnet> quit
Connection closed.

Notez que le por 80 est le port normal pour le traffic web (HTTP). Notez également la méthode pour sortir de telnet: control-] (crochet droite, qui nous amène dans l'invite de commande de telnet) puis quit.

Exemple d'un port fermé:

anarcat@mumia [~]$ telnet voice.koumbit.net 80
Trying 199.58.80.102...
telnet: connect to address 199.58.80.102: Connection refused

Le serveur ci-haut est en fait un serveur de téléphonie et n'a que faire du traffic web.

Quelques ports intéressants

FTP: 21 - transfer de fichiers, mais ouvre plein d'autres ports
SSH: 22 - invites de commandes, transfers de fichiers
HTTP: 80 - web
HTTPS: 443 - web sécurisé
SMTP: 25 - courriel général, souvent filtré
Submission: 587 - pour soumettre des courriels à votre fournisseur si le 25 est fermé
IMAP: 143 - pour aller chercher ses courriels
IMAPS: 993 - IMAP sécurisé, recommandé

L'index des services est généralement dans le fichier /etc/services sur toute platforme UNIX. Il est également possible d'utiliser les noms symboliques (smtp ou http) au lieu des ports numériques, mais ils sont parfois plus longs à taper.

Diagnostics intermédiaires

Une fois que nous nous sommes assurés d'un lien réseau minimal, il peut ensuite tester différents paramètres du lien réseau.

Fiabilité

La commande ping permet également de tester la qualité du lien. Plusieurs métriques sont disponibles mais on parle ici de la capacité du lien à transmettre de façon fiable tous les "paquets" transmis. Un bon lien ne perdra aucun paquet. Certains liens, particulièrement les liens sans fil, perdront un peu de paquets (1-5%). Certains liens surchargés pourront perdre plus de paquets (20-50%). À partir de ce moment, la dégradation de performance est devenue à ce point intolérable qu'on peut considérer le lien comme carrément non-fonctionnel.

Exemple, lien parfait

anarcat@mumia [~]$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.052 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.043 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.028 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.041 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_seq=9 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=10 ttl=64 time=0.044 ms
^C
--- localhost ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.028/0.038/0.052/0.009 ms

Exemple, lien endommagé

--- shell.koumbit.net ping statistics ---
5474 packets transmitted, 5158 received, 5% packet loss, time 5486047ms
rtt min/avg/max/mdev = 43.845/59.481/348.934/22.980 ms

Il importe de diagnostiquer où se trouve le problème avant de se précipiter à appliquer une solution. La fiabilité peut varier d'un site à un autre. Il faut alors utiliser un autre outil pour découvrir à quel niveau (hop) se trouve le problème. mtr est un tel outil, mais traceroute peut également faire pour ceux qui n'ont pas mtr de disponible.

Latence

PING donne déjà des statistiques de latence lorsqu'il se termine. Examinons plus en détails ces résultats:

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 47.567/55.088/61.264/5.678 ms

La métrique la plus important ici est la seconde (avg) qui indique le temps moyen de retour des paquets (RTT, round-trip time) qui est ici de 55ms, un temps bien acceptable pour un lien ADSL. On remarque aussi le minimum et maximum rencontrés durant le test (min et max), respectivement 47 et 61ms, encore une fois acceptables. Dépendemment des conditions réseau, les maxima et mimima peuvent fluctuer de façon significative et donc affecter la performance.

Une fois qu'un problème de latence est diagnostiqué, il faut encore identifier l'endroit où il se trouve. Il faut donc un autre outil.

Traceroute

Traceroute permet d'examiner le chemin entre vous et le serveur à inspecter. Il peut également donner des information sur la latence entre le point de départ et chacun des points du parcours.

anarcat@mumia [~]$ traceroute.db 4.2.2.1
traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 40 byte packets
 1  roadkill.anarcat.ath.cx (192.168.0.1)  4.343 ms  4.424 ms  4.534 ms
 2  H6.C31.B96.tor.eicat.ca (66.96.31.6)  43.402 ms  44.335 ms  46.838 ms
 3  vulture.eicat.ca (66.96.16.12)  51.436 ms  52.954 ms  55.459 ms
 4  gw-wvfiber.torontointernetxchange.net (198.32.245.110)  70.634 ms  73.213 ms  79.271 ms
 5  sl-gw35-nyc-3-0-0.sprintlink.net (144.232.168.145)  80.115 ms  80.762 ms  80.981 ms
 6  sl-crs1-nyc-0-10-2-0.sprintlink.net (144.232.13.36)  83.466 ms  65.792 ms  67.821 ms
 7  te-4-2-0.edge1.NewYork1.level3.net (4.68.111.157)  68.644 ms  58.388 ms  61.756 ms
 8  vlan79.csw2.NewYork1.Level3.net (4.68.16.126)  62.786 ms vlan69.csw1.NewYork1.Level3.net (4.68.16.62)  56.140 ms  57.151 ms
 9  ge-2-0.core1.NewYork1.Level3.net (4.68.97.8)  59.853 ms ge-5-0.core1.NewYork1.Level3.net (4.68.97.40)  44.575 ms ge-2-0.core1.NewYork1.Level3.net (4.68.97.8)  45.527 ms
10  vnsc-pri.sys.gtei.net (4.2.2.1)  44.600 ms  43.670 ms  61.952 ms

On remarque ici les faits suivants:

roadkill est la passerelle sur le réseau local et donc a une faible latence (4ms)
le point suivant est la passerelle du fournisseur d'accès, on voit donc que le lien "haute vitesse" ajoute une latence de 40ms, environ
les autres points sont tous "sur internet" et ajoute un peu de latence, mais somme toute très peu car la latence finale du point de destination reste proche de la latence locale et celle du lien (40 + 4 = 44ms).¹

traceroute peut donner beaucoup de diagnostics sur différents problèmes et est donc très utile pour diagnostiquer différent problèmes réseaux.

Smokeping

We are are using Smokeping to monitor ping times from various locations, see SmokePing and LookingGlass.

outil web

http://just-traceroute.com/

Débit

Afin de tester le débit d'un site, il est parfois possible d'essayer le téléchargement d'un gros fichier en HTTP ou (préférablement, car l'overhead est moindre) en FTP, voire même directement en IP.

Exemple de fichiers de tests:

http://iweb.com/about-us/networks/
chez koumbit: http://test.koumbit.net/

Des outils comme iPerf et netcat avec pv peuvent ensuite tester la connectivité entre deux points en protocoles purement UDP ou TCP.

Netcat

Avec netcat (nc) sur la première machine (ici 192.168.1.3 avec le port 3333), lancez un serveur dont la sortie sera mesurée par pv (pipeviewer):

netcat -l -p 3333 | pv

puis connectez vous sur une 2e machine:

dd if=/dev/zero | nc 192.168.1.3 3333

la première machine devrait afficher quelque chose comme ceci, indiquant les performances du transfer:

280MB 0:00:19 [17.6MB/s] [                 <=>                               ]

iPerf

Une alternative plus intégrée à cette solution est d'utiliser iperf d'une façon similaire:

Première machine:

iperf -s

Deuxième machine:

iperf -d -c 192.168.1.3 -t 60

Ce qui va donner un test bidirectionnel avec un résultat sur chaque machine ressemblant à ceci:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.3 port 5001 connected with 192.168.1.1 port 44335
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec    243 MBytes    202 Mbits/sec

Le test par défaut dure 10 secondes. C'est un peu court pour avoir une bonne idée de la stabilité de transfert, donc avec -t 60 on demande à iperf de transmettre pendant une minute. On peut augmenter la valeur de -t aussi pour pouvoir tweaker certaines configurations pendant que ça roule et voir les effets live. Pour ça on veut probablement ajouter -i 1 pour avoir un rapport de vitesse à chaque seconde)

Test UDP:

iperf -c  199.58.80.1 -u -b 100M

Le -b 100M est important sinon le UDP est cappé à 1mbps.

Test DDOS:

iperf -c  199.58.80.1 -u -b 1000M -P 50 -t 30

50 threads en parallèle... ça segfault dans mes tests.

Tests en ligne

Le classique pour faire ces tests est le site Speedtest.net. Il est également possible de l'utiliser en ligne de commande avec:

apt-get install speedtest-cli

Le site SpeedOf.Me offre pour sa part une version HTML5 similaire, sans flash!

Autres outils

La commande iftop permet aussi d'examiner le débit généré ou reçu par une machine. bwm-ng est aussi pratique pour ça quoique iptraf est beaucoup plus évolué et "performant". (Sous FreeBSD, utiliser trafshow.) Ces solutions sont utile afin d'examiner du vrai traffique réseau actif plutôt que de générer nous même du traffic pour tester les liens.

Finalement, il est possible de carrément "flooder" en UDP pour stress-tester un réseau, voir http://www.linuxscrew.com/files/udp_flood.txt.

Diagnostics avancés

Spike réseau

Symptôme

spike réseau détecté par le système de monitoring:

16:15:37 <knag> sw3-canix2.koumbit.net (Netel uplink) PROBLEM #3 HARD 0.096s 0.027s CRITICAL - Current BW in: 60.93Mbps Out: 66.09Mbps in=60.937465Mb/s;10240;15120 out=66.090423Mb/s;10240;15120

Démarche

1. vérifier dans le WeatherMap quel serveur utilise la bande passante

Les graphiques ci-bas ont été fait avec MRTG au lieu de Munin, qui est présentement utilisé pour le WeatherMap - mais le concept reste le même.
on voit tout de suite le spike sur le graphique "upstream":
b. en descendant dans la page, on retrouve un spike similaire sur homere:
à noter que ces graphiques ont été croqués le lendemain de l'opération et le spike est donc plus évident
se connecter sur homere
lancer iftop pour trouver quel client utilise la bande passante. on découvre une seule IP qui tire beaucoup (1mbps) de bande passante sur le port www
faire un grep pour l'ip dans /var/log/apache/access.log. on découvre le domaine responsable.
dans ce cas-ci, on a simplement ouvert un billet pour garder un oeil sur la facturation du client (26251)

Objectif

s'assurer que nous ne dépassons pas notre quota (au 95ePercentile)

DDOS

Voir la page DDOS pour ce cas spécifique d'attaque.

"Sniffing" et dissecation bas niveau

Outils utiles:

wireshark - outil générique de dissécation de packet
tcpick - pour lire le contenu des connexions TCP telles que le HTTP, très utile pour diagnostiquer applicatifs en backend

Traffic shaping et VoIP

Le VoIP demande une qualité de ligne exceptionnelle, tant en terme de latence que de "packet loss". Il peut être difficile de diagnostiquer des problèmes audio dans les appels téléphoniques (prendre par exemple 13136) et plusieurs outils peuvent aider au diagnostic.

Les problèmes de qualité sont la plupart du temps liés à des problèmes de congestion réseau. Un "traffic shaper" peut être utilisé pour tenter de résoudre ce problème, mais il est important de comprendre que le traffic shaper n'a effet que sur les paquets sortants de son interface. Par exemple, au bureau, nous utilisons PF pour le traffic shaping, et il priorise le traffic uploadé vers l'internet (1.5mbps). Le traffic entrant (10mbps de bandwidth) n'est pas régulé car quand il arrive sur PF, il est déjà trop tard pour prioriser.

Trois outils très important peuvent être utilisés pour diagnostiquer les problèmes:

oping
pftop
bmon
iftop

On roule les tests avec plusieurs appels simultanés. On peut, par exemple, faire un appel de 5 postes fixes au bureau vers la même conférence. Idéalement, une musique en attente est ajoutée à la conférence (avec le bouton "conf" d'un des postes) pour s'assurer d'avoir un exemple audible de problèmes avec la qualité de l'appel.

oping

oping est utilisé pour créer un "mini-smokeping", un diagnostic très rapide de où se trouve la latence. Exemple:

$ noping -i 0,2 -c 100 rtr  216.113.126.6 koumbit.net voice0.koumbit.net
56 bytes from rtr6.office.koumbit.net (192.168.20.1): icmp_seq=97 ttl=64 time=0,11 ms
56 bytes from 216.113.126.6 (216.113.126.6): icmp_seq=97 ttl=252 time=11,25 ms
56 bytes from koumbit.net (209.44.112.66): icmp_seq=97 ttl=57 time=12,95 ms
56 bytes from voice0.koumbit.net (199.58.80.102): icmp_seq=97 ttl=57 time=17,93 ms
56 bytes from rtr6.office.koumbit.net (192.168.20.1): icmp_seq=98 ttl=64 time=0,16 ms
56 bytes from 216.113.126.6 (216.113.126.6): icmp_seq=98 ttl=252 time=10,09 ms
56 bytes from koumbit.net (209.44.112.66): icmp_seq=98 ttl=57 time=12,77 ms
56 bytes from voice0.koumbit.net (199.58.80.102): icmp_seq=98 ttl=57 time=17,14 ms
56 bytes from rtr6.office.koumbit.net (192.168.20.1): icmp_seq=99 ttl=64 time=0,14 ms
56 bytes from 216.113.126.6 (216.113.126.6): icmp_seq=99 ttl=252 time=10,54 ms
56 bytes from koumbit.net (209.44.112.66): icmp_seq=99 ttl=57 time=12,57 ms
56 bytes from voice0.koumbit.net (199.58.80.102): icmp_seq=99 ttl=57 time=16,58 ms

┌──── rtr6.office.koumbit.net ping statistics ────────────────────────────────────────────────────────────────────────┐
│ 99 packets transmitted, 99 received, 0,00% packet loss, time 13,1ms                                                 │
│ rtt min/avg/max/sdev = 0,096/0,132/0,295/0,029 ms                                                                   │
│ ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁                 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌──── 216.113.126.6 ping statistics ──────────────────────────────────────────────────────────────────────────────────┐
│ 99 packets transmitted, 99 received, 0,00% packet loss, time 2557,7ms                                               │
│ rtt min/avg/max/sdev = 6,937/25,836/76,440/20,693 ms                                                                │
│ ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▇▃▄▆▆▂▃▃▃▃▃▃▃▃▄▄▄▄▄▄▄▄▄▄▄▄▄▅▃▅▅▅▅▅▅▆▅▄▅▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁                 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌──── koumbit.net ping statistics ────────────────────────────────────────────────────────────────────────────────────┐
│ 99 packets transmitted, 99 received, 0,00% packet loss, time 2767,8ms                                               │
│ rtt min/avg/max/sdev = 11,252/27,957/76,859/19,059 ms                                                               │
│ ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▇▃▄▅▆▂▃▃▃▃▃▄▃▃▄▄▄▄▄▄▄▄▄▄▄▄▄▅▃▅▅▅▅▅▅▆▅▄▅▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁▁▁▁▁▁▁▁                 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌──── voice0.koumbit.net ping statistics ─────────────────────────────────────────────────────────────────────────────┐
│ 99 packets transmitted, 99 received, 0,00% packet loss, time 3012,8ms                                               │
│ rtt min/avg/max/sdev = 11,879/30,432/76,955/17,437 ms                                                               │
│ ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▇▃▄▅▆▂▃▃▃▃▃▄▃▃▄▄▄▄▄▄▄▄▄▄▄▅▄▅▃▅▅▅▅▅▅▆▅▄▅▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂▁▁▁▁▁▁▁▁▁▁▁▁▁                 │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

--- rtr6.office.koumbit.net ping statistics ---
100 packets transmitted, 100 received, 0,00% packet loss, time 13,2ms
rtt min/avg/max/sdev = 0,096/0,132/0,295/0,029 ms

--- 216.113.126.6 ping statistics ---
100 packets transmitted, 100 received, 0,00% packet loss, time 2567,5ms
rtt min/avg/max/sdev = 6,937/25,675/76,440/20,650 ms

--- koumbit.net ping statistics ---
100 packets transmitted, 100 received, 0,00% packet loss, time 2781,7ms
rtt min/avg/max/sdev = 11,252/27,817/76,859/19,014 ms

--- voice0.koumbit.net ping statistics ---
100 packets transmitted, 100 received, 0,00% packet loss, time 3031,0ms
rtt min/avg/max/sdev = 11,879/30,310/76,955/17,391 ms

On voit ci-haut une capture d'écran du terminal où oping est appelé (notez la commande, noping qui donne également une version graphique depuis 1.6.2-2). Ce terminal est mis à jour très rapidement (5 fois par seconde) ce qui permet d'avoir du feedback rapide quand il y a un problème, car les coupures se passent souvent en moins d'une seconde. En fait, on pense souvent que l'oreille humaine peut détecter les problèmes de perte de signal et de latence après environ 50 milisecondes.

On voit, par exemple, dans le graphique ci-haut, que la latence a augmenté significativement durant le test, jusqu'à 80 milisecondes. Ceci a été simulé par le téléchargement d'un fichier de test de 10 Mio. À noter également que ce téléchargement n'a pas affecté la qualité des appels téléphoniques grâce au traffic shaper.

En somme, on peut utiliser oping pour établir une corrélation entre la latence et la qualité des appels, et identifier où la latence se trouve (au centre de données, au bureau, etc). Le choix des cibles du ping multiple est donc critique.

pftop

pftop permet, sur le router FreeBSD, d'examiner les files d'attente du traffic shaper. Exemple:

rtr6# pftop -s 1 -v queue
pfTop: Up Queue 1-9/9, View: queue, Cache: 10000                                                               13:57:00

QUEUE                             BW SCH  PRIO     PKTS    BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN     P/S     B/S
root_em1                       1500K hfsc    0        0        0        0        0    0                     0       0
 voip                           450K hfsc    7    96105 19661996      819   166570    0                   200   41200
 ack                            300K hfsc    6     5598   385919        0        0    0                    10     815
 ssh                            300K hfsc    5        0        0        0        0    0                     0       0
  ssh_interactive               150K hfsc    5      133    10362        0        0    0                     0       0
  ssh_bulk                      150K hfsc    3       59    13958        0        0    0                     0       0
 other                          300K hfsc    4    15682  1934879       67    19672    0                   250   17771
 bulk                          75000 hfsc    3     7869  1042287       21    27636    0                    27    3204
 bittorrent                    75000 hfsc    2       53     4858        0        0    0                     0       0

On voit ici que la file voip a 200 packets par secondes et ~40Ko/s de traffic. C'était un test à 3 appels simultanés, si ma mémoire est bonne. On voit également que la file a "droppé" 819 packets - chaque packet droppé provoque une perte de signal, un silence pour l'utilisateur.

Il n'est pas toujours évident de retracer la source de ces packet drop. On peut tenter de prioriser autrement les files, par exemple ici, nous avons considéré que la file "ack" avait trop haute priorité et avons réorganisé le traffic comme suit:

pfTop: Up Queue 1-9/9, View: queue, Cache: 10000                                                               16:33:44

QUEUE                             BW SCH  PRIO     PKTS    BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN     P/S     B/S
root_em1                       1500K hfsc    0        0        0        0        0    0                     0       0
 voip                           450K hfsc    7   345340 70616707      514   105006    0                     0       0
 ack                            150K hfsc    4    69373  5678959       23     2944    0                    11    1448
 ssh                            300K hfsc    5        0        0        0        0    0                     0       0
  ssh_interactive               150K hfsc    5     3425   236794        0        0    0                     0       0
  ssh_bulk                      150K hfsc    3     2668   351145        0        0    0                     0       0
 other                          150K hfsc    4   355489 54141411      434   102195    0                    13    1365
 bulk                          75000 hfsc    3    42120 12242755      644   823770    0                     0       0
 bittorrent                    75000 hfsc    2      725    75198        0        0    0                     0       0

On voit ainsi que, malgré le traffic plus élevé (345340 vs 96105 packets), moins de packets ont été échappés par le traffic shaper après cette configuration.

En somme, avoir un terminal qui surveille la sortie de pftop permet rapidement de voir si le problème se trouve sur le routeur ou sur la connexion réseau, comme c'était le cas dans le ticket 13275.

bmon

bmon permet d'avoir des statistiques live sur la transmission et réception en terme de bandwidth et aussi nombre de paquets par seconde. Il produit aussi des graphes pour la bandwidth et les paquets par seconde. C'est un outil vraiment rapide aussi.

Par contre, c'est un outil qui ne permet pas d'identifier le transfert pour chaque connexion, dans le but d'identifier qui transfert combien de trafic. C'est plus un outil haut niveau qui permet d'avoir rapidement une bonne vue d'ensemble sur ce qui passe par les interfaces réseau.

 igb0                                                                                                                                                            bmon 3.3 
Interfaces                     │ RX bps       pps     %│ TX bps       pps     %                                                                                           
 +igb0                         │ 149.85Mb   23.72K     │  46.37Mb   14.63K
  igb1                         │  13.05Mb    9.27K     │  77.04Mb   12.69K
  vlan141                      │  15.38Mb    2.17K     │   7.63Mb    1.96K
  vlan60                       │  69.19Mb   11.94K     │  13.87Mb    8.81K
───────────────────────────────┴───────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
      Mb                      (RX Bytes/second)                                            Mb                      (TX Bytes/second)
  242.47 ...............|.......................|..........|....|....                  161.47 ..........................................................|.
  202.06 .........|...|.|......|.....||.........|....|.||..|....|..|.                  134.56 ..........................................................|.
  161.65 ||||||...||..||||.|||||||.|.||...|...||||||||.|||.||||||||||                  107.65 ..........................................................|.
  121.24 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   80.74 ..........................................................|.
   80.82 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   53.82 |.||||||||||||.|||||||||.||.|..||..||||||||||||||||.|..||.||
   40.41 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   26.91 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
         1   5   10   15   20   25   30   35   40   45   50   55   60                         1   5   10   15   20   25   30   35   40   45   50   55   60
       K                     (RX Packets/second)                                            K                     (TX Packets/second)
   30.63 ...............|......|................|....|.|...|....|..|.                   25.95 ..........................................................|.
   25.53 |||||||..||..||||.|||||||.|.||.......||||||||||||.|||||||||.                   21.63 ............................................|||...........|.
   20.42 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   17.30 ..|||.|..|..||.|.||||||..................|||||||..|.......|.
   15.32 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   12.98 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   10.21 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                    8.65 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
    5.11 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                    4.33 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
         1   5   10   15   20   25   30   35   40   45   50   55   60                         1   5   10   15   20   25   30   35   40   45   50   55   60

Un truc qui peut être utile dans l'interface: appuyer sur Tab change le temps de moyenne pour les colonnes des graphes entre seconde, minute, heure, et jour.

iftop

Nous avons déjà mentionné iftop, mais rappelons que iftop permet d'identifier le traffic qui sature la connexion réseau. Peu importe les modifications apportées au traffic shaper, tant que réseau est saturé, la qualité des communications en temps réel va se dégrader. Il s'agit alors d'identifier, selon les mécanismes mentionnés plus haut, quels protocoles, stations de travail ou services provoquent une surcharge du réseau.

Dans le cas d'école (13275), il s'agissait d'un cronjob qui roulait de façon simultanée sur toutes les machines du bureau (MonkeySphere). Mais il pourrait également s'agir d'un téléchargement de fichier inopiné (e.g. un "torrent" laissé ouvert...).

À faire

... filtrage, proxying, MTU, etc..

Retrouver une adresse MAC à travers nos serveurs

Si jamais on a un conflit d'adresses MAC, on peut chercher les deux adresses MAC sur les switches pour trouver c'est quelle machine qui envoie ça.

Voir: HP/Procurve2510#Searching_a_host_per_MAC_address

Sommaire des outils présentés

ping: tests de connectivité, latence et qualité du lien
traceroute: découverte de chemin, latence, qualité du lien
mtr: qualité du lien, chemin, patterns de qualité
bwm-ng: inspection du débit et erreurs en local
iptraf: inspection du débit, erreurs, protocoles en local
trafshow: un peu comme iptraf, mais sous FreeBSD
iftop: débits par protocole et adresse, peut être trop lent lors des attaques sur le routeur
netcat: "swiss army knife" des protocoles TCP et UDP, tests de débits et transfer de données arbitraires
iPerf: tests de débits
pv: pipe-viewer, pas vraiment un outil de test réseau mais, combiné avec netcat, permet de mesurer le débit réseau
oping: test de latence avec graphiques avancés

Tests automatisés de réseau

Dans l'optique de se diriger de plus en plus vers une "Infrastructure en Code", on veut utiliser des outils pour permettre de lancer des tests/diagnostiques de réseau automatisés. Ces outils là devraient pouvoir être utilisés via une suite de tests qui roulerait sur notre outil d'Intégration Continue (jenkins en ce moment).

https://scapy.net/ - Librairie Python qui permet de générer des paquets réseau
- Permet d'avoir un script qui roule un test réseau bien précis
- présentement très populaire dans le domaine de la sécurité informatique, donc beaucoup d'utilisatrices.teurs.
- permet de vérifier la réponse obtenue
- permet de forger des paquets (pour tester des cas de trafic réseau invalide, ou des cas de sécurité sur le réseau)
- avantage: C'est une librairie qu'on utilise pour scripter le flux réseau. Donc ça permet de facilement réutiliser un test et en créer d'autres en modifiant les instructions.
- avantage: pas besoin d'un "serveur" qui envoie les requêtes pour nous.
https://packetsender.com/ - Outil avec API et interface CLI qui permet de définir des paquets réseau à envoyer et recevoir. On peut donc mécaniser les envois et vérifier la réponse obtenue.
- Un package debian vient (2020-06) d'être créé et existe dans "unstable".
- Si ça fonctionne bien, ça pourrait être utilisé pour tout genre de test réseau!
- gros avantage de cet outil là: tout cas de test qu'on roule avec ça peut être scripté et automatisé. donc facilement réutilisable et peut être recréé en modifiant le script qui fait appel à packetsender.
Une autre possibilité, c'est de pré-enregistrer un fichier .pcap qui contient un certain flux de paquets réseau qu'on veut répliquer. On peut créer ce fichier là à l'aide de tcpdump et wireshark.
- Pas certain comment vérifier que les réponses sont ce à quoi on s'attend.
- pourrait être utile pour vérifier que certains paquets passent par le firewall et le routage
- On pourrait se service de cette méthode là pour avoir des scénarios de DDoS que les sysadmins pourraient faire rejouer dans une série de VMs locales pour se pratiquer à répondre à ce genre d'urgence là.
- problématique de cette approche là: la création d'un fichier .pcap pour un test ne peut pas vraiment être facilement réplicable

CategoryDebug CategoryOptimisation

On pourrait expliquer les latences observées sur les points intermédiaires par la théorie suivante: les routeurs intermédiaires doivent être occuppés à passer le vrai traffic au lieu de répondre aux questions. (1)

Wiki

Page

User

Pratiques de diagnostic réseau

Diagnostics de base

Charger une page web

Connectivité générale: commande ping

Adresses de test

Outil web

Connectivité locale: tester la passerelle

Disponibilité DNS

Contourner un problème avec la coupure d'un seul serveur DNS

Disponibilité de port

Quelques ports intéressants

Diagnostics intermédiaires

Fiabilité

Latence

Traceroute

Smokeping

outil web

Débit

Netcat

iPerf

Tests en ligne

Autres outils

Diagnostics avancés

Spike réseau

DDOS

"Sniffing" et dissecation bas niveau

Traffic shaping et VoIP

oping

pftop

bmon

iftop

À faire

Retrouver une adresse MAC à travers nos serveurs

Sommaire des outils présentés

Tests automatisés de réseau