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.

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:

  1. le réseau local n'est pas connecté à internet, ou;
  2. 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.

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:

  1. roadkill est la passerelle sur le réseau local et donc a une faible latence (4ms)
  2. 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
  3. 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).1

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

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:

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 rtr1.koumbit.net ou 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":
    • sw3-canix2.koumbit.net_1-day.png

    b. en descendant dans la page, on retrouve un spike similaire sur homere:
    • sw3-canix2.koumbit.net_14-day.png

  • (!) à 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:

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:

  1. oping

  2. pftop

  3. 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.

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

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).


CategoryDebug CategoryOptimisation

  1. 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)

DiagnosticsRéseau (last edited 2020-06-24 21:59:13 by gabriel)