Sommaire Index Rechercher Liens A Propos

[LinuxFocus Image]
[Navegation Bar]
  Nouvelles   Archives

Gestion et Surveillance
de Réseaux avec Linux: Des outils pratiques pour gérer les réseaux étendus d'aujourd'hui

par David Guerrero

Introduction

Quest ce que SNMP?

Le problème de la sécurité

Qu'est-que le MIB

Quel est l'avenir de SNMP ?

SNMP avec Linux

MRTG: Multi Router Traffic Grapher

Autres Programmes

Conclusions

Cet article est apparu pour la première fois dans le 'linux journal'.
Nous l'éditons avec l'autorisation de l'auteur.

Introduction

Dans le monde actuel, où l'informatique se dirige vers le concept de réseau, le travail des administrateurs systèmes est très complexe. Sa mission consiste à maintenir en fonctionnement des ressources tels que les routeurs, les hubs, les serveurs, ainsi que tout dispositif critique qui compose le réseau.

Il existe un grand nombre de raisons pour lesquelles un administrateur a besoin de monitoriser, entre autres : l'utilisation de la largeur de bande, l'état de fonctionnement des liens, la détection de goulets d'étranglement, détecter et résoudre les problèmes du cablage, administrer le cheminement de l'information entre les machines, etc. La supervision du réseau prend en compte l'étude des problèmes de sécurité.

Dans de nombreux cas, le réseau d'une organisation s'entrelacent avec des liens couteux vers des réseaux étendus (WAN) ou avec internet, lesquels coûts dépendent du volume du trafic. Il est très important de maintenir un registre statistique du trafic d'informations qui circulent par ces liaisons. Cette situation est assez commune en Europe, où les liaisons X.25 sont encore assez courantes. La tarification de ce type de lignes se réalise en fonction du nombre de paquets envoyés et reçus.

Un autre type de liaison, comme le "point à point" (Frame relay), sont en tarif plein. Pour ceux, la compagnie téléphonique doit garantir une largeur de bande, qu'il est important de superviser.

A la fin de cet article, nous présentons un outil qui permet de faire un suivi graphique du trafic des routeurs. Il est facilement configurable pour pouvoir superviser d'autres catégories d'informations du réseau.

Qu'est-ce-que le SNMP ?

La réponse a tous les problèmes exposés précédemment, c'est le protocole Simple Network Management Protocol (SNMP). Elaboré dans les années 80, son principal objectif était d'intégrer la gestion des différents types de réseau au travers d'un outil simple et qui produise peu de surcharge pour le réseau.

SNMP opère au niveau applicatif, en utilisant le protocole de transport TCP/IP, qui ignore les aspects spécifiques du hardware sur lequel il fonctionne. La gestion se réalise au niveau IP, Grâce auquel il peut contrôler les dispositifs qui sont connectés au travers des réseaux accessibles depuis Internet, et pas seulement ceux qui sont connectés sur le réseau local. Evidemment, si un dispositif de routage avec le matériel distant ne fonctionne pas correctement, on ne pourra pas superviser sa reconfiguration.

Le protocole SNMP est composé de deux éléments : l'agent et le gestionnaire (manager). C'est client-serveur, dans laquelle l'agent joue le rôle de serveur et le manager le rôle de client.

L'agent est un programme qui doit s'exécuter sur chaque noeud du réseau qu'on doit superviser. Il offre une interface de tous les éléments qu'il peut configurer. Ces éléments sont stockés dans des structures de données appelées "Management Information Base" (MIB), qu'on décrira plus loin. Elles représentent la partie "serveur", qui contient l'information qu'on souhaite gérer et attendent des commandes de la part du client.

Le gestionnaire est le software qui s'exécute sur la station chargée de superviser le réseau, et son travail consiste à consulter les différents agents qui se trouvent dans les noeuds du réseau, les données qu'ils obtiennent.

