Agenda: exercises-network-metrics-and-analysis-vFR.txt

Définitions des performances du réseau et exercices de mesure.
=========================================================

Notes :
------
* Les commandes précédées de "$" signifient que vous devez exécuter la commande en tant qu'utilisateur général - et non en tant qu'utilisateur root.
* Les commandes précédées de "#" signifient que vous devez travailler en tant qu'utilisateur root.
* Les commandes comportant des lignes de commande plus spécifiques (par exemple "GW-RTR>" ou "mysql>") signifient que vous exécutez des commandes sur des équipements à distance, ou dans un autre programme.
* Si une ligne de commande se termine par "\", ceci signifie que la commande se poursuit sur la ligne suivante et que vous devez la traiter comme une seule ligne.

Exercices Partie I
================

0. Ouvrez une session sur votre PC/machine virtuelle ou ouvrez une fenêtre de terminal en tant qu'utilisateur sysadm :

Remarque : Au cours de ces exercices, si la commande apt-get se plaint que certaines archives sont introuvables, vous devrez peut-être mettre à jour votre base de données des paquets apt. Pour cela, tapez :

      $ sudo apt-get update


Indicateurs de performance du réseau
---------------------------

1. ping
-------

ping est un programme qui envoie des paquets ICMP de demande d'écho à des hôtes cibles et attend une réponse ICMP de la part de ces derniers. Selon le système d'exploitation utilisé, vous pouvez observer des temps d'aller-retour (RTT, Round-Trip Time) minimaux, maximaux ou moyens, et parfois un écart type par rapport à la moyenne des réponses ICMP de l'hôte cible. Pour plus de précisions, voir :

http://en.wikipedia.org/wiki/Ping

Il est généralement déconseillé de bloquer ping.

En partant de ces éléments, essayez d'utiliser Ping de différentes manières :

    $ ping localhost

Appuyez sur ctrl-c pour arrêter le processus. Voici quelques résultats typiques de la commande ci-dessus :

    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.020 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.006 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.006 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.006 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.009 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.007 ms
    ^C
    --- localhost ping statistics ---
    7 packets transmitted, 7 received, 0% packet loss, time 5994ms
    rtt min/avg/max/mdev = 0.006/0.008/0.020/0.005 ms

Question : pourquoi la première réponse ICMP a-t-elle mis 20 ms alors que les autres réponses ont été beaucoup plus rapides ? Il s'agit d'un type de délai. De quelle sorte de délai s'agit-il ?


2. traceroute
-------------

Vous avez peut-être déjà utilisé traceroute par le passé, mais avez-vous vraiment regardé ce qu'il fait ? Si ce n'est pas le cas, lisez ceci :

http://en.wikipedia.org/wiki/Traceroute

Il vous faudra peut-être installer d'abord la commande traceroute. Pour ce faire, tapez :

        $ sudo apt-get install traceroute

Une fois installé, essayez :

        $ traceroute nsrc.org

Ci-dessous un exemple du résultat de traceroute dans nsrc.org (les lignes bouclent en raison de leur longueur):

        traceroute to nsrc.org (128.223.157.19), 64 hops max, 52 byte packets
         1  gw.ws.nsrc.org (10.10.0.254)  1.490 ms  1.069 ms  1.055 ms
         2  192.248.5.2 (192.248.5.2)  2.741 ms  2.450 ms  3.182 ms
         3  192.248.1.126 (192.248.1.126)  2.473 ms  2.497 ms  2.618 ms
         4  mb-t3-01-v4.bb.tein3.net (202.179.249.93)  26.324 ms  28.049 ms  27.403 ms
         5  sg-so-06-v4.bb.tein3.net (202.179.249.81)  103.321 ms  91.072 ms  91.674 ms
         6  jp-pop-sg-v4.bb.tein3.net (202.179.249.50)  168.948 ms  168.712 ms  168.903 ms
         7  tpr5-ge0-0-0-4.jp.apan.net (203.181.248.250)  172.789 ms  170.367 ms  188.689 ms
         8  losa-tokyo-tp2.transpac2.net (192.203.116.145)  579.586 ms  284.736 ms  284.202 ms
         9  abilene-1-lo-jmb-702.lsanca.pacificwave.net (207.231.240.131)  303.736 ms  
            284.884 ms  530.854 ms
        10  vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.082 ms  
            305.800 ms  533.644 ms
        11  vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92)  336.680 ms  617.267 ms  
            495.685 ms
        12  vl-3.uonet2-gw.uoregon.edu (128.223.3.2)  310.552 ms  421.638 ms  612.399 ms
        13  nsrc.org (128.223.157.19)  309.548 ms  612.151 ms  611.505 ms

