Chapitre 5

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 10

Chapitre 5

Gestion et monitoring des réseaux Ip

1. Introduction
De nos jours, les réseaux informatiques dans les entreprises deviennent de plus en plus
importants et complexes. Le besoin de maintenance et de gestion de ces réseaux est
rapidement devenu une priorité. Il faut souvent avoir recours à des techniques
d’administration pour pouvoir contrôler leur fonctionnement mais aussi afin d’exploiter au
mieux les ressources disponibles, et de rentabiliser au maximum les investissements réalisés.

La disponibilité des réseaux devient de plus en plus critique pour l'entreprise du fait de l'intégration
croissante des ordinateurs à tous les processus. Ainsi des défaillances de système peuvent causer de
graves pertes. En surveillant continuellement le réseau et les serveurs, on peut détecter non seulement
les défaillances apparues, mais aussi les problèmes cachés longtemps avant que les problèmes
deviennent sérieux :

 Evitez les goulots d'étranglement de la bande passante et serveurs


 Améliorez la qualité de la prestation fournie à vos utilisateurs en négociant proactive
 Planifiez vos investissements d'infrastructure en vous basant sur des tendances d'utilisation
fiables
 Augmentez votre profit en évitant des pertes à cause de défaillances de système cachées

2. Généralités

La gestion des réseaux informatiques constitue un problème dont l’enjeu est de garantir au
meilleur coût non seulement la qualité du service global rendu aux utilisateurs mais aussi la
réactivité face aux besoins de changement et d’évolution.
La gestion des réseaux informatiques se définit comme étant l’ensemble des moyens mis en
œuvre (connaissances, techniques, méthodes, outils) pour superviser, exploiter des réseaux
informatiques et planifier leur évolution en respectant les contraintes de coût et de qualité. La
qualité de service se décline sur plusieurs critères, du point de vue de l’utilisateur final,
notamment la disponibilité, la performance (temps de réponse), la fiabilité, la sécurité…
Les activités d’administration sont communément classées en activités de :
Supervision qui consiste à surveiller les systèmes et à récupérer les informations sur leur état
et leur comportement, ce qui peut être fait par interrogation périodique ou par remontée non
sollicitée d’informations de la part des équipements de réseaux eux-mêmes.
- Administration qui désigne plus spécifiquement les opérations de contrôle « à froid »
du réseau avec la gestion des configurations et de la sécurité.
- Exploitation qui désigne l’ensemble des activités permettant de traiter les problèmes
opérationnels sur le réseau : maintenance, assistance technique…

3. Principe général
Sur le point de l’administration, un système de réseau informatique se compose d’un
ensemble d’objets qu’un système d’administration surveille et contrôle. Chaque objet est géré
localement par un processus appelé agent qui transmet régulièrement les informations de
gestion relatives à son état et les événements qui le concernent au système d’administration.
Le système d’administration comprend un processus (manager ou gérant) qui peut accéder
aux informations de gestion de la MIB (Management Information Base) locale via un
protocole d’administration comme SNMP ou CMIP ce qui le met en relation avec les divers
agents.
Le principe se repose donc sur les échanges :
- D’une part, entre une base d’informations appelée MIB (Management Information
Base) et l’ensemble des éléments administrés (objets)
- D’autre part, entre les éléments administrés et le système d’administration.

Figure 1: Administration réseau « Structure fonctionnelle »

Le processus de supervision est réalisé à plusieurs niveaux: Au niveau interconnexions


(Réseau), au niveau de la machine elle-même (Système) et au niveau des services offerts par
cette machine (Applications).
 Supervision réseau : Par le terme réseau on entend ici l'aspect communication entre