Il y a une commande spéciale dans SNMP qui s'appelle trap, qui permet à un agent d'envoyer des données qui n'ont pas été sollicitées de manière explicite par le gestionnaire, pour informer d'événements tels que : erreurs, défaillances du courant électrique...etc

En réalité, SNMP est un protocole très simple, vu que toutes les opérations se réalisent au travers d'un processus de charge et stockage (load and store), ce qui permet un jeu de commandes réduit. Un gestionnaire peut réaliser seulement deux types d'opérations différentes sur un agent : lire ou écrire la valeur d'une variable dans le MIB de l'agent. Ces deux opérations sont connus comme demande de lecture (get-request) et demande d'écriture (set-request). Il existe une commande pour répondre à une demande de lecture qui s'appelle get-response, qui est utilisée uniquement par l'agent.

La possibilité d'ampliation du protocole est directement en relation avec la capacité du MIB de stocker des nouveaux éléments. Si un fabricant souhaite ajouter une nouvelle commande à un dispositif, comme un routeur, il doit seulement ajouter les variables correspondantes dans la base de données (MIB).

Presque tous les fabricants implémentent des versions agents de SNMP dans leurs dispositifs : routeurs, hubs, systèmes opérationnnels, etc. Linux ne fait pas exception, et il existe plusieurs agents SNMP disponibles de manière publique sur Internet.

Le problème de la sécurité

SNMP n'offre pas beaucoup de support pour l'authentification. Il offre seulement un schéma de deux mots-clés (two-passwords). La clef publique permet aux gestionnaires de réaliser des demandes de valeurs de variables, alors que la clef privé permet de réaliser des demandes d'écriture. On appelle ces mots-clés les SNMP communities. Chaque dispositif connecté avec un réseau gestionnaire SNMP doit être configurées avec ces deux "communities".

Il est courant d'assigner par défaut la valeur "public" au community public et "private" au privé. Il est très important de modifier ces valeurs pour protéger le réseau.

Qu'est-que le MIB ?

SNMP définit un standard séparé pour les données gérées par le protocole. Ce standard définit les données maintenues par un dipositif en réseau, ainsi que les opérations qui sont autorisées. Les données sont structurées en arborescence : il y a seulement un chemin entre la racine et la variable. Cette structure arborescente s'appelle Management Information Base (MIB) et on peut trouver des informations sur celle-ci dans divers RFC.

La version actuelle de TCP/IP MIB est la 2 (MIN-II) et elle est définit dans la RFC-1213. L'information est divisée par un dispositif qui maintient 8 catégories (voir ci-après). Toute variable doit se trouver dans une de ces catégories.

Table 1. Information TCP/IP
Categorie Information
interfaces Information des interfaces réseau
addr-translation Information sur les translations d'adresses
ip Information sur le protocole IP
icmp Information sur le protocole ICMP
tcp Information sur le protocole TCP
udp Information sur le protocole UDP
egp Information sur le protocole egp (exterior Gateway)

La définition d'un élément concret MIB implique la specification du type de donnée qu'il peut contenir. Normalement, les éléments du MIB sont des entiers, mais il peut stocker également des chaines de caractères ou des structures plus complexes comme des tables. Les éléments du MIB sont nommés "objets". Les objets sont les noeuds (feuilles) de l'arbre du MIB, si bien qu'un objet peut contenir plus d'une instance, par exemple un objet table. Pour référencer une valeur contenue dans un objet, on doit ajouter le numéro de l'instance. Quand l'objet possède une instance unique, c'est l'instance 0.

Par exemple, l'objet ifNumber de la catégorie "interfaces" est un entier qui représente le nombre d'interfaces présentes dans le dispositif. L'objet ipRoutingTable de la catégorie ip contient la table de routage du dispositif.

Il faut se rappeler qu'il est nécessaire d'utiliser le numéro de l'instance pour lire la valeur d'un objet. Dans ce cas, le nombre d'interfaces présentes dans le routeur peut être observé au moyen de l'instance ifNumber.0.

