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 rappelle que tout le monde peut intervenir pour cet atelier dans ce salon
  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 note aussi
  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 continue ou s'arrête :) . A l'impression de parler dans le vide :P
  32 (10:22:52) ***ndimby pense que willy peut continuer
  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 a une question a attente pour tous :)
  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 note por itop et trafshow
  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 rappelle d'ailleurs qu'il y a un atelier sur squid samedi
  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 consulte sa montre
 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 -------------