les machines. Le rôle est de s'assurer du bon fonctionnement des communications et
de la performance des liens (débit, latence, taux d'erreurs). C'est dans ce cadre que l'on
va vérifier par exemple si une adresse IP est toujours joignable, ou si tel port est ouvert
sur telle machine, ou faire des statistiques sur la latence du lien réseau.
 Supervision système : La surveillance se cantonne dans ce cas à la machine elle
même et en particulier ses ressources. Si l'on souhaite par exemple contrôler la
mémoire utilisée ou la charge processeur sur le serveur voire analyser les fichiers de
logs système.
 Supervision applicative : Cette technique est plus subtile, c'est elle qui va nous
permettre de vérifier le fonctionnement d'une application lancée sur une machine. Cela
peut être par exemple une tentative de connexion sur le port de l'application pour voir
si elle retourne ou demande bien les bonnes informations, mais aussi de l'analyse de
logs applicatifs.

La supervision du réseau se base sur deux grandes méthodes s'opposent lorsque l'on parle de
supervision.
- le polling
- le heartbeat
Le Polling est un sondage réalisé périodiquement (à intervalle de temps régulier) par un
superviseur. Cette méthode permet un véritable suivi à l'initiative du superviseur mais elle a
les inconvénients suivants : des échanges pour rien, Réaction non temps réel, possibilité de ne
pas voir certains changements.
Le HeartBeat est un signal émis par un équipement à chaque changement d'état. Cette
méthode fonctionne en temps réel et permet de remonter tous les événements. Cependant, elle
ne permet pas de remonter les événements produits lors de l'initiative de l'équipement actif

4. Concepts de supervision:
Le concept de supervision a été normalisé par l’ISO (International Organization for
Standardization, la norme ISO7498/4). Voici les différentes fonctions qui ont été défini par
cette norme :

4.1 Gestion des performances : Elle doit pouvoir évaluer les performances des ressources du
système et leur efficacité. Elle comprend les procédures de collecte de données et de
statistiques. Elle doit aboutir à l’établissement de tableaux de bord. Les informations
recueillies doivent aussi permettre de planifier les évolutions du réseau. Les performances du
réseau sont évaluées à partir de quatre paramètres :
- le temps de réponse
- le débit
- le taux d’erreur par bit
- la disponibilité

4.2 Gestion des configurations (Management Configuration) : La gestion de configuration


permet d’identifier, de paramétrer et de contrôler les différents objets du réseau. Les
procédures requises pour gérer une configuration sont :
- la collecte d’information
- le contrôle d’état
- la sauvegarde historique de configurations de l’état du système.

4.3 Gestion de la comptabilité (Accounting Management) : Son rôle est de connaître les
charges des objets gérés ainsi que leurs coûts de communication. Des quotas d’utilisation
peuvent être fixés temporairement ou non sur chacune des ressources réseaux. De plus, la
gestion de la comptabilité autorise la mise en place de systèmes de facturation en fonction de
l’utilisation pour chaque utilisateur.

4.4 Gestion des anomalies (Fault Management) : La gestion des fautes permet la détection,
la localisation et la correction d’anomalies passagères ou persistantes. Elle doit également
permettre le rétablissement du service à une situation normale.

4.5 Gestion de la sécurité (Security Management) La gestion de la sécurité contrôle l’accès


aux ressources en fonction des politiques de droits d’utilisation établies. Elle veille à ce que
les utilisateurs non autorisés ne puissent accéder à certaines ressources protégées. Elle a
également pour rôle de mettre en application les politiques de sécurité

5. Supervision basée sur le protocole SNMP

5.1 Présentation :
SNMP (Simple Network Management Protocol) est le protocole de gestion de réseaux
proposé par l'IETF. Il est actuellement le protocole le plus utilisé pour la gestion des
équipements de réseaux. SNMP est un protocole relativement simple. Pourtant l'ensemble de
ses fonctionnalités est suffisamment puissant pour permettre la gestion des réseaux
hétérogènes complexes. Il est aussi utilisé pour la gestion à distance des applications : les
bases de données, les serveurs, les logiciels, etc. Les buts du protocole SNMP sont de :
- connaître l'état global d'un équipement (actif, inactif, partiellement opérationnel...)
- gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal d'un
équipement...) ;
- analyser différents métriques afin d'anticiper les problèmes futurs (engorgement
réseau...) ;
- agir sur certains éléments de la configuration des équipements.

5.2 Les différentes versions du SNMP :


