Re: Bridge réseau + fail over
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
Reply to: