1 (09:56:31) semainetech@reunion.auf.org: willy a changé le sujet en : ☞ Le salon de la Semaine Tech ☜ Atelier "Diagnostic réseau" https://wiki.auf.org/wikiteki/Projet/SemaineTech/Ateliers/DiagnosticR%C3%A9seau
2 (10:07:56) willy: svp tout le monde, pour l'atelier qui doit commencer, voulez-vous qu'on le fasse sous forme d'échanges ? chacun présenterait un peu comment il résoud certains problèmes ?
3 (10:08:05) willy: vous pouvez vous exprimer ici ;)
4 (10:09:21) patrick.mwamba: k
5 (10:10:30) willy: ok... en espérant vous réveiller, je vais juste présenter un peu comment je procède pour faire des diagnostics réseau
6 (10:11:00) willy: en relation avec l'atelier d'hier présenté par Moussa sur les outils de supervision
7 (10:11:44) willy: dans le cade du diagnostic réseau, j'utilise assez régulièrement :smokeping, munin (section traffic réseau), tcpdump , tshark et nmap
8 (10:12:53) willy: smokeping je le place à la fois sur un serveur en local et un autre qui soit hors de mon implantation
9 (10:13:29) willy: ça me permet de "m'observer" de temps en temps
10 (10:13:57) ***willy
11 (10:14:31) willy:
12 un exemple de graphe http://www.flickr.com/photos/ongola/5618847752/
13 (10:15:07) progfou: REMARQUE : votre implantation AuF est très certainement déjà dans le SmokePing du BAP et de plusieurs autres implantations, car il y a eu un projet de déploiement général de SmokePing à l'AuF, cf http://www.vn.auf.org/cgi-bin/smokeping.cgi
14 (10:15:39) ***willy
15 (10:16:12) willy: c'est un élément pour vous aider à savoir ce qui se passe
16 (10:16:27) willy: bien sur, des coupures peuvent intervenir à n'importe quel endroit du réseau
17 (10:16:37) willy: et pas forcément chez votre FAI ;)
18 (10:16:51) willy: donc faites attention quand vous leur rapportez un soucis
19 (10:17:33) willy: concernant les problèmes liés à l'internet, avec votre FAI, la discussion tournera souvent autour de savoir "chez qui est le problème?"
20 (10:17:50) willy: à votre niveau, vous devez être sur que rien ne cloche
21 (10:18:08) willy: et c'est là qu'intervient la panoplie d'outils que vous avez
22 (10:18:40) willy: c'est souvent bien d'isoler les réseaux quand vous voulez faire un test
23 (10:19:14) willy: si vous avez un parefeu central (ce qui doit être le cas de tout le monde je crois), vous pouvez faire vos diagnostics depuis ce poste
24 (10:20:15) willy: par exemple avec nmap pour connaitre les postes présents (et qui répondent à vos pings )
25 (10:20:31) willy: nmap -i eth3 -sP 192.168.1.0/24
26 (10:20:55) willy: j'utilise nmap sur l'interface 'eth3'
27 (10:21:16) willy: et je lui demande de me repertériorer les postes du réseau en question
28 (10:21:29) willy: en général tous les postes sous linux répondront
29 (10:21:38) willy: mais pas forcément ceux sous windows
30 (10:21:52) willy: .
31 (10:22:12) ***willy
32 (10:22:52) ***ndimby
33 (10:22:54) progfou: REMARQUE : une fois le modèle Lucid AuF déployé, on peut aussi utiliser un simple ping -b 192.168.1.255 au lieu d'utiliser nmap
34 (10:23:32) willy: ok. merci jc et ndimby
35 (10:23:45) willy: le ping -b est plus simple et mieux en effet
36 (10:24:12) progfou: REMARQUE : la plupart des postes Windows ne répondront pas car par défaut ils ne répondent pas aux requêtes ICMP (ils n'ont jamais été très bon en réseau chez Micro$oft...)
37 (10:24:28) willy: +1
38 (10:25:04) willy: vous avez donc nmap qui permet de trouver plusieurs infos sur les postes du réseau
39 (10:25:33) willy: un autre ... pour ceux qui veulent aller plus loin c'est : nessus . Mais bon, moi nmap me suffit amplement
40 (10:25:56) willy: deux autres outils : tcpdump et tshark
41 (10:26:15) willy: NOTE: tshark est le pendant en mode texte de wireshark
42 (10:26:34) willy: je l'utilise parfois sur les serveurs
43 (10:27:02) willy: je préfère tshark à tcpdump parce qu'il est un peu plus explicite
44 (10:27:47) willy: mais tous les deux font plus ou moins le même travail; ils vous renseignent sur les paquets qui transitent à travers les interfaces réseaux
45 (10:28:15) willy: on peut exclure/inclure en fonction des ports, hôtes, protocoles, etc...
46 (10:28:31) willy: c'est très pratique pour vérifier rapidement quelque chose
47 (10:29:29) willy: d'autres outils que vous utilisez pour vos diagnostics ?
48 (10:29:40) ***willy
49 (10:30:14) progfou: iptraf
50 (10:30:18) ndimby: itop
51 (10:30:25) ndimby: trafshow
52 (10:30:28) progfou: pour savoir rapidement qui prend tout le débit
53 (10:30:46) willy: ah, oui .. j'aime bien iptraf ...
54 (10:31:15) willy: parfois ça me fait sourire quand je vois les chiffres augmenter rapidement et quand je vois un usager se lever... ça chute brusquement :D
55 (10:31:39) ***willy
56 (10:32:11) progfou: sinon mrtg (ou munin), pour avoir un graphique de l'usage de la bande passante dans le temps ; et pour répondre à une question d'hier, cet outil aide aussi à voir si on peut atteindre le débit maximum annoncé par le fournisseur (l'autre technique plus ponctuelle étant d'utiliser bing)
57 (10:33:10) willy: oui, c'est important d'avoir des outils qui font des reports dans le temps
58 (10:33:39) willy: ça vous donne des "arguments" valables si jamais vous vous rendez compte que le problème n'est pas chez vous
59 (10:34:16) progfou: sinon on peut se faire des outils nous-même aussi, cf l'étude que j'avais lancé en 2007, avec un exemple minimal qui marche (suivre le lien /test1) : http://wiki.auf.org/wikiteki/Etude/AnalyseRéseau
60 (10:35:15) khuon.tiv: Bing fait bien le test de débit de liaison, je l'ai utilisé quand notre connexion était LS
61 (10:40:03) ndimby: QUESTION: peut on monitorer qu'un usager dès qu'un usager commence à faire du P2P
62 (10:40:25) ndimby: avant qu'on le ressente la lenteur sur la connexion?
63 (10:40:46) willy: ndimby: tu veux savoir si on peut 'anticiper' l'usage ?
64 (10:41:20) ndimby: qu'on se fasse avertir
65 (10:41:56) franck.kouyami: Anticiper le P2P est difficile à mon avis
66 (10:42:23) franck.kouyami: la plage de ports à surveiller est trop large
67 (10:42:42) progfou: mais si c'est facile à anticiper : il y aura toujours quelqu'un qui va tenter d'en faire ;-)
68 (10:42:51) progfou: c'est très prévisible ;-)
69 (10:43:44) franck.kouyami: en effet, il y a toujours une forte probabilité que quelqu'un en fasse :)
70 (10:44:30) willy: ça me rappelle qu'en général et quand c'est possible , je procède par l'éducation des usagers
71 (10:44:47) thomas.tsimi: j'ai l'impression que tout le monde peut déjà écrire dans ce salon
72 (10:45:13) willy: au lieu d'interdire radicalement et sans avertir les gens (ce qui ne serait pas bien) , je préfère expliquer certains usages qui seraient néfastes à tous
73 (10:45:31) franck.kouyami: d'ou l’intérêt de "bandwithd" qui te donne un apercu des consommations par protocole
74 (10:45:36) willy: bien sur on ne convertit pas tout le monde mais c'est mieux que rien
75 (10:46:15) willy: thomas.tsimi: on procèdera ainsi pour des ateliers qui demandent les avis de tous
76 (10:46:55) progfou: ensuite, si on veut filtrer, je ne connais que 2 méthodes : la plus redoutable mais aussi très fasciste, c'est de tout fermer et de n'ouvrir qu'au compte-goutte et en gardant un œil... et une autre méthode moins garantie (car le P2P ça évolue tout le temps) c'est d'installer un outil de filtrage de type L7 (= Level 7 = 7ème niveau du modèle OSI = reconnaissance des paquets au niveau applicatif)
77 (10:48:22) progfou: mais sinon, je pense que le P2P n'est finalement pas le pire...
78 (10:48:42) willy: par exemple filtrer (un peu) à travers des règles de squid ?
79 (10:48:48) progfou: car tout le monde s'accorde pour dire qu'on peut l'interdire, au moins pendant les heures de travail
80 (10:49:11) progfou: le pire qui arrive (ou même est déjà là) à mon avis, c'est la vidéo en ligne... les YouTube, DailyMotion et autres
81 (10:49:40) progfou: dans un idéal il faudrait que nos liaisons évoluent au rythme des contenus en lignes, mais concrètement ce n'est pas le cas
82 (10:50:25) progfou: et il y a de plus en plus de vidéos _éducatives_ en ligne, donc l'argument de dire qu'on interdit les vidéos est de moins en moins valable
83 (10:51:11) progfou: d'autre part, ça peut passer via le même port que le web, donc la reconnaissance du flux n'est pas toujours évidente
84 (10:51:31) khuon.tiv: Willy: je ne crois pas avec les règles de squid font le P2P ;-)
85 (10:51:31) progfou: effectivement tout faire passer par un proxy aide déjà pas mal
86 (10:52:05) franck.kouyami: J-C : RTSP peut être proxisé ..?
87 (10:52:16) progfou: Khuon, détrompes-toi : Squid a la méthode CONNECT qui autorise une connexion arbitraire (protocole et ports arbitraires)
88 (10:52:18) willy: khuon.tiv: oui, en effet. Je pensais surtout à des gestions autour des URL, types de fichiers par exemple
89 (10:53:06) ***willy
90 (10:53:33) progfou: franck.kouyami, je n'ai pas vérifié (j'ai préféré ouvrir les filtrages pour des destinations connues), mais je pense que oui, à condition de spécifier le proxy dans le client RTSP
91 (10:54:11) progfou: (willy, tu nous arrête si nos discussions t'empêchent de continuer hein... ;-) )
92 (10:54:20) willy: non; ça va..
93 (10:55:05) willy: au contraire.. c'est mieux de discuter ainsi
94 (10:55:47) progfou: willy, tu continue ?
95 (10:55:59) franck.kouyami: Question : Smokeping ca sert à quoi ?
96 (10:56:00) willy: en fait, j'avais pas grand chose à rajouter...
97 (10:56:22) progfou: à faire plein de ping et voir si ça fume ! ;-)
98 (10:56:30) franck.kouyami: latence du réseau, oui, mais utilité pour nous ?
99 (10:56:30) willy:
100 franck.kouyami: le plus simple serait que tu vois ici http://www.vn.auf.org/cgi-bin/smokeping.cgi
101 (10:56:43) franck.kouyami: oki
102 (10:56:49) progfou: je vais détailler un peu
103 (10:58:01) progfou: le principe de SmokePing est d'envoyer régulièrement une série de ping vers des machines choisis, et de faire un graphique montrant les résultats obtenus : les pertes de paquets (couleurs), les ralentissements dans les réponses (fumée)
104 (10:58:37) progfou: donc concrètement ça sert à quoi ? à savoir si le trajet vers une machine est stable (et accessoirement si la machine répond au ping)
105 (10:59:40) progfou: c'est très très utile pour vérifier a posteriori (quand on nous signale un problème après coup) si la cause venait du réseau et si oui de quelle partie (ça se déduit en faisant des smokeping vers des machines à plusieurs étapes différentes du trajet)
106 (11:00:59) franck.kouyami: donc si j'en crois les graphes Cotonou va super mal :D
107 (11:01:18) ***willy
108 (11:01:44) progfou: quand on me dit « coda marchait pas hier à 3h », si je vois un trou dans smokeping vers tous les sites, je sais tout de suite que c'était une coupure de liaison Internet, si je vois un trou seulement sur le graphique de Montréal, je peux en déduire que c'était une coupure plutôt vers chez eux
109 (11:02:42) progfou: pour Cotonou regardes les détails : http://www.vn.auf.org/cgi-bin/smokeping.cgi?target=BAO.Cotonou
110 (11:03:04) progfou: le test est fait sur www.bj.refer.org
111 (11:03:21) progfou: qui ne répond plus au ping depuis début novembre dernier
112 (11:03:42) franck.kouyami: oui ce qui est tout à fait normal en fait
113 (11:04:22) willy: on va clôturer cet atelier
114 (11:04:35) willy: vous pourrez continuer sur tech :)
115 (11:04:49) willy: ---------------- FIN ATELIER : diagnostic réseau -------------