Dans le cas d'un objet "table", il faut utiliser l'index de la table comme dernier numéro pour spécifier l'instance (liste de la table).

Il existe un autre standard que définit et identifie les variables MIB, appelé "Structure de Management Information" (SMI). SMI spécifie les variables MIB, celles-ci étant déclarées selon un langage formel ISO appelé ASN.1, ce qui entraîne qu'aussi bien la forme comme le contenu des variables sont dénuées de toute ambiguité.

Le champ des nombres ISO (arbre) est situé à l'intérieur d'une autre champ de nombres, joint à d'autres arborescences d'autres standards d'autres organisations. A l'intérieur du champ de nombres ISO se situe un enbranchement spécifique pour l'information MIB. Au sein de cet enbranchement MIB, les objets sont à la fois hierarchisés en sous-enbranchements pour les différents protocoles et applications, de manière que chaque information peut être représentée de façon non équivoque.

La figure 1 montre que le champ nom de l'espace TCP/IP MIB est situé juste sous le champ mgmt name space of thede l' IAB. La hierarchie précise aussi un nombre pour chacun des niveaux.

Figure 1. Organigramme TCP/IP

Il est important de préciser que la plus grande partie du logiciel nécessite le point-racine (.) pour localiser un objet dans la MIB. Si on n'inclut pas ce point-racine, on suppose que le path est relatif depuis .iso.org.dod.internet.mgmt-mib-2.

De cette manière, l'objet ifNumber de la catégorie "interfaces" peut s'appeler :

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber
ou son équivalent numérique :
.1.3.6.1.2.1.2.1
et l'instance est la suivante :
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0
ou son équivalent numérique:
.1.3.6.1.2.1.2.1.0

On peut ajouter des MIB additionnels à cette arborescence conformément à la définition de nouveaux objets par les vendeurs, et leurs publications RFC correspondantes.

Quel est l'avenir de SNMP ?

Une nouvelle spécification dénommée SNMPv2 est actuellement en développement rapide. Cette version essaie de résoudre les lacunes existantes en matière de sécurité du protocole actuel, au moyen de mécanismes qui se recentrent sur la privatisation, l'authentification et le contrôle de l'accés. Il autorisera également un mécanisme complexe de spécifications de variables, ainsi quelques nouvelles commandes. Le problème de SNMPv2 c'est qu'il n'existe actuellement aucun standard largement accepté, à la différence de SNMPv1. Il n'est pas facile de rencontrer des versions de SNMPv2 d'agents ou de software qui utilisent les nouvelles commandes. Il faut laisser passer le temps et nous verrons ce qu'il en adviendra dans le futur proche.

SNMP sur Linux

Un des packages les plus populaires de SNMP est CMU-SNMP. Développé initialement à l'université de Carnegie Mellon, est a été transporté sur Linux par Juergen Schoenwaelder et Erik Schoenfelder. Il est entièrement compatible avec le standard SNMPv1 et inclut quelques fonctionalités de la version SNMPv2.

La distribution contient quelques outils de gestion qui permettent, depuis la ligne de commande, d'envoyer des demandes aux dispositifs qui exécutent les agents SNMP. Il contient également un programme agent SNMP, destiné a s'exécuter sur Linux, qui propose des gestionnaires s'exécutant sur le réseau (ou le système même) : informations sur l'état des interfaces, les tables de routage, instances d'initialisation, information de contact...

Un caractéristique précieuse qui a été ajoutée avec CMU-SNMP est C-API, qui permet aux programmeurs de construire des outils complexes de gestion basés sur les capacités du réseau de la distribution.

L'installation sur un système Linux est simple, quoique légèrement différente de l'installation d'origine. Il existe une distribution avec les exécutables pré-compilés des outils de gestion, le daemon et la bibliothèque API.

