SUPERVISION DES

RÉSEAUX
INFORMATIQUES

Animé par : LABRIGUI Jihane

Introduction
 Le métier
d’administrateur devient
de plus en plus complexe.

 Un défi majeur pour

l’équipe est de gagner en
temps et en efficacité
grâce à un bon outil de
supervision.

 Les systèmes
d’information étant par
nature complexes, leur
supervision est
indispensable.
Les problèmes sont
inévitables
 Les systèmes d’information sont tous différents de
par leur taille, leur nature, leur criticité.
 Ils ont cependant pour point commun d’être le
théâtre d’incidents, à un moment ou à un autre.
 La loi de Murphy est immuable. « Si quelque chose
peut mal tourner, alors elle finira infailliblement par
mal tourner ».
 Les administrateurs doivent concevoir l’architecture
du système d’information de telle manière qu’une
panne ait un impact minimal sur le reste du
système.
 Ils doivent aussi gérer les éventuels problèmes.
 80% de l’activité d’un administrateur consiste en la
résolution de problèmes que rencontrent les
utilisateurs.
Être alerté en temps réel
 Les utilisateurs : un moyen de
supervision peu fiable et pas
toujours agréable.

 Les utilisateurs ne manquent pas de

signaler aux administrateurs les
problèmes qu’ils y rencontrent.

 les problèmes surviennent soit par

manque de formation des
utilisateurs, soit par réelle carence
du système.

 L’utilisateur réclamant un problème

n’est généralement ni tendre ni très
précis.

 Une solution de supervision permet à

l’administrateur d’éviter ce genre de
soucis.
Pourquoi un outil de
supervision ?
 L’administrateur est prévenu rapidement
d’une situation anormale.
 Il dispose de plus d’informations
pertinentes et peut immédiatement
s’atteler à la résolution du problème.
 En outre, certaines ressources ne sont
utilisées qu’occasionnellement, sans outil
de supervision, l’erreur n’est pas remontée.
 Les systèmes étant de plus en plus
imbriqués, une simple erreur peut en
produire un nombre incalculable d’autres
(effet domino).
Pourquoi un outil de supervision :
Eviter l’effet domino
 Une ressource fait partie d’une
architecture plus large.

 En cas de problème, cette

ressource peut emporter avec
elle tout un pan de la
construction.

 Assurer une vitesse de

détection et de réaction.

 La résolution rapide du
problème épargne les autres
éléments.

 Gagner du temps et minimiser

la charge du travail.
supervision :
remonter à la source du
problème
 Un historique pour
remonter à la source
des problèmes.

 Un outil de supervision
permet de conserver un
historique des alertes.

 Analyser les incidents qui

se sont produits juste
avant le problème constaté
permet de remonter à la
source.

 On arrive à résoudre le
problème rapidement.
Pourquoi un outil de supervision :
Être proactif face aux problèmes
 Certains problèmes sont précédés de signes
annonciateurs avant de devenir bloquants.

 Repérer ces signes est une plus-value non

négligeable des outils de supervision.

 Surveiller le système d’information y compris

pendant les périodes non ouvrées présente
bien des avantages.

 Être proactif ; résoudre les problèmes, avant

même qu’ils ne se présentent, à condition
d’être bien informé.
supervision :
Améliorer la disponibilité
effective
 Distinguer entre les plaintes abusives des
utilisateurs et les véritables soucis de
performance.

 Accorder des priorités sur les interventions pour

se concentrer sur l’essentiel.

 prévoir les besoins futurs et dimensionner au

mieux le système d’information.

 Les outils de supervision ont souvent un champ

d’action qui s’étend au-delà du seul périmètre
du système d’information.
Mise en place d’une solution
de supervision
 La mise en place d’un outil de supervision
est un projet complexe, dont il faut prévoir et
prévenir les plus gros obstacles.

 Un défaut courant dans la mise en place

d’une solution de supervision est de la traiter
comme une opération purement technique.

 la réussite du projet de supervision sera

autant technique qu’organisationnelle.

 La supervision doit évoluer avec le SI.

Mise en place d’une solution
de supervision
 Trouver l’équilibre entre « ne rien rater
d’important » et « vouloir tout superviser ».

 Il vaut mieux alors avoir trop d’indicateurs que

pas assez.

 Si un indicateur n’apporte aucune information

par rapport à un autre déjà en place, il ne faut
pas le surveiller.

 Il est vivement déconseillé de mettre en place