Comprenez-vous ce que signifie chaque élément ? Si ce n'est pas le cas, consultez la page Wikipedia et tapez

    $ man traceroute

pour plus d'informations. Qu'est-ce que cela signifie si vous voyez des lignes comme celles-ci ?

    15  * * *
    16  * * *
    17  * * *

Ces lignes signifient que le dispositif distant ne répond pas aux demandes d'écho icmp, ou qu'il utilise une adresse de réseau privé (RFC 1918).

Comme vous pouvez le voir, traceroute peut être utilisé pour déterminer où ont lieu les problèmes entre deux points de terminaison d'un réseau. 

Essayez d'exécuter de nouveau traceroute sur le même hôte (nsrc.org). Il faudra probablement beaucoup moins de temps.


3. mtr
------

L'outil mtr associe ping et traceroute en un seul et même affichage mis à jour de manière dynamique. 
Avant d'utiliser mtr, vous devrez peut-être d'abord l'installer :

        $ sudo apt-get install mtr-tiny

Maintenant essayez :

        $ mtr nsrc.org

Le résultat de la commande varie selon les différentes versions de Linux et d'UNIX, mais vous obtiendrez en général un résumé indiquant les paquets perdus sur chaque noeud du chemin jusqu'à l'hôte cible distant, le nombre de paquets ICMP de demande d'écho envoyés, le dernier temps RTT vers l'hôte, le RTT minimal, maximal et moyen ainsi que l'écart type des temps RTT.

L'affichage du pourcentage de paquets perdus dans ce format permet de localiser beaucoup plus facilement les problèmes de réseau.


4. ping avec taille de paquet variable  
---------------------------------

Par défaut, ping envoie des datagrammes IP d'une taille de 84 octets :

* 20 octets d'en-tête IP
* 8 octets d'en-tête ICMP
* 56 octets de remplissage

Vous pouvez cependant envoyer des paquets plus grands avec l'option -s. Avec `-s 1472` vous obtiendrez un datagramme IP de 1500 octets, ce qui est le maximum avant fragmentation pour la plupart des réseaux (MTU = unité de transmission maximale)

Ce mécanisme simple peut être utilisé pour déboguer toutes sortes de problèmes, et permet même de faire la distinction entre les délais de transmission et les délais de propagation.

Choisissez un hôte localisé à quelques sauts de vous. Tapez d'abord :

        $ traceroute nsrc.org

Cherchez maintenant une machine se trouvant à plus de deux sauts et notez son adresse IP. Pourquoi ? Parce qu'un saut correspond à votre routeur virtuel et que cet exercice ne donnera pas de résultats fiables avec un matériel virtuel. Le second saut correspond au routeur de passerelle de notre réseau privé. Il est trop près et la différence en termes de temps de ping sera probablement trop faible pour être utile. Nous allons désigner la machine vers laquelle vous avez choisi d'envoyer un ping en tant que PING_MACHINE.

Envoyez 20 pings standard à cette adresse :

        $ ping -c20 PING_MACHINE

Notez le temps d'aller-retour (RTT) *moyen* relevé (t1).

Envoyez maintenant 20 pings de taille maximale :

        $ ping -c20 -s1472 PING_MACHINE

Notez à nouveau le temps d'aller-retour (RTT) *moyen* relevé (t2).

Le délai de propagation est le même dans les deux cas, par conséquent le temps aller-retour plus long doit être dû au délai de transmission.

Vous pouvez désormais estimer le délai de transmission et donc la bande passante de la liaison entre deux points

    Allongement du temps de transmission   =  t2 - t1
    augmentation du nombre de bits envoyés           =  (1500-84) * 8 * 2  = 22656

(Multipliez par 2 car le temps d'aller-retour implique d'envoyer le paquet deux fois)

Répartissez le nombre de bits par le temps pour obtenir une estimation du débit (bits par seconde). N'oubliez pas de convertir d'abord les millisecondes en secondes.

Exemple :
        