La première décision à prendre c'est de savoir si on monte la distribution avec les sources ou avec les exécutables. Il n'est pas difficile de trouver ce package sur Internet. La distribution binaire s'installe et s'exécute sans problème avec les systèmes Linux qui supportent le standard ELF. Nous expliquerons donc comment installer la distribution binaire. C'est de bon usage de charger des distributions binaires uniquement sur des serveurs Internet de confiance pour éviter les chevaux de Troie et autres problèmes de sécurité.

Il faut copier le fichier cmu-snmp-linux-3.4-bin.tar.gz sur le répertoire racine (/), le décompresser avec la commande suivante : Put the file cmu-snmp-linux-3.2-bin.tar.gz in the root directory (/) of your Linux system and decompress it with the command:

gunzip cmu-snmp-linux-3.2-bin.tar.gz

puis extraire les fichiers de l'archive tar avec la commande:

tar xvf cmu-snmp-linux-3.2-bin.tar

Vous devriez avoir alors tous les utilitaires et les bibliothèques correctement installés sur le système, à l'exception du fichier de configuration suivant de l'agent : /etc/snmp.conf. Vous pouvez le créer en exécutant le script suivant :

/tmp/cmu-snmp-linux-3.2/etc/installconf

avec ces paramètres:

/tmp/cmu-snmp-linux-3.2/etc/installconf -mini

où password est le mot-clé public (community) qu'on va utiliser. Maintenant on peut éditer le nouveau fichier de configuration /etc/snmp.conf. On peut y modifier la valeur du port UDP utilisé par l'agent, les variables systemContact, sysLocation et sysName, ainsi que les paramètres de vitesse de l'interface pour les cartes de réseau et les port PPP.

Les outils les plus importants de ce package sont :

  • /usr/bin/snmpget un programme destiné à la consultation d'une valeur concrète pour un agent MIB du réseau (un routeur, un hub...)
  • /usr/bin/snmpgetnext il permet de lire l'objet suivant dans l'arbre MIB sans connaître nécessairement son numéro.
  • /usr/bin/snmpsetun outil pour écrire des valeurs dans les objets des agents distants.
  • /usr/bin/snmpwalkun outil qui lit un objet complet ou une série d'objets sans spécifier l'instance exacte. Il est utile pour interroger des objets de type table.
  • /usr/bin/snmpnetstat
  • /usr/bin/snmptrapd Daemon qui écoute les "traps" des agents.
  • /usr/bin/snmptestoutil interactif destiné à démontrer les possibilités de API.

L'agent est situé dans le répertoire /usr/sbin/snmp.

CMU_SNMP intalle aussi un fichier MIB dans /usr/lib/mib.txt. C'est un bon endroit pour chercher quel type d'information on peut demander à un dispositif en réseau.

L'agent doit être lancé en exécution au démarrage de la machine. On peut faire cela en ajoutant les lignes suivantes dans un fichier d'initialisation (par exemple /etc/rc.f/rc.local) :

/usr/sbin/snmpd -f ; echo 'démarrer snmpd'

Une fois que l'agent est lancé dans la machine Linux, on peut essayer une fonction avec un outil quelconque de gestion, par exemple :

/usr/bin/snmpget -v 1 localhost public interfaces.ifNumber.0

lequel retournera le numéro des interfaces configurés dans le système, y:

/usr/bin/snmpwalk -v 1 localhost public system

retourne toutes les valeurs du sous-arbre "system" du MIB. (Voir la Figure 2 pour le résultat de cette commande.)

Figure 2 
dragon:~$ /usr/bin/snmpwalk

usage: snmpwalk [-p ] host community [object-id]

dragon:~$ /usr/bin/snmpwalk  localhost public system

system.sysDescr.0 = "Linux version 2.0.24 (root@dragon) 
                     (gcc version 2.7.2) #6 Mon Nov 25 15:08:40 MET 1996"
