sich wrote:
Lehmann Guillaume a �crit :
C'est justement gr�ce au spanning-tree que tu es s�r que ce sera
toujours le m�me chemin qui sera pris pour aller d'un switch � un
autre. Je m'�tais inspir� d'un document en anglais (howstuffworks),
que j'ai traduis et remani� un peu pour mes besoins personnels, qui
explique comment cela marche :
http://lehmann.free.fr/Contributions/CoursSwitchs.pdf (regarde le
paragraphe 6 : "Spanning Trees" ainsi que le 7 : "Qu'est-ce que le
switch root ?").
Apparemment le spanning tree devrait pouvoir m'aider. Par contre
concernant le noyau, je pense prendre le dernier noyau 2.4 dont les
sources sont dispo pour la stable. Cela semble correct ou je dois
prendre un 2.4 sur kernel.org voir un 2.6 ? Je pr�sume que le 2.4 de
Debian est suffisant non ? Que pourrais r�ellement m'apporter un 2.6 sur
une machine de ce type ?
Un 2.4 est suffisant. Soit tu prends le dernier de la branche 2.4
(qui est le .26), soit tu prends le 2.4 fourni avec GNU/Debian
qui n'est pas forc�ment le 2.4.26, mais qui contient tout de m�me
les patchs qui font que tu n'auras pas de pb de s�cu.
Le 2.6 est plus jeune donc moins �prouv� que le 2.4, mais semble
(je n'ai pas test� car je suis toujours en 2.4) tout de m�me
utilisable en environnement de prod. Au niveau fonctionnalit�s,
le 2.4 est suffisant.
Est-il possible de coller MRTG l� dessus ? Etant donn� qu'on audit une
interface et que sur un bridge y'a pas d'interface logique...
Si, il y a une interface et c'est br0, br1, ...
Je n'ai pas utilis� MRTG, mais je pense qu'il est possible de lui
dire d'�couter l'interface br0. Au pire, br0 correspond bien �
une interface physique (eth0 ou eth1 ou ...), et donc tu demandes
� MRTG d'�couter sur cette interface et ca devrait �tre bon aussi.
>Et que
pourrais-tu me conseiller comme outil d'audit temps r�el et si possible
dispo par browser. Genre MRTG mais avec des graphes d'activit� par
port.. Aussi un genre d'iptraf mais par browser aussi... Je sais je suis
lourd :)
J'aime bien ntop (www.ntop.org) m�me s'il a quelques probl�mes de
stabilit�, surtout lorsque les d�bits sont importants. Note que
je ne l'ai pas utilis� sur du niveau 2 mais du niveau 3,
cependant je pense fortement qu'il marchera car il me remontait
des infos de niveau 3+ (IP, sessions, protos) _et_ niveau 2
(@MAC). Sinon, je passe g�n�ralement par la mise en place d'un
agent snmp (snmpd) sur la machine et ensuite je fais des requ�tes
snmp (un peu de prog en perl et libsnmp). C'est un peu du
bidouillage, mais c'est plus fun :) Sinon dans le meme style que
mrtg, j'ai entendu parler de cacti qui a l'air simple et bien
pour du monitoring (la palme d'or de la convivialit� revient �
ntop tout de m�me).
Plus basique, surtout au niveau interface, iptraf, etherape, mais
plus pour du temps r�el.
Tant qu'on y'est, des stats des paquets refus�s, stats des machines qui
papotent le plus sur le rzo, etc etc... Tant qu'a poser un linux en
frontal autant s'en servir pour auditer un maximum de choses.
Pour avoir un truc sur mesure, je pr�f�re utiliser snmp, mais des
outils plus simples/tout_en_un exitent. Voir ci-dessus.
Pour ma part, je demandais � pouvoir prendre du temps sur mon temps de
travail pour faire de la doc, ou de la traduction. C'est pas une aide
financi�re, mais c'est une aide tout de m�me. Le test logiciel aussi
est utile par exemple. Enfin, tu es mieux plac� que moi pour savoir ce
qui est possible de demander et ce qui ne l'est pas :)
Guillaume
Bah de la doc (notamment une proc�dure en Fran�ais rassemblant tous
�l�ments du pont) je vais devoir en faire rien que pour ma boite. Et
j'essayerai de les faire complet et clair pour pouvoir les distribuer.
Je serai int�ress� par ton retour d'exp�rience, car je n'ai
jamais mont� une telle architecture (pont fitrant) au-d�l� d'une
simple maquette.
Merci pour tous tes conseils ils me sont tr�s utiles.
De rien :)
Guillaume