Depuis la création de SNMP, ce protocole a connu des améliorations importantes. Cependant
les précédentes versions (la V1 et la V2C) sont encore les versions les plus utilisées
actuellement. Un support de SNMP V3 a récemment été lancé car il est plus sécurisé si on le
compare à ses prédécesseurs.
- SNMP V1 : C'est la première version du protocole. La sécurité de cette version est
minimale car elle basée uniquement sur la chaîne de caractère appelée "communauté".
Cette version du protocole est définie dans les RFC 1155 et 1157.
- SNMP V2C : C'est un protocole révisé, qui comprend les améliorations de SNMP V1
dans différents domaines tels que les types de paquets, les éléments de structure MIB
et les requêtes protocolaires MIB. Cependant ce protocole utilise la structure
d'administration de SNMP V1 (à savoir "communauté") d'où le terme SNMP V2C.
- SNMP V3 : Aussi connu sous le nom de version sécurisée de SNMP. SNMP V3
facilite la configuration à distance des entités SNMP.

Ces trois versions sont les principales, même si des versions intermédiaires ont vu le jour
(SNMPSec, SNMP V2, SNMP V2U, SNMP V2P), celles-ci ne présentent que des mises à
jours mineures plutôt que de véritables améliorations. Actuellement les versions les plus
utilisées (par ordre d'utilisation) sont : SNMP V1, SNMP V3 puis SNMP V2C. Malgré tout la
version SNMP V1 persiste encore sur les périphériques, plusieurs facteurs expliquent ce
phénomène :
 Les infrastructures déployées en V1 ne sont plus modifiées, tout
simplement car cela fonctionnait suffisamment à l'époque, du coup
aucune modification n'y est appliquée.
 Les autres versions de SNMP ont été implémentées tardivement par les
différents constructeurs.
 SNMP V1 demande très peu de ressources sur des petits équipements
tels qu'une imprimante ou un hub.

5.3 Architecture :
Les différents éléments que l'on peut identifier avec le protocole SNMP sont synthétisés par le
schéma ci-dessous.
- Les agents SNMP : ce sont les équipements (réseau ou serveur) qu'il faut superviser.
- Le superviseur SNMP : c'est une machine centrale à partir de laquelle un opérateur
humain peut superviser en temps réel toute son infrastructure, diagnostiquer les
problèmes et finalement faire intervenir un technicien pour les résoudre.
- La MIB : ce sont les informations dynamiques instanciées par les différents agents
SNMP et remontées en temps réel au superviseur.
Figure 2: Architecture SNMP

5.4 Le manager
Rappelons que le Manager se trouvera sur un machine d'administration (un poste de travail en
général). Il reste un client avant tout, étant donné que c'est lui qui envoie les différentes
requêtes aux agents. Il devra disposer d'une fonction serveur, car il doit également rester à
l'écoute des alertes que les différents équipements sont susceptibles d'émettre à tout moment.
Si l'on se base sur le schéma précédent, l'administrateur peut observer correctement le
comportement de ses différents équipements en réseau. Le Manager dispose d'un serveur qui
reste à l'écoute sur le port UDP 162 ainsi que d'éventuels signaux d'alarme appelés des
"traps". Le Manager peut tout autant être installé sur une machine.

5.5 L’agent snmp :


L'agent est un programme qui fait partie de l'élément actif du réseau. L'activation de cet agent
permet de recueillir la base de données d'informations et la rend disponible aux interrogations.
Les principales fonctions d'un agent SNMP :
- Collecter des informations de gestion sur son environnement local.
- Récupérer des informations de gestion tel que dé_ni dans la MIB propriétaire.
- Signaler un évènement au gestionnaire.

Par ailleurs même si la principale fonction de l'agent est de rester à l'écoute des éventuelles
requêtes du Manager et y répondre s’il y est autorisé, il doit également être capable d'agir de
sa propre initiative, s'il a été configuré. Par exemple, il pourra émettre une alerte si le débit
d'une interface réseau, atteint une valeur considérée par l'administrateur comme étant critique.
Plusieurs niveaux d'alertes peuvent ainsi être définis, selon la complexité de l'agent
(température du processeur, occupation disque dur, utilisation CPU...)