t2 = 1,71
t1 = 1,14

t2-t1 = 0,57

0.57 ms = 0,00057 sec

22656 bits / 0,00057 sec = 39747368,42 bps

Vous pouvez ensuite convertir le résultat en Kbps, Mbps, etc.

En procédant de même pour les sauts suivants, il est possible d'estimer la bande passante sur chaque saut, même les plus éloignés de vous. Il existe un outil, nommé "pathchar", qui fait cela automatiquement, mais vous devez le compiler à partir des fichiers sources. Quelques outils binaires spécifiques au SE sont disponibles à l'adresse :

ftp://ftp.ee.lbl.gov/pathchar/

La page Web comprenant la documentation est accessible à l'adresse suivante :

http://www.caida.org/tools/utilities/others/pathchar/


---------------------------------------------------------------------------


Exercices Partie II
=================

Analyse du réseau
----------------

1. lsof et netstat
-------------------

Vérifiez les services présents sur votre machine. Vous pouvez pour cela vous baser sur la présentation.

Ou voir avec "man lsof", "man netstat", "lsof -h" et "netstat -h" les options disponibles (elles sont nombreuses !). Pensez à utiliser sudo lorsque vous utilisez lsof et netstat afin de vous doter des permissions nécessaires pour tout voir.

Il vous faudra peut-être installer lsof. Pour cela, tapez :

        $ sudo apt-get install lsof

* avec lsof, déterminez les services IPv4 qui écoutent sur votre machine.
* avec netstat, déterminez les services IPv4 et IPv6 qui écoutent sur votre machine.

Lorsque vous exécutez lsof et netstat, vous devez le faire en tant que root :

        $ sudo lsof 
        $ sudo netstat

Rappel : vous devrez spécifier des options pour déterminer les services IPv4 et IPv6 qui s'exécutent sur votre machine.


2. tcpdump et tshark
---------------------

Vous devez d'abord installer ces deux programmes :

        $ sudo apt-get install tcpdump tshark

Utilisez tcpdump comme suit :

        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log

Vous pouvez maintenant initier du trafic sur votre interface de bouclage avec un autre terminal. C'est-à-dire ouvrir une autre session ssh sur votre PC/machine virtuelle.

Par exemple :

        $ ping localhost
        $ ssh localhost
 
etc. Appuyez ensuite sur CTRL-C pour mettre fin à la session tcpdump.

Remarque : ssh donne des résultats beaucoup plus "intéressants". Lisons maintenant avec shark les résultats de tcpdump :

        $ sudo tshark -r /tmp/tcpdump.log | less

Que voyez-vous ? Pouvez-vous suivre la session SSH que vous avez lancée plus haut ?

Nous allons ensuite utiliser ftp. Vous devez d'abord installer un client ftp :

        $ sudo apt-get install ftp

Essayez maintenant ceci :

        $ sudo rm /tmp/tcpdump.log
        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log

Sur un autre terminal :

        $ ftp limestone.uoregon.edu
 
        Connected to limestone.uoregon.edu.
        220 FTP Server ready.
        Name (limestone.uoregon.edu:sysadmin): anonymous
        Password: <anything you want>
        ftp> exit

Mettez fin à la session tcpdump sur l'autre terminal (CTRL-C)  et observez maintenant le contenu du fichier log :

        $ sudo tshark -r /tmp/tcpdump.log | less

Voyez-vous votre mot de passe ? En présence d'un gros trafic sur votre réseau, il se peut que le fichier tcpdump.log soit volumineux. Vous pouvez rechercher votre session FTP en tapant :

        "/FTP"

dans l'écran de résultat. Étant donné que vous avez redirigé le flux de votre commande shark sur la commande "less" avec "/", la recherche de chaînes fonctionne. Appuyez maintenant sur la touche "n" pour "next" (suivant) afin de suivre la session FTP. Vous devriez voir une ligne comportant la chaîne suivante :

        "FTP Request: PASS PasswordYouTypedIn"

Ce type d'outil permet de détecter très facilement des mots de passe cryptés sur des réseaux LAN sans fil.

N'oubliez pas de nettoyer après votre passage :

        $ rm /tmp/tcpdump.log


3. tcpdump partie II
-------------------