la totalité de la supervision en une seule
opération.
Mise en place d’une solution
de supervision
 Faire accepter le projet de supervision à ses
supérieurs.

 Intérêt de faire adhérer toute l’équipe à l’outil.

 Limiter le nombre d’alertes et les hiérarchiser.

 Alerter uniquement les bonnes personnes.

 Des indicateurs aussi simples et clairs que

possible.

 Est perçu comme un surveillant permanent.

Mise en place d’une solution
de supervision
 Les indicateurs de métrologie sont comme
les épices dans un plat : s’il n’y en a pas
assez, c’est fade ; s’il y en a trop, c’est
écœurant.

 Un nombre insuffisant d’indicateurs ne permet

pas à coup sûr que l’un d’entre eux éclaire sur la
cause probable d’un problème.

 S’il y en a trop, les informations risquent d’être

en double , de prendre plus d’espace et de
capacité de calcul et cela fait perdre du temps.

 Trouver un juste milieu est nécessaire.

Superviseur mais également
hyperviseur
 Les outils de supervision ne doivent pas
se contenter d’un rôle de supervision.

 Ils doivent également être à l’écoute

des autres outils afin de centraliser les
informations.

 Une seule console de supervision.

 La modularité : réduire si possible le

nombre de superviseurs.
 ISO et le modèle
d'administration réseau
 L'organisme international de normalisation ISO
(International Standards Organization) a créé
un comité visant à produire un modèle pour
l'administration réseau, sous la direction du
groupe OSI.

 Ce modèle se décline en quatre parties:

 Le modèle d’organisation
 Le modèle d’informations
 Le modèle de communication
 Le modèle fonctionnel
 Modèle d’administration
réseau
 Le modèle d'organisation décrit les composants de
l'administration réseau, par exemple administrateur, agent, et ainsi
de suite, avec leurs relations. La disposition de ces composants
mène à différents types d'architecture.

 Le modèle d’informations est relatif à la structure et au stockage

des informations d'administration réseau. Ces informations sont
stockées dans une base de données, appelée base d'informations
de management (MIB). L'ISO a établi la structure des informations
d'administration (SMI) pour définir la syntaxe et la sémantique des
informations d'administration stockées dans la MIB.

 Le modèle de communication traite de la manière dont les

données d'administration sont transmises entre les processus agent
et administrateur. Il est relatif au protocole d'acheminement, au
protocole d'application et aux commandes et réponses entre égaux.

 Le modèle fonctionnel concerne les applications d'administration

réseau qui résident sur la station d'administration réseau (NMS). Le
modèle d'administration OSI compte cinq domaines fonctionnels,
parfois appelés le modèle FCAPS.
 Les domaines fonctionnels
 La gestion de la
configuration réseau.
 La gestion des
performances.
 La gestion des
anomalies.
 La gestion de la
sécurité.
 La gestion de la
comptabilité.
FCAPS : Fault Management
 La gestion des anomalies est souvent le
module le plus populaire au sein des outils de
gestion réseaux.

 Permet de détecter, isoler et résoudre les

problèmes réseaux rencontrés voire même de
prédire des incidents potentiels.

 Réduire les temps d’arrêt, la dégradation des

performances ou tout autre incident…
 Détection des incidents, correction des
anomalies, isolation des incidents, notifications
des incidents, corrélation des alertes, …
FCAPS : Configuration
Management
 La gestion de la configuration permet de
collecter et de stocker les informations de
configuration des équipements ; que ce soit
physiques ou systèmes.

 Il permet donc d’obtenir un inventaire des

équipements et des programmes présents.
 De plus, cet inventaire sera continuellement à jours.

 Simplifie le processus de changement et en obtenir

un réel suivi.
 Récolte des informations systèmes, génération de
statistiques, gestion des backups, management des
changements, analyse des tendances (d’usage)
pour préparer la consommation future, …
FCAPS : Accounting
Management
 La gestion des accès permet de faire des
statistiques utilisateurs. En effet, en prenant
en compte les usages ainsi que l’analyse des
accès aux équipement, on peut établir une
réelle estimation des coûts.

 Répartition des ressources de façon optimale

et équitable entre les utilisateurs du réseau.
 Utilisation des systèmes plus efficace, en
minimisant le coût des opérations.
 Analyse de l’usage matériel et logiciel,
gestion des coûts, …
FCAPS : Performance
Management
 La gestion des performances vise à mesurer les
différents aspects de la performance des équipements
et des systèmes.

 Permet de comprendre l’état actuel du réseaux et de