system.sysObjectID.0 = OID: enterprises.tubs.ibr.linuxMIB
system.sysUpTime.0 = Timeticks: (39748002) 4 days, 14:24:40
system.sysContact.0 = "David Guerrero"
system.sysName.0 = "dragon "
system.sysLocation.0 = "Madrid (SPAIN)"
system.sysServices.0 = 72
system.sysORLastChange.0 = Timeticks: (39748006) 4 days, 14:24:40
system.sysORTable.sysOREntry.sysORID.1 = OID: enterprises.tubs.ibr.linuxMIB.linuxAgents.1
system.sysORTable.sysOREntry.sysORDescr.1 = "LINUX agent"
system.sysORTable.sysOREntry.sysORUpTime.1 = Timeticks: (39748007) 4 days, 14:24:40

dragon:~$


La C-API est située dans /lib/libsnmp.so.3.1.

On peut visualiser les fichiers en relation avec la bibliothèque dans :

  • /usr/include/snmp/snmp.h
  • /usr/include/snmp/snmp_impl.h
  • /usr/include/snmp/asn1.h
  • /usr/include/snmp/snmp_api.h

On trouvera de plus amples informations dans les pages du manuel snmp-api(3) et variables(5).

Il existe aussi un module Perl d'interface avec CMU C_API grâce auquel on peut réaliser facilement des appels à cette bibliothèque depuis le programme Perl (Perl-scripts).

MRTG: Multi Router Traffic Grapher

MRTG est un utilitaire graphique tres avancé écrit par Tobias Oetiker et Dave Rand pour représenter graphiquement les données que les gestionnaires SNMP lisent sur les agents SNMP. Il produit une belle page HTML avec des images GIF sur le trafic entrant et sortant des interfaces du réseau, pratiquement en temps réel. Avec cet outil, on évite d'avoir à travailler directement avec les utilitaires CMU_SNMP au moyen de lignes de commandes. C'est l'outil le plus puissant et le plus facile à utiliser qu'on trouve sur Internet.

MRTG utilise une implémentation de SNMP écrite complètement en Perl, mais il n'est pas pour autant nécessaire d'installer un autre package. Le programme principal est écrit en C pour accélérer le processus de génération des images GIF. Les graphiques sont générés avec l'aide de la bibliothèque GD écrite par Thomas Boutell, auteur de la FAQ WWW.

Le package contient quelques fonctions pour analyser les interfaces de routage, extraire leurs caractéristiques et générer des fichiers de configuration de base, qu'on peut après modifier pour les adapter aux nécessités concrètes.

Une autre caractéristique intéressante de MRTG, c'est la quantité d'information qu'il produit. Il autorise quatre niveaux de détail pour chaque interface : trafic des 24 dernières heures, de la dernière semaine, du dernier mois et graphique annuel. Cela permet de recueillir des informations pour réaliser des statistiques. Il conserve toutes ces informations dans une base de données qui utilise un algorithme de consolidation qui empèche que les fichiers ne croissent de manière démesurée.

Il génére aussi une page principale qui contient les images GIF des détails journaliers de chaque interface de routage, ce qui permet de se faire une idée générale de ce qui passe au niveau du routeur d'un simple coup d'oeil. La page principale, ainsi qu'une page de détail générée par MRTG est visible sur les Figures 3 et 4.

Figure 3. Page principale de l'Interface Figure 4. Page des détails de l'Interface
Clikez sur les images pour les voir en plein écran

Voyons maintenant la procédure d'installation. Il faut se procurer une distribution sur Internet. Au moment où l'auteur écrit ces lignes, la dernière version est 2.1; visitez les URL référencés en fin d'article pour conaître la dernière version.