5.6 MIB :
Chaque agent SNMP maintient une base de données décrivant les paramètres de l'appareil
géré. Le Manager SNMP utilise cette base de données pour demander à l'agent des
renseignements spécifiques. Cette base de données commune partagée entre l'agent et le
Manager est appelée Management Information Base (MIB). Généralement ces MIB
contiennent l'ensemble des valeurs statistiques et de contrôle définis pour les éléments actif du
réseau. SNMP permet également l'extension de ces valeurs standards avec des valeurs
spécifiques à chaque agent, grâce à l'utilisation de MIB privées.

Un fichier MIB est écrit en utilisant une syntaxe particulière, cette syntaxe s'appelle SMI 3,
basée sur ASN.1 tout comme SNMP lui-même. En résumé, les fichiers MIB sont l'ensemble
des requêtes que le Manager peut effectuer vers l'agent. L'agent collecte ces données
localement et les stocke, tel que défini dans la MIB. Ainsi le Manager doit être conscient de la
structure (que celle -ci soit de type standard ou privée) de la MIB afin d'interroger l'agent au
bon endroit.

La structure d’une MIB est une arborescence hiérarchique dont chaque nœud est défini par un
nombre ou un Object IDentifier (OID). Chaque identifiant est unique et représente les
caractéristiques spécifiques du périphérique géré. Lorsqu'un OID est interrogé, la valeur de
retour n'est pas un type unique (texte, entier, compteur, tableau...) Un OID est donc une
séquence de chiffres séparés par des points. Une MIB est un arbre très dense, il peut y avoir
des milliers d'OID dans la MIB.

Voici un exemple de structure MIB :

Figure 3 : Strcuture OID


Ainsi, pour interroger les différentes variables d'activité sur un appareil, il faudra explorer son
arborescence MIB. Celle-ci est généralement fournie par le constructeur mais il est aussi
possible d'utiliser un explorateur de MIB tel que « Getif MIB Browser ».

Ensuite, pour accéder aux variables souhaitées, on utilisera l'OID (Object Identification) qui
désigne l'emplacement de la variable à consulter dans la MIB. On aura par exemple sur un
commutateur Nortel Passport l'OID .1.3.6.1.4.1.2272.1.1.20 désignant le taux de charge du
CPU.

5.7 Les requêtes SNMP :


Le mécanisme de base du protocole SNMP est constitué d’échanges de type requête/réponse
appelé PDU pour Protocol Data Unit. En fonction de la version du protocole SNMP utilisé,
différentes commandes sont possibles. La structure des paquets utilisés par le protocole
SNMP V1, est définie dans la RFC 1157. Les requêtes SNMP vont contenir une liste d’OID
(Object identifier) à collecter sur l’agent SNMP.

Les types de requêtes du manager SNMP vers l’agent SNMP sont :


- Get Request : Le manager interroge un agent sur les valeurs d’un ou de plusieurs
objets d’une MIB.
- Get Next Request : Le manager interroge un agent pour obtenir la valeur de l’objet
suivant dans l’arbre des objets de l’agent. Cette interrogation permet de balayer des
objets indexés de type tableau.
- Get Bulk Request : Introduite avec la version 2 du protocole SNMP, cette requête
permet de mixer la commande GET et GETNEXT pour obtenir des blocs entiers de
réponses de la part de l’agent.
- Set Request : Le manager positionne ou modifie la valeur d’un objet dans l’agent.

Les réponses ou informations de l’agent vers le manager sont :


- Get Response : L’agent répond aux interrogations du manager.
- Trap : L’équipement génère un envoi vers son manager pour signaler un événement,
un changement d’état ou un défaut. L’agent n’attend pas d’acquittement de la part du
manager.
- Notification : Introduite avec la version 2 du protocole SNMP. L’équipement génère
un envoi vers son manager pour signaler un événement, un changement d’état ou un
défaut. L’agent n’attend pas d’acquittement de la part du manager.
- Inform : Introduite avec la version 2 du protocole SNMP. L’équipement génère un
envoi vers son manager pour signaler un événement, un changement d’état ou un
défaut. L’agent attend un d’acquittement de la part du manager et il y aura une
retransmission en cas de non réponse.
Figure 4 : Les échanges entre le manager et l’agent SNMP

