Agenda: 02-fr_exercises-network-metrics-and-analysis.txt

File 02-fr_exercises-network-metrics-and-analysis.txt, 7.5 KB (added by hervey, 8 years ago)
Line 
1surveillance du rŽseau et de gestion
2Exercices de définition et de mesure des performances réseau
3
4Remarques :
5-----------
6* Les commandes précédées de "$" doivent être exécutées en tant qu'utilisateur général et non en tant qu'utilisateur root.
7* Les commandes précédées de "#" nécessitent que vous travailliez en tant qu'utilisateur root.
8* Les commandes incluant des lignes de commande plus spécifiques (telles que "RTR-GW>" ou "mysql>") doivent être exécutées sur un équipement distant ou au sein d'un autre programme.
9* Une ligne de commande se terminant par "\" se poursuit sur la ligne suivante et doit être traitée comme une ligne unique.
10
11Exercices Partie I
12------------------
13
14Mesures de performances du réseau
15---------------------------------
16
171. ping
18   ----
19
20ping 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 voir les délais de propagation (RTT, Round-Trip Time) minimaux, maximaux et moyens, ainsi que parfois les écarts types par rapport à la moyenne des réponses ICMP de l'hôte cible. Voir pour plus de précisions :
21
22        http://en.wikipedia.org/wiki/Ping
23
24Il est généralement déconseillé de bloquer ping.
25
26En partant de ces éléments, essayez d'utiliser Ping de différentes manières :
27
28        $ ping localhost
29
30Appuyez sur ctrl-c pour interrompre le processus. Voici quelques résultats classiques de la commande ci-dessus :
31
32PING localhost (127.0.0.1) 56(84) bytes of data.
3364 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms
3464 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.006 ms
3564 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006 ms
3664 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.006 ms
3764 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.006 ms
3864 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.009 ms
3964 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.007 ms
40^C
41--- localhost ping statistics ---
427 packets transmitted, 7 received, 0% packet loss, time 5994ms
43rtt min/avg/max/mdev = 0.006/0.008/0.020/0.005 ms
44
45Question : 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 ?
46
47Créons de manière artificielle un délai de traitement. Dans une fenêtre de terminal, saisissez la commande suivante :
48
49        $ ping localhost
50
51Dans une autre fenêtre de terminal (sur la même machine), tapez :
52
53        $ cd
54        $ vi cpu.sh
55       
56Ajoutez les lignes suivantes dans ce fichier :
57
58#!/bin/sh
59sh $0
60or in c
61while ( 1 )
62fork();
63
64Enregistrez le fichier et rendez-le exécutable :
65
66        $ chmod a+x cpu.sh
67
68Exécutez maintenant le script de bouclage :
69
70        $ ./cpu.sh
71
72Vous devriez voir les résultats de ping dans votre autre fenêtre commencer à prendre plus de temps. Une fois terminé, appuyez sur ctrl-c dans les deux fenêtres du terminal afin d'interrompre les deux processus.
73
74
752. mtr
76   ---
77
78L'outil mtr associe ping et traceroute en un seul et même affichage mis à jour de manière dynamique.
79Faites un essai :
80
81        $ mtr nsrc.org
82
83Le résultat de la commande looks varie entre les environnements Linux et UNIX, mais vous obtiendrez en général une synthèse des paquets perdus sur chaque noeud du chemin jusqu'à l'hôte cible distant, du nombre de paquets ICMP de demande d'écho envoyés, le dernier délai RTT vers l'hôte, le meilleur, le RTT minimal, maximal et moyen ainsi que les écarts par rapport à la moyenne.
84
85L'affichage du pourcentage de paquets perdus dans ce format permet de localiser beaucoup plus facilement les problèmes de réseau.
86
87
88Exercices Partie II
89-------------------
90
91Analyse du réseau
92-----------------
93
941. lsof et netstat
95   ---------------
96
97Vérifiez les services présents sur votre machine. Vous pouvez pour cela vous baser sur la présentation du réseau.
98
99Ou 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
100nécessaires pour tout voir
101
102* avec lsof : quels sont les services IPv4 qui écoutent votre machine ?
103* avec netstat, quels sont les services IPv4 et IPv6 qui écoutent votre
104machine ?
105
106
1072. tcpdump et tshark
108   -----------------
109
110Pour utiliser tcpdump, vous devez utiliser sudo ou vous connecter en tant que root. Pour utiliser wireshark vous devez ouvrir un terminal et utiliser sudo en tant qu'utilisateur normal (c'est-à-dire avant l'identifiant "tldadmin") :
111
112Utilisez tcpdump comme suit :
113
114        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log
115
116Vous pouvez maintenant initier du trafic sur votre interface avec un autre terminal.
117
118Exemple :
119
120        $ ping localhost
121        $ ssh localhost
122 
123etc. Appuyez ensuite sur CTRL-C pour mettre fin à la session tcpdump.
124
125Remarque : ssh donne des résultats beaucoup plus "intéressants". Lisons maintenant avec shark les résultats de tcpdump :
126
127        $ sudo tshark -r /tmp/tcpdump.log | less
128
129Que voyez-vous ? Pouvez-vous suivre la session SSH initiée plus haut ?
130
131Essayons maintenant ceci :
132
133        $ sudo rm /tmp/tcpdump.log
134        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log
135
136Sur un autre terminal :
137
138        $ ftp limestone.uoregon.edu
139 
140        Connected to limestone.uoregon.edu.
141        220 FTP Server ready.
142        Name (limestone.uoregon.edu:sysadmin): anonymous
143        Password: <anything you want>
144        ftp> exit
145
146Mettez fin à la session tcpdump sur l'autre terminal (CTRL-C) et observez maintenant le contenu du fichier log :
147
148        $ sudo tshark -r /tmp/tcpdump.log | less
149
150Voyez-vous votre mot de passé ? 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 :
151
152        "/FTP"
153
154dans l'écran de résultat. Sachant 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" afin de suivre la session FTP. Vous devriez voir la chaîne suivante :
155
156        "FTP Request: PASS PasswordYouTypedIn"
157
158Ce type de script permet de détecter très facilement des mots de passe cryptés sur des réseaux LAN sans fil.
159
1603. Utilisation d'iperf
161   -------------------
162
163Utilisez "man iperf" ou "iperf -h" pour obtenir de l'aide.
164
165Installez tout d'abord iperf :
166
167        $ sudo apt-get install iperf
168
169Demandez à votre voisin d'exécuter :
170
171        $ iperf -s
172
173Connectez-vous à la machine de votre voisin avec :
174
175        $ iperf -c ipNeighbor
176
177Comment se présente le débit entre vos machines ?
178
179Vous pouvez connecter vos deux PC directement (par un câble sans passer par le commutateur). Utilisez une adresse IP privée sur les deux machines, vérifiez que vous pouvez adresser mutuellement des "ping", puis renouvelez les étapes précédentes avec votre nouvelle connexion. Le débit est-il meilleur ?
180
181Si 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.
182
183Autres aspects à explorer...
184
185* Testez TCP dans différentes tailles de fenêtres (-2).
186
187* Vérifiez TCP MSS (-m). Quel en est l'incidence sur le débit ? Qu'entend-on par
188  découverte du MTU d'un chemin ?
189
190* Testez avec deux fils parallèles (-P) et comparez les totaux. Constatez-vous des différences ? Pourquoi ?
191
192* Testez avec différentes tailles de paquets et l'option TCP_NODELAY (-N).