Hmm t’as plutôt intérêt à faire ça avec un port du switch en monitoring/mirroring :) Par définition, le routeur ne voit pas le traffic entre les machines dans le même LAN (ou alors, faut sérieusement t’inquiéter). Le switch est le seul équipement qui voit tout passer (et bien entendu, l’usage de petit switch dans les bureaux à la mode low-cost n’est plus possible). Donc si tes switchs ne savent pas faire ça (c’est assez banal maintenant), faut les changer.
> Le 30 juin 2017 à 19:07, Thin-hinen Hedli <thinhinenhe...@gmail.com> a écrit : > > Pas dans la "conversation publique" mais en échangeant avec une personne > après avoir précisé mes besoins. > En effet, je n'étais pas assez précise sur ma problématique, ce qui peut > sûrement restreindre les solutions proposées, je vais essayer alors de > détailler mon architecture et mes besoins. > > > Mon objectif est de savoir depuis n'importe quel poste ( si possible), ce > que reçoit et envoie un poste X , de savoir quel est le type de flux reçu ( > vidéo ...) et sa source ( dans le cas de la vidéo, quelle adresse ip > multicast, le port ...). Et encore mieux si je peux avoir certaines > statistiques comme le débit du flux( pas primordial). > En plus de cette vision globale au niveau des flux, il me faudrait connaître > l'état ( en cours d'exécution, arrêté ...) de toutes les applications et > services développés par l'entreprise en temps réel sur un poste x depuis un > autre poste y. > Je suis en fait dans le cas d'un LAN totalement fermé où je n'ai pas un point > où convergerait tous les flux. > Mon architecture est telle que schématisée et je voudrais si possible avoir > un "superviseur" branché à un des routeurs et que toutes les infos du trafic > soient envoyées à ce "superviseur-serveur" pour savoir ce qui se passe sur la > machine host sachant que la plupart de son trafic ne passe naturellement pas > par cette machine ni même le routeur (R2) . Est ce que ces solutions > proposées engendrent beaucoup de trafic, peuvent elles être source de > congestion ? > > superviseur > SW + > + + > ++++++++++++++++ > +Routeur R1 + > ++++++++++++++++ > + > + > + > ++++++++++++ > +Routeur R2+ > ++++++++++++ > + + > SW SW > + > + > host > > > Merci pour tous conseils, > > Cdt, > > Thin-Hinen > > > Le 30 juin 2017 à 18:45, David Ponzone <david.ponz...@gmail.com > <mailto:david.ponz...@gmail.com>> a écrit : > Quelqu’un t’avait suggéré ntop pour de la supervision réseau ? > > > > Le 30 juin 2017 à 18:40, Thin-hinen Hedli <thinhinenhe...@gmail.com > > <mailto:thinhinenhe...@gmail.com>> a écrit : > > > > Chère liste, > > > > Je vous remercie pour toutes vos réponses, diverses, cela me permet > > d'aiguiller mes recherches et de découvrir plein d'outils ! > > Je pense être en bonne voie. Avec les nouvelles demandes de mes chefs je me > > réoriente sur ntop. > > > > Je me permettrais de revenir vers vous si besoin, > > Bonne soirée à vous ! > > > > Le 8 juin 2017 à 23:54, Raphael Mazelier <r...@futomaki.net > > <mailto:r...@futomaki.net>> a écrit : > > > >> > >> > >> On 07/06/2017 17:41, Jean-Henri Antunes wrote: > >> > >>> Bonjour a tous, > >>> > >>> ayant débuté sur Nagios, What's UP Gold et un outil maison on a testé un > >>> peu d'autre trucs, Zabbix, Centreon, shinken, puis on est resté sur > >>> Check_mk. > >>> > >>> Check Mk se pose comme bonne alternative... a essayer > >>> y a du graph de l'alerting, on peu y adjoindre nagvis pour des cartes > >>> etc... > >>> > >>> > >>> > >> Oui alors attention check_mk c'est plus un ensemble d'outils qui gravitent > >> autour de nagios plus qu'une solution complète à mon sens. > >> On doit toujours utiliser un core nagios like (nagios, naemon, icinga, > >> shinken, ou meme le core light proposé) pour lancer les checks générés par > >> l'auto discover check_mk. > >> > >> Ceci étant check_mk (que je vois comme un framework de check pour nagios > >> like) est extrêmement intéressant. Je l'ai longtemps utilisé avec succès et > >> plaisir. Livestatus est aussi quasi indispensable à toute gui au dessus de > >> nagios (ou l'alternative dans icinga2). Je suis beaucoup moins convaincu > >> par la gui mulisites. > >> > >> En revanche pour tout ce qui est graphing je ne me passerai plus de > >> grafana (et donc d'une vraie base tsdb graphites, influxdb ou mieux > >> prometheus). Cela demande certes des agents ou exporters divers, un peu de > >> temps de setup mais après c'est un bonheur. > >> > >> Ça c'était pour la partie monitoring/graphing infra/métier quand on a du > >> temps. Pour surveiller rapidement un réseau Obersvium ou LibreNMS font bien > >> le taff, malgré tout le mal que j'en pense. Attention à ne pas avoir des > >> switchs trop sensible aux requêtes snmp (toute série de switchs en deux > >> lettres d'un constructeur commençant par J au pif). > >> > >> > >> > >> > >> -- > >> Raphael Mazelier > >> > >> > >> > >> --------------------------- > >> Liste de diffusion du FRnOG > >> http://www.frnog.org/ <http://www.frnog.org/> > >> > > > > --------------------------- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ <http://www.frnog.org/> > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