Avant de commencer l'installation de MRTG, il est nécessaire d'installer la bibliothèque GD (qu'on peut charger aussi sur Internet). La version actuelle est la 1.2 et il ne devrait pas y avoir de gros problèmes pour la compiler et l'installer. Tout simplement, il faut exécuter un make dans le répertoire où on a désarchiver la distribution et cela génére un fichier appelé libgd.a. Il faut copier ce fichier dans le répertoire /usr/local/lib et les fichiers avec extension .h dans le répertoire /usr/local/include/gd.

A ce point, le package GD est correctement installé. Maintenant, on peut compiler le package MRTG. Il faut extraire la distribution et éditer le fichier ../../common/January1998/Makefile pour indiquer où se trouve la bibliothèque et les archives de GD, ainsi que le fichier exécutable Perl 5.003 : normalement dans /usr/bin/perl ou usr/local/bin/perl. Ceci est fait avec les variables GD_LIB, GD_INCLUDE and PERL.

Il faut construire le programme principal grâce à la commande make rateup. Quand la compilation est terminée, tapez make substitute pour inclure le path correct de l'interpréteur Perl dans les scripts Perl utilisés par MRTG.

Copiez les fichiers suivants dans les repertoires de destination finale : (par exemple /usr/local/mrtg) : BER.pm, SNMP_Session.pm, mrtg y rateup. Il faut copier également dans ce répertoire les deux fichiers de configuration :indexmaker et cfgmaker.

Il faut s'assurer que tous les programmes ont une autorisation d'exécution. On peut alors créer un fichier de configuration simple. Il est nécessaire d'avoir un accés en lecture SNMP vers le routeur. Pour un routeur Cisco, les lignes de configuration qui donnent cette autorisation sont :

access-list 99 permit 193.147.0.8
access-list 99 permit 193.147.0.9
access-list 99 permit 193.147.0.130
snmp-server community public RO 99

Ceci autorise des demandes en lecture seule depuis les répertoires spécifiés dans la liste 99, en utilisant le mot clé "public" comme community. Si vous souhaitez un accés depuis n'importe quelle machine en mode lecture vers le routeur, la ligne est la suivante :

snmp-server community public RO

Si le routeur du réseau est d'une autre marque, il faut consulter son manuel pour déterminer les permissions d'accés SNMP. Le script cfgmaker simplifie beaucoup la tâche de construire le fichier de configuration. Il suffit de l'exécuter avec les paramètres suivants :

cfgmaker <community>@<router-host-name or IP>

Par exemple:

cfgmaker [email protected] > mrtg.cfg

Il localisera toutes les interfaces du routeur mec-router.rediris. Il écrira une section dans le fichier avec les spécifications des numéros d'interface, leur vitesse maximum, description, etc., joint à quelques étiquettes HTML, pour que cette section soit incluse dans la page détaillée. Il est possible d'éditer le fichier HTML, pour le traduire dans sa langue et ses préférences, etc. la figure 5 montre le résultat pour une des interfaces de mon routeur.

Figure 5
Target[mec-router.1]: 1:public@mec-router MaxBytes[mec-router.1]: 1250000 Title[mec-router.1]: mec-router.rediris.es (mec-router.mec.es): Ethernet0 PageTop[mec-router.1]: <H1>Estadisticas del puerto Ethernet0<BR> Red del MEC (MECNET)</H1> <TABLE> <TR><TD>System:</TD><TD>mec-router.rediris.es en RedIRIS </TD></TR> <TR><TD>Maintainer:</TD><TD>[email protected]</TD></TR> <TR><TD>Interface:</TD><TD>Ethernet0 (1)</TD></TR> <TR><TD>IP:</TD><TD>mec-router.mec.es (193.147.0.1)</TD></TR> <TR><TD>Max Speed:</TD> <TD>1250.0 kBytes/s (ethernetCsmacd)</TD></TR> </TABLE>

Maintenant, on peut exécuter le programme mrtg pour la première fois. Tout simplement, on lance la commande:

./mrtg mrtg.cfg

Si tout va bien, le programme se mettra en contact avec le routeur, demandera quelques valeurs, et générera quelques fichiers de recherche et quelques fichiers GIF dans le répertoire en cours. Il ne faut pas être surpris par les messages d'anomalies concernant les fichiers de registre ou graphiques qu'on n'a pas trouvés : cela arrive uniquement la première fois qu'on lance le programme. Il faut supprimer les fichiers graphiques qu'il génère et relancer le programme. Le graphique généré montrera le trafic produit depuis la dernière exécution du programme. Il génère aussi des pages HTML pour chaque interface.

Maintenant, nous allons également indiquer à MRTG comment il doit s'exécuter de manière adéquate dans le système. Premièrement, il faut créer un répertoire au sein du répertoire principal du serveur WEB, en supposant que le système dispose d'un serveur WEB qui fonctionne, pour contenir les pages et les graphiques que MRTG produit chaque fois qu'il s'exécute. Ajoutez ce répertoire dans l'entête du fichier de configuration avec la directive WorkDir: /usr/local/web/mrtg (supposant que le répertoire racine est situé dans /usr/local/web). La prochaine fois que MRTG s'exécutera, il créera les fichiers de registre et les fichiers graphiques dans ce répertoire, avec la possibilité d'accéder au travers de http://your_host_domaine/mrtg.

Maintenant on peut construire la page principale pour chaque interface comme celle de la Figure 3. On peut effectuer cela avec l'utilitaire indexmaker. Il faut exécuter :

indexmaker mrtg.cfg <router-name regexp> > /usr/local/web/mrtg/index.html

On génère un document HTML avec des graphiques journaliers des interfaces dont le nom de routeur coïncide avec l'expression régulière antérieure et on fait le lien avec la page individuelle détaillée.

Comme cela laisse à supposer, le programme MRTG doit s'exécuter à intervalles réguliers pour recueillir les données à chaque intervalle et générer des graphiques périodiques, de manière qu'il donne l'impression d'être monitoriser en temps réel. Ceci peut être obtenu au moyen de la ligne suivante dans le fichier /etc/crontab en supposant que le programme mrtg se situe dans le répertoire

0,5,10,15,20,25,30,35,40,45,50,55 * * * * \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

Dans le cas d'une RedHat, la ligne est la suivante :

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

Si aucun problème ne surgit, on peut consacrer quelque temps pour terminer la configuration et ajuster la page index HTML. Une bonne amélioration consisterait à inclure dans la section <HEAD> d'en-tête de cette page un code <META .....> pour obliger le viseur WEB à recharger l'information toutes les 300 secondes.

Une autre amélioration qu'on peut inclure dans le fichier de configuration est la directive WriteExpire, qui force MRTG à créer des fichiers " meta " pour chaque fichier GIF et page HTML, éliminant des opérations inutiles de " cache ", aussi au bien des serveurs proxy qu'au niveau des viseurs web. Pour cela, il est nécessaire de configurer le serveur Apache (en supposant que ce soit un serveur Apache) pour qu'il lise les fichiers " meta " et envoie correctement les entêtes " Expire " avec la directive MetaDir le fichier XXXX.

On peut rencontrer plus de directives dans le fichier de configuration exemple, qui est fourni avec la distribution, par ailleurs très bien documentée. Il est possible de modifier la disposition des images générées par MRTG.

Nous espérons que vous apprécierez ce programme : s'il en est ainsi, envoyez un petit mot aux auteurs, dont vous trouverez l'adresse dans les pages Web de MRTG.

Autres programmes

Il existe un programme similaire appelé Router-Stats, écrit par Iain Lea, le célèbre auteur du lecteur de news " tin ". Router-Stats actualise les graphiques une fois par jour, et présente une information statistique très intéressante sur l'utilisation horaire et autres aspects. Le seul problème, c'est qu'il se base sur de nombreux programmes externes (SMU-SNMP pour les tâches avec SNMP, GNUPLOT pour tracer des graphiques, NetPBM et GIFTOOL pour travailler avec des graphiques).

Il y a une autre catégorie de software qui apporte un plus dans la tâche de gestion des réseaux, offrant une solution complète aussi bien pour superviser que pour configurer tout le réseau. Ce type de solution permet d'obtenir une vue graphique complète du réseau, et visualiser facilement les noeud qui le composent, en vérifiant les détails des configurations spécifiques autres questions qui présentent un intérêt.

A ce niveau, nous pouvons parler de deux solutions commerciales qui sont largement utilisées : HP-OpenView de Hewlett-Packard et SunNetManager de Sun. Ces outils offrent une plate-forme intégrée pour la gestion des réseaux au travers d'interfaces graphiques impressionnantes. Entre autres fonctionnalités, ils disposent d'outils pour localiser les noeuds du réseau où s'exécutent des agents SNMP. Autre caractéristique importante, c'est la capacité d'intégrer les produits des autres fabricants, comme CiscoWork de Cisco, qui permet à l'administrateur de maintenir une base de données avec toutes les configurations des routeurs et même de superviser graphiquement les panneaux arrières des routeurs avec toutes leurs connexions.

Les deux inconvénients majeurs de ces produits, c'est qu'ils sont commerciaux et ne sont pas disponibles pour Linux. néanmoins, il existe des solutions disponibles publiquement avec une fonctionnalité plus ou moins identique. Un des packages qu'on trouve c'est le Scotty. Scotty est un package basé sur TCL qui permet la création de programmes spécifiques aux nécessités propres du réseau, utilisant un API de haut niveau de chaînes de caractères. Un package similaire est le Tkined. C'est une éditeur de réseau qui offre des extensions qui permet de créer un ensemble de tâches complet, intégrant quelques outils pour localiser les IP réseaux, support pour le processus d'installation du réseau ou résolution de problèmes IP réseaux utilisant SNMP en relation avec d'autres utilitaires standard (par exemple traceroute). Scotty inclut aussi un visualisateur graphique MIB qui permet d'explorer facilement les informations MIB.

La liste en fin d'articles vous donne les références de logiciels de gestion de réseau commerciaux et gratuits..

Conclusions

SNMP est un protocole simple mais puissant qui peut aider à superviser les ressources d'un réseau sans trop surcharger celui-ci. Il est probable que les extensions qu'on développe actuellement incrémentent la complexité et les possibilités de cet outil, mais en contrepartie augmenteront les ressources nécessaires pour l'installer.

Dans cet article, on a présenté deux outils qu'on peut trouver sur Internet. Il existe une multitude d'outils qu'on développe continuellement. Consultez les groupes de news usenet comp.protocols.snmp pour vous tenir au courant des différentes annonces sur les nouveaux logiciels et MIBs.



Références
CMU-SNMP pour Linux:
ftp://sunsite.unc.edu/pub/Linux/system/network/admin/cmu-snmp-linux-3.2-bin.tar.gz
PERL 5 module d'extension pour CMU-SNMP:
ftp:/ftp.wellfleet.com/netman/snmp/perl5/SNMP.tar.gz
Multi Router Traffic Grapher (MRTG):
http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
GD Graphic Library: (nécessaire pour MRTG)
http://www.boutell.com/gd/
Perl 5.003: (nécessaire pour MRTG)
http://www.perl.com/perl/info/software.html
Listes de diffusion MRTG:
Listes de Discussion

Envoyer un courrier à [email protected] avec "subscribe" dans le sujet

Liste d'annonces :

mail to [email protected] with "subscribe" in the subject

Router Stats:

http://www.scn.de/~iain/router-stats/
Logiciel de gestion de réseau SNMP:
http://wwwsnmp.cs.utwente.nl/software/
Scotty:
http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/
Scotty pour Linux:
ftp://sunsite.unc.edu/pub/Linux/system/network/admin/tkined-1.3.4+scotty-ELF.tar.gz

Traduit par Joaquin Gonzales
Pour en savoir plus:
  • Lisez le "Network Administration Guide".


© 1997 David Guerrero
Ce site web est maintenu par Miguel A Sepulveda.