savoir comment il se comporte.
 Préparer le réseaux pour les futurs besoins.

 Gestion des performances inclus la mesure de

différents indicateurs.
 Assurer la disponibilité du service et les performances
à un niveau optimal.
 Gestion des seuils pour les alertes, génération de
graphs concernant différents indicateurs, prédire
l’utilisation futur en analysant les perfs, …
FCAPS : Security Management
 La gestion de la sécurité prend en charge la
protection des équipements, la sécurité d’accès via
une authentification encryptée ainsi que la
protection des informations confidentielles.

 Protéger le réseau contre les hackers, les

utilisateurs non autorisés, ou même contre le
sabotage physique du matériel.
 La confidentialité des données doit être gérer selon
les besoins clients et doit être maintenue à un seuil
donné tout au long du cycle de vie du réseau.

 Gestion des autorisations, historique des accès,

génération d’audit, …
SNMP ?
 Simple Network Management Protocol.
 Protocole de communication entre
agent et station de gestion(NMS).
 Permet aux administrateurs réseau de
superviser, diagnostiquer et de gérer
les équipements du réseau.
 Développé par l’IETF.
 RFC 1157.
Différentes versions
SNMP
 Le protocole SNMP a commencé à émerger dans les
années 1980 et a évolué en plusieurs versions.
 SNMPv1 : c'est la première version du protocole. La
sécurité de cette version est minimale, car elle est
basée sur la connaissance entre les parties d'une chaîne
de caractères appelée "communauté" ;
 SNMPv2c : cette version du protocole est appelée
"community string based SNMPv2". Elle améliore encore
les requêtes protocolaires par rapport à SNMPv2p et
utilise la sécurité par chaîne de caractères
"communauté" de SNMPv1 ;
 SNMPv3 : cette version, supportant les "proxies", est
une combinaison de la sécurité basée sur les usagers,
les types et les opérations définis dans SNMPv2p. La
sécurité est basée sur les
versions SNMPv2u et SNMPv2*.


Différentes versions
SNMP
 Actuellement, les versions les plus utilisées
sont : SNMPV1, SNMPV3 et SNMPV2c.
 Le fait que la version 1 de SNMP perdure de
nos jours s'explique par plusieurs facteurs :
 Les infrastructures déployées en version 1 ne sont
plus modifiées sous prétexte que l'on ne modifie
pas quelque chose qui fonctionne ;
 Les nouvelles versions de SNMP ont été
implémentées avec beaucoup de retard par les
différents équipementiers (Le protocole CMIP été
développé en parallèle).
 SNMPv1 est un protocole très simple qui demande
peu de ressources lors de son implantation sur un
petit équipement (une imprimante ou un hub …).
Que permet le protocole
snmp ?
 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 indicateurs afin d'anticiper
les problèmes futurs (engorgement réseau...) ;
 Agir sur certains éléments de la configuration
des équipements.
Architecture globale
Architecture globale :
Agent SNMP
 Un agent SNMP est un logiciel implanté sur un
équipement à superviser.
 Il s'agit souvent d'un équipement réseau (switch,
hub, routeur...) mais on trouve aussi des agents sur
des serveurs.
 Le rôle d'un agent SNMP est :
 d'instancier les différentes variables de la MIB
spécifiques à cet équipement ;
 de mettre à jour les valeurs dynamiques de ces
différentes variables ;
 de recevoir les requêtes SNMP envoyées par le
superviseur SNMP et d'y répondre ;
 d'envoyer les messages SNMP "Trap" ou "Inform" au
superviseur SNMP pour le prévenir d'un événement
exceptionnel sur l'équipement ;
 de gérer la sécurité des accès aux variables de la MIB
Architecture globale :
Les superviseurs SNMP
 Le rôle d'un superviseur (NMS) SNMP est de :
 présenter (si possible de manière graphique), une vue de l'infrastructure
supervisée avec l'état des différents équipements qui la composent.
 Dans les grosses infrastructures, il est courant que le superviseur SNMP
affiche son écran sur un mur d'images dans la salle de supervision ;
 communiquer avec les différents agents SNMP pour récupérer
régulièrement les différents états des équipements ;
 réagir en conséquence lorsqu'une variable de la MIB sort des limites
définies par l'opérateur (engorgement du réseau, taux de remplissage
du disque dur...).
 On peut définir les actions à réaliser en cas de réaction automatique