6 Supervision basée sur SYSLOG

6.1 Présentation :
Le protocole Syslog est un protocole très simple et très largement utilisé. Son but est de
transporter par le réseau les messages de journalisation générés par une application vers un
serveur hébergeant un serveur Syslog. Un autre but est aussi d'assurer la fonction de
concentration des journaux, un serveur Syslog intermédiaire pouvant re-transférer les
messages Syslog qu'il reçoit vers un autre serveur Syslog.

6.2 L’architectures Syslog


L’architecture Syslog contient trois nœuds (Client syslog, relais syslog et serveur syslog) :
- Un Client syslog est une machine ou une application qui génère des messages Syslog.
- Un relais syslog est une machine ou une application qui reçoit des messages Syslog et
les retransmet à une autre machine.
- Un serveur syslog est une machine ou une application qui reçoit des messages Syslog
mais qui ne les retransmet pas.

6.3 Structure du message syslog


La structure du message syslog peut contenir six champs comme suit :

< facility, security, timestamp, host, tag, message>

Facility : correspond au type d'application générant le message Syslog. Les


24 fonctionnalités existantes sont définies par la RFC 3164

Numéro de fonctionnalité Usage

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0
17 local use 1
18 local use 2
19 local use 3
20 local use 4
21 local use 5
22 local use 6
23 local use 7

Security: correspond au degré d'urgence du message. Il contient 8 niveaux de sévérités.

Numéro de sévérité Usage


0 Emergency : system is unusable
1 Alert : action must be taken immediately
2 Critical : critical conditions
3 Error : error conditions
4 Warning : warning conditions
5 Notice : normal but significant condition
6 Informational : informational messages
7 Debug : debug-level messages

Timestamp : Représente le horodatage du message. Le format de date utilisé par le champ


TIMESTAMP est "Mmm dd hh:mm:ss".

 "Mmm" est l'abréviation anglaise pour le mois sur 3 caractères. Les seules valeurs
admises sont : "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct",
"Nov", "Dec".
 Un caractère espace (" ") doit obligatoirement suivre la valeur du nom du mois.
 "dd" représente le numéro de jour dans le mois. Ce numéro de jour doit toujours être
représenté par 2 caractères. Si ce numéro de jour est inférieur à 10, il doit alors être
précédé du caractère espace (" ").
 Un caractère espace (" ") doit obligatoirement suivre la valeur numéro de jour.
 "hh:mm:ss" est l'heure locale. L'heure est représentée en utilisant un format sur 24
heures. Les valeurs autorisées vont de "00" à "23". Les valeurs autorisées pour les
minutes ("mm") et les secondes ("ss") vont de "00" à "59".

Un caractère espace (" ") doit obligatoirement suivre le champ TIMESTAMP.

Hostname : Le champ HOSTNAME peut contenir :

 Un nom de machine sans son nom de domaine. Un nom de machine ne doit pas
contenir de caractère espace (" ").
 Une adresse IP au format IPv4 (format décimal pointé 192.168.1.1 par exemple).
 Une adresse IP au format IPv6 (voir la RFC RFC 2373 pour les différentes notations
supportées).
 Rien, le champ HOSTNAME est facultatif.

Un caractère espace (" ") doit obligatoirement suivre le champ HOSTNAME (même si ce
champ est vide).

Tag : nom du processus ayant généré le message.

Message : ce champ comprend au message texte à transférer.

7 Quelques solutions de supervision

Logiciels snmp de base

 snmp
 snmpd (agent)
 net-snmp (windows)
 Logiciels Syslog
 syslog-ng

Logiciels Browser de Mib

 mbrowse
 snmpb
 Mib-Browser (Windows)

Logiciels de supervision

 Nagios
 Shinken
 Centreon
 HP Openview
 Cacti
 PRTG, MRTG
 Orion (Solarwinds)

Vous aimerez peut-être aussi