Vous pouvez également utiliser tcpdump comme un outil d'investigation informatique en temps réel. Il faudrait plusieurs heures de classe pour traiter totalement tcpdump, mais nous allons commencer avec un autre exemple concret.

Nous allons examiner une requête dhcp partant de votre PC et les réponses qu'elle reçoit.

Connectez-vous d'abord à votre image PC et devenez utilisateur root :

    $ sudo bash
    
Ensuite, nous allons utiliser un utilitaire du nom de "screen" :

    # apt-get install screen
    
Maintenant, exécutez screen :

    # screen
    
À ce stade, vous pouvez avoir plusieurs sessions terminal ouvertes dans une seule fenêtre ssh. Lancez le processus tcpdump d'écoute de requêtes dhcp :

    # tcpdump -s0 -ni eth0 port 67 or port 68

Avec screen, ouvrez maintenant un autre "écran" dans votre fenêtre terminal.

        Faites ctrl-a c
    
Pour comprendre l'action de "-s0", "-n" et "-i", vous pouvez vous référer à la page de manuel tcpdump :

        # man tcpdump
        
Recherchez "-s" en tapant "/" et ensuite "-s", puis appuyez sur ENTRÉE. Appuyez sur "n" pour voir l'occurrence suivante de la chaîne "-s".

Maintenant lancez sur votre machine une requête dhcp portant sur une nouvelle adresse eth0 :

        # dhcpclient
        
Revenez à l'écran précédent pour voir ce qu'affiche tcpdump :

        Appuyez sur "ctrl-a p"          ("p" pour Précédent, "n" pour "next" (suivant) pour faire défiler les écrans)

Vous devriez obtenir un résultat comme celui-ci :

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:03:05.003190 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:4a:5e:68:77, length 300
18:03:05.004349 IP 10.10.0.254.67 > 10.10.0.250.68: BOOTP/DHCP, Reply, length 300

        Pour arrêter la session tcpdump tapez "ctrl-c"

Savez-vous ce que cela signifie ? Pourquoi avons-nous spécifié d'écouter les ports 67 et 68 ? Si vous ouvrez le fichier /etc/services, vous trouverez les définitions suivantes pour les ports 67 et 68

bootps           67/udp     # Bootstrap Protocol Server
bootps           67/tcp     # Bootstrap Protocol Server
bootpc           68/udp     # Bootstrap Protocol Client
bootpc           68/tcp     # Bootstrap Protocol Client

Vous pouvez revenir à l'écran où vous avez exécuté dhcpclient et quittez l'écran si vous le souhaitez :

        ctrl-a-n
        
Puis tapez :

        # exit
        
Si l'utilitaire screen et son fonctionnement vous intéressent, visitez :

        http://www.howtoforge.com/linux_screen

ou posez des questions à votre instructeur.


4. Utilisation d'iperf
--------------

Installez tout d'abord iperf :

        $ sudo apt-get install iperf

Utilisez "man iperf" ou "iperf -h" pour obtenir de l'aide.

Demandez à votre voisin d'exécuter :

        $ iperf -s

Connectez-vous à la machine de votre voisin avec :

        $ iperf -c ipNeighbor

Si vous ne connaissez pas l'adresse IP de la machine de votre voisin, demandez-lui de faire :

        $ ifconfig eth0

et de vous indiquer quelle adresse IP utilise sa machine.

Quel est le débit entre vos machines ? Vous pouvez répéter cet exercice avec n'importe quelle machine distante où iperf est installé et sur laquelle vous avez un compte. C'est un moyen rapide de voir comment se présente la bande passante entre deux points.

Pour arrêter le serveur iperf sur lequel vous avez exécuté "iperf-s", appuyez sur CTRL-c.

Si vous en avez le temps, continuez d'explorer les options iperf. Si vous disposez d'un PC distant fonctionnant sous UNIX ou Linux, vous pouvez essayer d'installer iperf et de tester la connexion entre le laboratoire de l'atelier et votre machine distante.

Autres aspects à explorer...

* Testez TCP dans différentes tailles de fenêtres (-2).

* Vérifiez TCP MSS (-m). Quel en est l'incidence sur le débit ? Qu'entend-on par découverte du MTU d'un chemin ?

* Testez avec deux threads parallèles (-P) et comparez les totaux. Constatez-vous une différence ? Pourquoi ?

* Testez avec différentes tailles de paquets et l'option TCP_NODELAY (-N).