(envoi d'un mail par exemple). Le comportement le plus courant d'un
superviseur SNMP sera de modifier la couleur de l'équipement en cause
pour alerter visuellement l'opérateur ;
 recevoir en temps réel les messages SNMP "Trap" ou "Inform" en
provenance des équipements et modifier l'affichage général en
conséquence pour refléter le nouvel état ;
 prendre en compte l'évolution de l'infrastructure en permettant l'ajout
de nouveaux équipements dans le périmètre de supervision.
Exemples de
superviseurs SNMP :
 HP OpenView (désormais Network Node Manager). C'est
une solution payante, référence en matière de supervision
réseau ;
 Nagios (anciennement appelé Netsaint). C'est une
application permettant la surveillance système et réseau.
Elle surveille les hôtes et services spécifiés, alertant
lorsque les systèmes vont mal et quand ils vont mieux.
C'est un logiciel libre sous licence GPL ;
 Zabbix. C'est un logiciel open source créé par Alexei
Vladishev qui permet de surveiller le statut de divers
services réseau, serveurs et autres matériels réseau ;
 Multi Router Traffic Grapher (MRTG). C'est un logiciel
développé sous licence GNU/GPL à l'initiative de Tobi
Oetiker. Ce logiciel permet de créer des graphiques sur le
trafic réseau. Il utilise le protocole SNMP pour interroger
des équipements réseau tels que des routeurs, des
commutateurs, ou des serveurs, disposant d'une MIB ;
 Centreon. C'est un logiciel de surveillance et de
Exemples de superviseurs
SNMP :
 Vigilo. C'est un logiciel de supervision capable de gérer des
systèmes hétérogènes (autant réseau que serveurs) de grande
taille grâce à une architecture répartie et modulaire construite
autour de Nagios.
 BMC ProactiveNet Performance Management (anciennement
BMC Patrol). C'est une solution de supervision payante dont
l'éditeur estBMC Software.
 OpenNMS. OpenNMS est une plateforme de management et de
supervision réseau développé dans le cadre du logiciel libre ou le
modèle open source. Il dispose d'une communauté ainsi que
d'une organisation offrant des services commerciaux, de
formation et de soutien.
 NerveCenter. NerveCenter est une plateforme de gestion de
réseau qui permet aux responsables informatiques de facilement
et rapidement détecter et corriger les problèmes qui affectent les
réseaux distribués d'aujourd'hui.
 NetView. NetView est une solution de gestion réseau distribué
développée par IBM Tivoli.
 WhatsUpGold. WhatsUpGold est une solution payante de
Le standard ASN.1
 Avec SNMP, tout est ASN.1 (Abstract
Syntax Number 1).
 ASN.1 est un standard international
spécifiant une notation destinée à décrire
des structures de données.
 La description en ASN.1 d'une structure
de données a pour but d'obtenir une
spécification de la structure qui est
indépendante d'un encodage lié à un
matériel particulier et sans ambiguïté.
 Les trames transportées par le réseau
sont aussi codées en ASN.1.
La communication SNMP
 Le protocole SNMP est un protocole réseau qui
comporte différentes requêtes.
 Ces requêtes sont regroupées en 3 familles :
 les messages du superviseur SNMP vers l'agent SNMP ;
 les messages de l'agent SNMP vers le superviseur SNMP ;
 les messages entre agents SNMP.

 Le protocole SNMP est un protocole qui utilise UDP.

 Traditionnellement, les ports suivants sont utilisés :
 l'agent SNMP utilise le port UDP 161 pour recevoir les
messages "Get Request", "Get Next Request" et "Set
Request" ;

 le superviseur SNMP utilise le port UDP 162 pour recevoir

les messages "Trap", "Notification" et "Inform".
La communication SNMP
La communication SNMP :
Messages du superviseur vers l'agent
 Les messages envoyés par le superviseur SNMP vers
l'agent SNMP sont :
 Message "Get Request" : ce message permet au
superviseur d'interroger un agent sur les valeurs d'un ou
de plusieurs objets de la MIB ;
 Message "Get Next Request" : ce message permet au
superviseur d'interroger un agent pour obtenir la valeur
de l'objet suivant dans l'arbre des objets de l'agent. Ce
message permet de balayer des objets indexés de type
tableau ;
 Message "Get Bulk Request" : introduite avec la
version 2 du protocole SNMP, ce message permet de
mixer les messages "Get Request" et "Get Next
Request" pour obtenir des blocs entiers de réponses de
la part de l'agent ;
 Message "Set Request" : ce message permet au
La communication SNMP :
Messages de l'agent vers le
superviseur
 Les messages envoyés par l'agent SNMP vers le superviseur
SNMP sont :
 Message "Get Response" : ce message est utilisé par l'agent pour
répondre aux messages "Get Request", "Get Next Request" et
"Get Bulk Request" envoyés par le superviseur ;
 Message "Trap" : ce message est envoyé par l'agent à son
superviseur de manière asynchrone pour signaler un événement, un
changement d'état ou un défaut. L'agent n'attend pas d'acquittement
de la part du superviseur ;
 Message "Notification" : introduit avec la version 2 du protocole
SNMP, ce message est similaire au message "Trap". Il est envoyé par
l'agent à son superviseur de manière asynchrone 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 ;
 Message "Inform" : introduit avec la version 2 du protocole SNMP, ce
message est envoyé par l'agent à son superviseur de manière
asynchrone pour signaler un événement, un changement d'état ou un
défaut. L'agent attend un acquittement de la part du superviseur et il
y aura une retransmission en cas de non réponse.
La communication SNMP :
Messages entre
agents
 Le seul message envoyé entre les
agents SNMP est :
 Message "Report" : introduit avec la
version 2 du protocole SNMP mais jamais
implémenté, ce message permet aux
différents agents de communiquer entre
eux (principalement pour remonter des
problèmes de traitement des messages
SNMP).
La sécurité dans SNMPv3
 La sécurité apportée par la version 3 de SNMP repose sur les
concepts suivants :
 le modèle USM (User-based Security Model). Ce modèle est
défini par le RFC 3414 ;
 le modèle VACM (View-based Access Control Model). Ce modèle
est défini par le RFC 3415.
 Trois mécanismes sont utilisés par le modèle USM. Chacun de ces
mécanismes a pour but d'empêcher les attaques suivantes :
 l'authentification, qui permet d'empêcher la modification d'un
paquet SNMPv3 en cours de route et de valider le mot de passe
de la personne qui transmet la requête ;
 le cryptage, qui permet d'empêcher la lecture des informations
de gestions contenues dans un paquet SNMPv3 ;
 l'estampillage du temps qui permet d'empêcher la réutilisation
d'un paquet SNMPv3 valide a déjà transmis.
 Le modèle VACM quant à lui, permet de contrôler l'accès aux
variables de la MIB en restreignant leur accès en lecture ou en
écriture pour un groupe d'utilisateurs ou pour un utilisateur
spécifique.
La sécurité dans SNMPv3 :
authentification
 Les étapes d'authentification sont les suivantes :
 Le transmetteur groupe des informations à transmettre avec le
mot de passe.
 On passe ensuite ce groupe dans la fonction de hachage à une
direction.
 Les données et le code de hachage sont ensuite transmis sur le
réseau.
 Le receveur prend le bloc des données, et y ajoute le mot de
passe.
 On passe ce groupe dans la fonction de hachage à une
direction.
 Si le code de hachage est identique à celui transmis, le
transmetteur est authentifié.
La sécurité dans SNMPv3 :
cryptage
 Le cryptage a pour but d'empêcher que quelqu'un n'obtienne les informations de
gestion en écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre.
 Avec SNMPv3, le cryptage de base se fait sur un mot de passe « partagé » entre le
manager et l'agent.

 Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour
l'authentification et un pour le cryptage.
 Ceci permet au système d'authentification et au système de cryptage d'être
indépendants.

 SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le cryptage.
La sécurité dans SNMPv3 :
l’estampillage
 Si une requête est transmise, les mécanismes
d'authentification et de cryptage n'empêchent pas
quelqu'un de saisir un paquet SNMPv3 valide du
réseau et de tenter de le réutiliser plus tard, sans
modification.

 On appelle ce type d'attaques le « Replay Attack ».

 Pour éviter ceci, le temps est estampillé sur chaque

paquet. Quand on reçoit un paquet SNMPv3, on
compare le temps actuel avec le temps dans le
paquet.
 Si la différence est plus que supérieur à 150
secondes, le paquet est ignoré.
La MIB ?
 La MIB est la base d'informations de gestion. Il y est :
• des informations à consulter,
• des paramètres à modifier,
• des alarmes à émettre...
 SNMP permet de retrouver les informations et
d'agir sur les paramètres de façon
indépendante du matériel, comme du logiciel.

 La MIB se présente comme une base de données

normalisée, qui permettra de lire et d'écrire sur les
équipements distants, de façon également
normalisée.

 L'agent quant à lui se chargera de faire la

traduction entre les informations transmises par
SNMP et la plate-forme.
Structure de la MIB
 La structure de la MIB est hiérarchique.
 les informations sont regroupées en arbre.
 Chaque information a un object identifier qui est
une suite de chiffres séparés par des points, qui
l'identifie de façon unique et un nom, indiqué dans
le document qui décrit la MIB.
 Par exemple, [Link].[Link].1.2 est l'object
identifier ifDescr qui est la chaîne de caractères
décrivant une interface réseau.
Arbre MIB
MIB propriétaires
 L'arbre de la MIB, contient une branche particulière
qui est "private enterprises" (OID [Link].4.1).
 Cette branche permet aux différentes entreprises
de gérer leurs MIB spécifiques.
 Chaque entreprise se voit attribuer un OID unique
et elles ont ensuite le droit de décrire leurs OID
spécifiques en dessous de leur OID d'entreprise.
 La gestion de la branche d'une entreprise est
entièrement laissée à cette entreprise.
 Les différents OID d'entreprises sont alloués par
l'IANA. On retrouve par exemple :
 Cisco avec un OID [Link].4.1.9 ;
 HP avec [Link].4.1.11 ;
 Novell avec [Link].4.1.23 ;
 es P
i q u M
a t S N
p r d e
u x o n
va a ti
T r a n t
m e
p lé
Im
Le standard RMON
 Le standard RMON (Remote network
Monitoring) est fondé sur l’utilisation de
SNMP.

 Le standard RMON définit des jeux de

compteurs de trafic et de fonctions qu’il
rassemble dans des groupes numérotés et
spécifiés dans des fichiers MIB.

 RMON se décline en deux

versions, RMON1 et RMON2, pour couvrir
les 7 couches du modèle OSI.
Le standard RMON1
 Le standard RMON 1 a été créé initialement pour
avoir des informations sur les échanges réseau dans
les couches physique et liaison et prend en charge
les protocoles Ethernet et Token Ring.
 Le standard RMON1 est défini par le RFC 1757 de
l’IETF.
 Une sonde RMON ou un commutateur Ethernet
prenant en charge le standard RMON1 fournit des
statistiques sur le(s) segments Ethernet :
 Quantité de paquets et d’octets reçus et transmis
globalement sur le segment.
 Quantité de paquets de broadcast, de multicast et
d’erreurs globalement sur le segment.
 Tailles des paquets et répartition
 Quantité de paquets et d’octets reçus et transmis par
une adresse Ethernet (MAC).
Le standard RMON2
 Le standard RMON version 2 a étendu l’analyse du trafic
réseau de RMON1 limité au niveau Ethernet aux
protocoles de niveau supérieur.
 Le standard RMON2 est défini par le RFC 2021 de l’IETF.
 Des informations statistiques sont disponibles comme :
 Quantité de paquets et d’octets reçus et transmis par protocole
de transport (IP, IPX, AppleTalk etc.).
 Quantité de paquets et d’octets reçus et transmis par un host IP
(adresse IP).
 Quantité de paquets et d’octets reçus et transmis pour une
paire d’adresses IP dans le sens source vers destination.
 Quantité de paquets et d’octets reçus et transmis pour une
paire d’adresses IP dans le sens destination vers source.
 Quantité de paquets et d’octets reçus et transmis par un host IP
(adresse IP) pour une application identifiée par le port TCP/UDP.
 …..
Le protocole CMIP
 Le CMIP (Common Management Information Protocol) est un
protocole de gestion développé par ISO pouvant fonctionner sur
des réseaux hétérogènes.

 Nous pouvons le comparer au SNMP sur le fait que les deux

protocoles se servent de tables MIB pour effectuer leur travail.
D’ailleurs, le CMIP a été construit à partir du SNMP.
 Par contre, leur fonctionnement est plutôt différent puisque dans
le protocole CMIP, la station s’occupant de la gestion ne va pas
chercher elle-même les informations; elle attend que les stations
rapportent leur état.

 SNMP n'alourdit pas beaucoup la charge du système.

 CMIP a besoin de dix fois plus de ressources et est donc supporté
par beaucoup moins de réseaux.

 Le SNMP demeure donc le protocole de gestion le plus utilisé

puisqu’il est simple à implanter et configurer, malgré qu’il
entraîne un trafic plus élevé sur le réseau.