## page was renamed from Projet/SemaineTech2011/Ateliers/DiagnosticRéseau/Conversation
## page was renamed from Projet/SemaineTech/Ateliers/DiagnosticRéseau/Conversation
{{{#!highlight irc
(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
(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 ?
(10:08:05) willy: vous pouvez vous exprimer ici ;)
(10:09:21) patrick.mwamba: k
(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
(10:11:00) willy: en relation avec l'atelier d'hier présenté par Moussa sur les outils de supervision
(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
(10:12:53) willy: smokeping je le place à la fois sur un serveur en local et un autre qui soit hors de mon implantation
(10:13:29) willy: ça me permet de "m'observer" de temps en temps 
(10:13:57) ***willy rappelle que tout le monde peut intervenir pour cet atelier dans ce salon
(10:14:31) willy: 
un exemple de graphe http://www.flickr.com/photos/ongola/5618847752/
(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
(10:15:39) ***willy note aussi
(10:16:12) willy: c'est un élément pour vous aider à savoir ce qui se passe
(10:16:27) willy: bien sur, des coupures peuvent intervenir à n'importe quel endroit du réseau
(10:16:37) willy: et pas forcément chez votre FAI ;)
(10:16:51) willy: donc faites attention quand vous leur rapportez un soucis
(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?"
(10:17:50) willy: à votre niveau, vous devez être sur que rien ne cloche
(10:18:08) willy: et c'est là qu'intervient la panoplie d'outils que vous avez
(10:18:40) willy: c'est souvent bien d'isoler les réseaux quand vous voulez faire un test
(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
(10:20:15) willy: par exemple avec nmap pour connaitre les postes présents (et qui répondent à vos pings )
(10:20:31) willy: nmap -i eth3 -sP 192.168.1.0/24
(10:20:55) willy: j'utilise nmap sur l'interface 'eth3'
(10:21:16) willy: et je lui demande de me repertériorer les postes du réseau en question
(10:21:29) willy: en général tous les postes sous linux répondront
(10:21:38) willy: mais pas forcément ceux sous windows
(10:21:52) willy: .
(10:22:12) ***willy continue ou s'arrête :) . A l'impression de parler dans le vide :P
(10:22:52) ***ndimby pense que willy peut continuer
(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
(10:23:32) willy: ok. merci jc et ndimby
(10:23:45) willy: le ping -b est plus simple et mieux en effet
(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...)
(10:24:28) willy: +1
(10:25:04) willy: vous avez donc nmap qui permet de trouver plusieurs infos sur les postes du réseau
(10:25:33) willy: un autre ... pour ceux qui veulent aller plus loin c'est : nessus . Mais bon, moi nmap me suffit amplement
(10:25:56) willy: deux autres outils : tcpdump et tshark
(10:26:15) willy: NOTE: tshark est le pendant en mode texte de wireshark
(10:26:34) willy: je l'utilise parfois sur les serveurs
(10:27:02) willy: je préfère tshark à tcpdump parce qu'il est un peu plus explicite
(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
(10:28:15) willy: on peut exclure/inclure en fonction des ports, hôtes, protocoles, etc...
(10:28:31) willy: c'est très pratique pour vérifier rapidement quelque chose
(10:29:29) willy: d'autres outils que vous utilisez pour vos diagnostics ?
(10:29:40) ***willy a une question a attente pour tous :)
(10:30:14) progfou: iptraf
(10:30:18) ndimby: itop
(10:30:25) ndimby: trafshow
(10:30:28) progfou: pour savoir rapidement qui prend tout le débit
(10:30:46) willy: ah, oui .. j'aime bien iptraf ...
(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
(10:31:39) ***willy note por itop et trafshow
(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)
(10:33:10) willy: oui, c'est important d'avoir des outils qui font des reports dans le temps
(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
(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
(10:35:15) khuon.tiv: Bing fait bien le test de débit de liaison, je l'ai utilisé quand notre connexion était LS
(10:40:03) ndimby: QUESTION: peut on monitorer qu'un usager dès qu'un usager commence à faire du P2P
(10:40:25) ndimby: avant qu'on le ressente la lenteur sur la connexion?
(10:40:46) willy: ndimby: tu veux savoir si on peut 'anticiper' l'usage ?
(10:41:20) ndimby: qu'on se fasse avertir 
(10:41:56) franck.kouyami: Anticiper le P2P est difficile à mon avis
(10:42:23) franck.kouyami: la plage de ports à surveiller est trop large 
(10:42:42) progfou: mais si c'est facile à anticiper : il y aura toujours quelqu'un qui va tenter d'en faire ;-)
(10:42:51) progfou: c'est très prévisible ;-)
(10:43:44) franck.kouyami: en effet, il y a toujours une forte probabilité que quelqu'un en fasse :)
(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
(10:44:47) thomas.tsimi: j'ai l'impression que tout le monde peut déjà écrire dans ce salon
(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
(10:45:31) franck.kouyami: d'ou l’intérêt de "bandwithd" qui te donne un apercu des consommations par protocole
(10:45:36) willy: bien sur on ne convertit pas tout le monde mais c'est mieux que rien
(10:46:15) willy: thomas.tsimi: on procèdera ainsi pour des ateliers qui demandent les avis de tous
(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)
(10:48:22) progfou: mais sinon, je pense que le P2P n'est finalement pas le pire...
(10:48:42) willy: par exemple filtrer (un peu) à travers des règles de squid ?
(10:48:48) progfou: car tout le monde s'accorde pour dire qu'on peut l'interdire, au moins pendant les heures de travail
(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
(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
(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
(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
(10:51:31) khuon.tiv: Willy: je ne crois pas avec les règles de squid font le P2P ;-)
(10:51:31) progfou: effectivement tout faire passer par un proxy aide déjà pas mal
(10:52:05) franck.kouyami: J-C : RTSP peut être proxisé ..?
(10:52:16) progfou: Khuon, détrompes-toi : Squid a la méthode CONNECT qui autorise une connexion arbitraire (protocole et ports arbitraires)
(10:52:18) willy: khuon.tiv: oui, en effet. Je pensais surtout à des gestions autour des URL, types de fichiers par exemple
(10:53:06) ***willy rappelle d'ailleurs qu'il y a un atelier sur squid samedi
(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
(10:54:11) progfou: (willy, tu nous arrête si nos discussions t'empêchent de continuer hein... ;-) )
(10:54:20) willy: non; ça va..
(10:55:05) willy: au contraire.. c'est mieux de discuter ainsi
(10:55:47) progfou: willy, tu continue ?
(10:55:59) franck.kouyami: Question : Smokeping ca sert à quoi ?
(10:56:00) willy: en fait, j'avais pas grand chose à rajouter...
(10:56:22) progfou: à faire plein de ping et voir si ça fume ! ;-)
(10:56:30) franck.kouyami: latence du réseau, oui, mais utilité pour nous ?
(10:56:30) willy: 
franck.kouyami: le plus simple serait que tu vois ici http://www.vn.auf.org/cgi-bin/smokeping.cgi
(10:56:43) franck.kouyami: oki
(10:56:49) progfou: je vais détailler un peu
(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)
(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)
(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)
(11:00:59) franck.kouyami: donc si j'en crois les graphes Cotonou va super mal :D
(11:01:18) ***willy consulte sa montre
(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
(11:02:42) progfou: pour Cotonou regardes les détails : http://www.vn.auf.org/cgi-bin/smokeping.cgi?target=BAO.Cotonou
(11:03:04) progfou: le test est fait sur www.bj.refer.org
(11:03:21) progfou: qui ne répond plus au ping depuis début novembre dernier
(11:03:42) franck.kouyami: oui ce qui est tout à fait normal en fait 
(11:04:22) willy: on va clôturer cet atelier
(11:04:35) willy: vous pourrez continuer sur tech :)
(11:04:49) willy: ---------------- FIN ATELIER : diagnostic réseau -------------
}}}