Bonjour,
mon précédent message [1] n'a pas eu le succès que j'escomptais, car bien peu de réponses, et les produits proposés sont vieux, non maintenus, ou leur installation relève du défi...
Je ne blâme ni ceux qui m'ont si gentiment donné leur aide, ni ceux qui ont développé ces softs, car si il n'y a pas d'outils qui correspondent à ma demande, c'est probablement que personne n'en voit l'utilité.
Bref, du coup, et après avoir revu mes intentions à la baisse, je vous livre ce que je cherche à faire :
Notre réseau est constitué de switches dispersés dans tous les étages du bâtiment. C'est typique d'une topologie en étoile.
Je voudrais, sans avoir à passer dans toutes les colonnes sèches, pouvoir d'une façon ou d'une autre savoir quel équipement (PC, imprimante, switch, etc.) est connecté à quelle prise de quel switch. La version graphique, c'était pour mon confort, je l'avoue. L'outil que fournit 3Com avec ses switch [2] est très bien, mais payant, et permet pleins de choses qui me sont inutiles (surveiller des liens, par exemple), et les rapports proposés sont un peu miteux...
Partant de là, je suis presque certain que l'information que je recherche doit pouvoir se récupérer dans la table snmp de chaque switch (MIB). Je voudrais donc un outil (graphique, libre et gratuit) qui me permettrait de naviguer dans la MIB de mes switches pour extirper de cette base l'information qui m'intéresse, et pouvoir éventuellement scripter tout ça pour l'interfacer (pourquoi pas ?) avec glpi et son plugin de cartographie réseau...
J'ai évidement cherché à différents endroits, mais google ne me donne pas de bons résultats, et sourceforge ne me donne que des projets en phase alpha ou ne répondant pas à la question posée.
Évidement, j'ai essayé de récupérer la mib avec un script et essayé de la lire, mais une MIB d'un seul switch fait dans les 20Mo, en texte non compressé, et il faut tout se lire, juste pour trouver n° port, adresse (MAC, IP) associée.... Je pense bien qu'il doit y avoir plus simple, mais ça dépasse mes connaissances...
Alors, d'avance, merci pour votre attention, et pour les liens que vous pourrez me donner.
[1] : http://linuxfr.org/forums/41/22158.html
[2] : http://www.3com.com/products/en_us/detail.jsp?pathtype=purch(...)
Forum général.cherche-logiciel Management réseau...
15
juin
2007
# le truc bete...
Posté par NeoX . Évalué à 3.
sinon, il te faut avec ton client SNMP lui dire de ne relever que les paragraphes qui t'interesse pour l'inclure dans les rapports.
passer un temps je gerais mon serveur comme ca.
le serveur etait emetteur SNMP (avec une multitude de champs et de valeurs possibles)
et mon poste etait client pour generer des stats à partir des infos dispo en SNMP et en allant interroger le serveur de temps en temps.
[^] # Re: le truc bete...
Posté par Gyro Gearllose . Évalué à 2.
Oui, j'ai déjà essayé. Quand je me connecte directement sur chaque switch, que ce soit avec un navigateur ou avec un bête telnet, j'ai l'information, mais c'est loin, très loin même d'être pratique.
D'autant que je ne veux pas générer de stats, mais juste savoir quelle IP/MAC est connectée sur quel port de quel switch. Ensuite, ça devrait m'ouvrir les portes pour réaliser un beau graphique, et pourquoi pas, remplir ou aider à remplir les informations dans glpi.
Ton commentaire m'amène deux questions supplémentaires :
1) tu parles de "mon client snmp", mais je n'en ai pas, à part ce pauvre snmpwalk de php /o\ En aurais-tu un à me conseiller ? Si possible, libre, gratuit ? Peu importe l'OS sur lequel il tourne, je ne suis pas chauvin, et pour l'instant, ce n'est qu'un accessoire pour arriver à mes fins. Le produit fini sera de toutes façons sous linux.
2) Tu parles de "ne relever que les paragraphes qui t'intéressent"... Si je savais lesquels, je n'aurais pas à fouiller toute la MIB... Et ça, je ne le saurais qu'en ayant au préalable résolu le 1)
En tout cas, merci pour ton commentaire, car il m'apporte aussi quelques idées pour la suite ;-) !
[^] # Re: le truc bete...
Posté par ecid . Évalué à 1.
http://www.tembria.com/products/snmpbrowser/download.html
[^] # Re: le truc bete...
Posté par NeoX . Évalué à 1.
si tu veux faire vite, je trouve deux logiciels SNMP dans ma distrib :
mbrowse - a SNMP MIB browser
tkmib - NET SNMP (Simple Network Management Protocol) MIB Browser
et je trouve des lignes de commande
snmp et scli pour aller interroger les agents SNMP.
# Confusion ?
Posté par Barnabé . Évalué à 3.
Une MIB est juste un fichier texte, décrivant un sous-arbre snmp. Une MIB de 20 Mo, c'est assez surprenant....
L'idéal pour toi, ce serait de récupérer la MIB de tes équipements, qui te donnera simplement une correspondance du genre :
1.3.6.1.2.1.1.1 <=> SNMPv2-MIB::sysDescr
Ensuite, tu te sers de cette MIB pour «rendre intelligent» ton client SNMP, (je te conseille tkmib). Tu peux alors explorer les grandeurs (OIDs) retournées par tes équipements, et trouver celles qui t'intéressent.
Une fois que tu as la liste des OIDs à surveiller, un script à base de snmpget, ou bien un environnement plus complexe à base de RRDtool par exemple te donnerait à la demande les infos.
[^] # Re: Confusion ?
Posté par Gyro Gearllose . Évalué à 2.
Donc, si je comprends bien ton propos, un arbre snmp se présente sous une forme clef(numérique)->valeur arborescente, pour laquelle valeur peut également être une clef, etc. Un arbre, quoi.
Et la mib est juste une table de conversion clef (numérique) vers une forme lisible par un être humain.
Ça explique beaucoup de choses. Alors dans ce cas, oui, c'est l'arbre snmp qui fait presque 20Mo, et je n'ai pas la mib de 3com. C'est pour un switch XM3300, je vais tenter de la récupérer chez le fabriquant.
En tout cas, merci pour ces informations qui, même si elles ne m'aident pas, au moins, mettent les points sur les i, et c'est important, car maintenant, je sais de quoi je parle...
[^] # Re: Confusion ?
Posté par Barnabé . Évalué à 3.
Je te suggères de commencer tes recherches ici : http://www.snmplink.org/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.