1. II. SNMP
1. Architecture SNMP
2. Le protocole SNMP
3. Les bases d’information: MIB
4. La représentation des données
5. Les Messages SNMP

2. Introduction
 Les réseaux IP ont connu un essor important
concevoir très rapidement des outils de gestion des réseaux TCP/IP.
 SNMP domine actuellement dans le monde TCP/IP où il est le
standard recommandé depuis mai 1990.
 Son modèle d'architecture repose sur un ensemble de composants:
de réseau (nœuds ou agents)
de stations d'administration (station de gestion ou manager).
 Les managers sont chargés de surveiller les nœuds du réseau.
 Le rôle du protocole SNMP est de véhiculer les informations de
gestion entre managers et nœuds du réseau.
2

3. Objectifs de conception
 Intégration aussi simple que possible de la fonction de gestion dans les
éléments de réseaux
Petite taille de code
Agents légers à cause du nombre limité de fonctions
La complexité est reportée vers les Managers (stations de gestion)
 Indépendance de l‘architecture du réseau et des types d‘éléments
Utilisable aussi bien dans les imprimantes, PCs ou serveurs
 Facilement extensible
Définition de nouveaux modules de MIBs
 Robustesse
Ne nécessite qu‘un service de transport simple et orienté sans connexion
Fonctionne même si le réseau subit de graves problèmes.
3

4. STANDARDS impliqués
SMI: Structure of Management Information
RFC 1155
MIB-II: Management Information Base
RFC 1213
Un grand nombre de MIB additionnelles existe
SNMP: Simple Network Management Protocol
RFC 1157
Nouvelles versions : SNMPv2 et SNMPv3
4

5. Historique
Première version en 1989
Pas de sécurité
MIB version 1 assez simple
Deuxième version en 1993
Sécurisé (chiffrement, authentification)
Admet l’administration distribuée
Complète la MIB ( MIB-2)
Ajoute un agent RMON à la MIB-2
Ajoute une sous-MIB Manager-to-Manager
SNMPv3 (1998)
Modulaire
Renforce la sécurité
5

6. Architecture
SNMP (Simple Network Management Protocol) est un protocole
de gestion de réseau.
Il part du principe qu'un système d'administration réseau se
compose:
de nœuds administrés (MN = Managed Node) chacun contenant un
agent.
 Les agents sont les serveurs.
d'au moins une station d'administration. (NMS = Network
Management Station).
 Cette station d'administration est le Client
d'un protocole réseau utilisé par la NMS et les agents pour échanger
des informations d'administration. (ici SNMP)
6

7. SNMP – Architecture générale
Manager SNMP
Réseau
Protocole d‘échange IP
d‘information de gestion
Information de gestion
Eléments de réseaux
A A A A=Agent
7

8. SNMP - éléments principaux
NMS
Agent SNMP
SNMP
SNMP
Objets SNMP (MIB)
Ex:
-Segments TCP envoyés
-Datagrammes IP reçus
SNMP
Agent
Agent
Agent
Agent mandataire
8

9. Plan Architectural
9

10. Agent mandataire (Proxy)
L'utilisation de SNMP suppose que tous les agents et les stations
d'administration supportent IP et UDP.
 Ceci limite l'administration de certains périphériques qui ne
supportent pas la pile TCP/IP.
 De plus, certaines machines (ordinateur personnel, station de
travail, contrôleur programmable, ... qui implantent TCP/IP
pour supporter leurs applications, mais qui ne souhaitent pas
ajouter un agent SNMP.
=> utilisation de la gestion mandataire (les proxies)
 Un agent SNMP agit alors comme mandataire pour un ou
plusieurs périphériques
10

11. Agent mandataire (Proxy)
11

12. Information d’administration
 Chaque entité gère des variables décrivant son état.
 Une variable est appelée objet.
 L’ensemble des objets d’un réseau se trouve dans la MIB (Management
Information Base)
 Exigences
 Modélise l‘élément de réseau qu‘elle représente
 Importante pour l‘administration d‘un élément de réseau
 Pas propriétaire ou spécifique à un fournisseur d‘équipements
 “Standardisable”
 En plus
 Offre les opérations de lecture et d‘écriture et parfois d‘autres supplémentaires
 Notifie par un message d‘alarme lorsqu‘elle dépasse une valeur de seuil ou dans
des situations critiques
12

13. Généralités
Objet géré :
Unité d’information représentant l’état des ressources gérées.
Management Information Base (MIB) :
Spécification d’un ensemble structuré d’objets.
Extensibilité :
MIB Propriétaire : Efficacité de gestion des équipements d’un
constructeur.
MIB utilisateur : Gestion de l’environnement d ’un utilisateur
13

14. Managed Object (MO)
Opérations Managed
Object Comportement
Réponses/Notifications
 Exemples de Managed Objects d‘une imprimante
Attributs
 Etat actuel (prête, imprime, problème, …)
 Etat du Toner (normal, bas, vide)
 Nombre total de pages imprimées
 Informations sur le Job actuel (Utilisateur, taille, …)
Opérations supplémentaires
 Impression d‘une page de tests, mettre Offline, …
14

15. Management Information Base (MIB)
Définition
La Management Information Base (MIB) est une collection de
Managed Objects qui représente l’élément de réseau.
Un élément de réseau contient usuellement plusieurs modules.
Chaque MO fait partie d’un groupe et un ensemble de groupes
forme un module.
Nommage unique de chaque MO à l‘intérieur de la MIB
La MIB a une structure de nommage extensible pour être
complétée, à volonté, avec des modules standardisés ou privés.
Distinction entre la Définition d‘un module et son Instanciation
dans un élément de réseau
15

16. MIB: Espace de nommage global
ccitt (0) iso (1) joint-iso-ccitt (2)  Chaque MO est identifié dans un
espace de nommage global et
registration member- identified- hiérarchique (arbre inversé).
standard (0)
authority (1) body (2) organization (3)
 Les noeuds servent à structurer
… dod (6) … en groupes et en modules.
internet (1)
 Chaque MO est une feuille de
directory (1) management (2) experimental (3) private (4) l‘arbre.
…
mib-2 (1)
system (1)
…
sysDescr (1) sysObjID (2) sysUpTime (3) …
16

17. MIB: Nommage des MOs (I)
MY-MIB
(1)
address (1) info (2)
134.21.1.15
name (1) uptime (2)
server-1 12345
 Exemples
 Nommage d‘un MO de type scalaire
 .1.1.0 ⇒ 134.21.1.15
 Par concaténation des identificateurs de la  .1.2.1.0 ⇒ “server-1“
 .1.2.0 ⇒ ERREUR
racine à l‘objet et en rajoutant un 0 à la fin. Alternative (symbolique):
 .MY-MIB.info.uptime ⇒ 12345
17

18. MIB : Nommage des MOs (II)
MY-MIB
(1)
address (1) info (2) routeTable (3)
134.21.1.15
name (1) uptime (2) dest (1) next (2)
server-1 12345
2 2
3 3
 Nommage des entrées d‘une table 5 2
7 2
 Au lieu du 0 final, les valeurs des variable(s)
8 3
qui forment l‘index de la table sont 9 3
rajoutées.
 Exemples:
 Une table est accédée séquentiellement,
 1.3.2.5 ⇒ 2
valeur par valeur et non pas dans son
ensemble.
 1.3.1.7 ⇒ 7
18

19. Nommage des entrées d’une table
Définition d’une colonne d’indexation.
 Exemple : La valeur de NEW-MIB routeTable next 5 est 2
19

20. Indexation d’une table
EXEMPLES:
OID de la Table = 1.3
1.3.1.5 => 5
1.3.2.5 => 2 1.3.1.1 => Entrée inexistante
1.3.1.9 => 9 1.3.2.1 => Entrée inexistante
1.3.2.9 => 3
1.3.2.7 => 2
20

21. Indexation d’une table
 Un index n’est pas nécessairement un entier : Ici
l’index est une adresse IP
 EXEMPLES: OID de la Table = 1.3
 1.3.1.130.89.16.23 => 130.89.16.23
 1.3.2.130.89.16.23 => 130.89.16.1
 1.3.1.193.22.11.97 => 193.22.11.97
 1.3.2.193.22.11.97 => 130.89.16.4
 1.3.2.130.89.19.121 => 130.89.16.1
21

22. Indexation multiple d’une table
Un index n’est pas toujours unique et par la suite on aura besoin
de définir plus qu’un index pour s’assurer de l’unicité de la
combinaison de ces index :
 Dans le cas d’une table de routage un noeud peut être atteint de
par différents chemins et par la suite l’indexation de la table sur
la seule adresse IP destination ne suffit plus.
22

23. Indexation multiple d’une table
Exemple:
23

24. SMI
La SMI (Structure of Management Information) spécifie les règles
de définition des ‘Managed Objects’ (MO) qui sont:
Variables typées simples (scalaires); elles peuvent être organisées en
tables à 2 dimensions au maximum
‘Basés objets’ mais pas orientées objets; les opérations offertes sont
uniquement la lecture et l’écriture
Spécifiés par un sous-ensemble de
Abstract Syntax Notation 1 (ASN.1, Version 1988)
Ces règles sont valables quelque soit le protocole de gestion
utilisé.
Un MO est défini par
Type (Syntax), mode d‘accès (Access), état de définition (Status),
description et un Identificateur unique…
24

25. Utilisation de SMI
SMI (Structure of Management Information)
Constitue un moyen normalisé de représenter des informations de
gestion :
Définition de la structure d’une MIB particulière
Définition de chacun des objets de la MIB (syntaxe et valeur)
Codage des valeurs d’objets
Définitions formelles en A.S.N.1 (Abstact Syntax Not.1)
25

26. La structure des informations d ’Administration
(SMI)
Un objet peut agréger plusieurs objets :
Object1
Object2
Object3 Object4
object3 Object Identifier {object2 1}
object4 Object Identifier {object2 2}
object2 Object Identifier {object1 1}
26

27. Définition d’un objet
 Un objet est défini par les champs suivants :
 Syntax : ce champ indique la syntaxe du type d’objet. La syntaxe doit être
définie dans les structures SMI.
 Max-Access : ce champ indique le niveau d’accès de cet objet.
 Status : le niveau de support que requiert cet objet.
 Description : contient une description textuelle de l’objet.
 Le nom et l’identificateur de l’objet sont écrits respectivement au début et
a la fin de la macro de définition de l’objet.
 Les noms de variables MIB sont extraits d ’un espace des noms
d’identificateurs d’objets gérés par l ’ISO et l ’UIT-T.
 La responsabilité des règles de nommage est décomposée, à chaque niveau,
en domaines
 Chaque groupe a la responsabilité du choix de certains noms sans avoir à
consulter l’autorité supérieure pour chaque décision.
27

28. SMI – Syntax
Definit les types simples des Managed Objects
28

29. SMI– Access/Status
 ACCESS/Opérations d’accès d‘un MO (SMIv1)
not-accessible – pour la définition des tables
read-only – modifiable uniquement par l‘Agent
read-write – modifiable aussi par le Manager
write-only – uniquement accès en écriture
Changements avec SMIv2
 Elimination de „write-only“
 Nouveau: „read-create“ pour créer des MO dans des tables
 STATUS/Etat de définition d‘un MO
mandatory– le MO doit être disponible/implémenté
optional – l‘implémentation du MO n‘est pas nécessaire
obsolete – le MO va disparaître à la prochaine version
Changements avec SMIv2
 “mandatory” remplacé par “current”
 „optional“ a été éliminé
29

30. Définition d’un objet scalaire
30

31. SMI – Exemples de définition
Définition d‘une Adresse (objet scalaire):
address OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESSread-write
STATUS current
DESCRIPTION "The Internet address of this system"
::= {MY-MIB 1}
31

32. Définition d’une table
Principe:
Une table de routage est une séquence d’entrée
Chaque entrée est composée d’une @source, d’une @dest et d’un
critère de choix.
32

33. Définition de la table de routage
routeTable OBJECT-TYPE
SYNTAX SEQUENCE OF routeEntry
MAX-ACCESS not-accessible
STATUS mandatory
DESCRIPTION "This entity’s routing table"
::= {NEW-MIB 3}
routeEntry OBJECT-TYPE
SYNTAX ligne
MAX-ACCESS not-accessible
STATUS mandatory
DESCRIPTION "A route to a particular destination"
INDEX {dest, policy}
::= {routeTable 1}
33

34. Définition d’une table (suite)
ligne::=
SEQUENCE {
dest ipAddress,
policy INTEGER,
next ipAddress}
RouteEntry est une séquence (liste) de deux adresses IP et d’un
entier
34

35. Définition d’une table (suite)
dest OBJECT-TYPE
SYNTAX ipAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "The address of a particular destination"
::= {route-entry 1}
policy OBJECT-TYPE
SYNTAX INTEGER {
costs(1) -- lowest delay
reliability(2)} -- highest reliability
ACCESS read-only
STATUS mandatory
DESCRIPTION "The routing policy to reach that destination"
::= {route-entry 2}
next OBJECT-TYPE
SYNTAX ipAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION “The internet address of the next hop"
::= {route-entry 3}
35

36. Définition de nouveaux types
 Utilisation des conventions textuelles (TEXTUAL CONVENTIONS) pour
raffiner la sémantique des types déjà existants.
 Exemple:
RunState ::= TEXTUAL CONVENTION
STATUS mandatory
DESCRIPTION "..."
SYNTAX INTEGER{
running(1)
runable(2)
waiting(3)
exiting(4)
}
36

37. Exemple d’une convention textuelle
 La convention Etat d’une ligne est utilisée pour faciliter le changement du
contenu d’une table:
 Exemples:
PhysAddress MacAddress
TruthValue AutonomousType
InstancePointer VariablePointer
RowPointer RowStatus
TimeStamp TimeInterval
DateAndTime StorageType
TDomain TAddress
37

38. Groupe d’objets
La construction d’un groupe d’objets permet de regrouper un
ensemble de types d’objets ayant une caractéristique en
commun.
Exemple:
myGroup3 OBJECT-GROUP
OBJECTS { address, name, uptime }
STATUS mandatory
DESCRIPTION "The collection of scalar objects."
::= { myGroups 3 }
38

39. Groupes de la MIB 2
39

40. MIB II
 Le module MIB-II (RFC 1213) définit les MOs pour la gestion de la
pile de protocoles Internet:
Amélioration par rapport au module MIB-I (RFC 1156)
Spécifie entre autres les groupes IP, ICMP, UDP, TCP et SNMP
Objectifs:
 Base pour la gestion des erreurs et de la configuration réseau
 Simple et intuitive car ne comporte que environ 170 MOs
 Utilise uniquement les types de données de base
 L‘implémentation du module ne doit pas influencer le
fonctionnement/comportement de l‘élément de réseau
 Problèmes
Quelques définitions sont trop limitées (Routing-Table, Interface-Table)
Les définitions des adresses ne supportent pas IPv6 (adresses codées sur 4
octets)
40

41. Enregistrement de la MIB-II
ccitt (0) iso (1) joint-iso-ccitt (2)
registration member- identified-
standard (0)
authority (1) body (2) organization (3)
… dod (6) …
internet (1)
directory (1) management (2) experimental (3) private (4) …
.1.3.6.1.2.1 mib-2 (1)
system (1) address icmp (5) udp (7) cmot (9) snmp (11)
translation (3)
interfaces (2) ip (4) tcp (6) egp (8) transmission (10) …
41

42. MIB-II – Groupe " system"
 Groupe actualisé dans RFC 1907 pour tenir compte de SNMPv2
 Information au sujet de l‘élément de réseau lui-même
 Disponible sur tous les agents:
 sysDescr: Nom de l‘équipement, version du SW et type de HW
 sysObjectID: Identification unique de l‘équipement, pointe dans le sous-arbre „enterprises“
 sysUpTime: Durée depuis le dernier redémarrage (en 1/100 sec.)
 sysContact: Nom et adresse de la personne responsable de l‘équipement
 sysName: Nom logique de l‘équipement (nom de domaine)
 sysLocation: Position géographique de l‘équipement
 sysServices: Indique quelles couches du modèle OSI sont supportées par l‘équipement
42

43. MIB-II – Groupe " interfaces"
 Actualisé dans RFC 2863
 Information des interfaces réseau de l‘équipement
 Disponible dans tous les agents
ifNumber: Nombre d‘interfaces réseau
ifTable: Table qui contient une ligne par interface; chaque
interface est décrite par:
 Index
 Description
 Type d‘interface (ex: 7=802.3, 15=FDDI)
 Caractéristiques telles que MTU (longueur des données dans la trame) ou débit
 Adresse physique
 Etat administratif et opérationnel (up/down/testing)
 Données statistiques (Compteurs de trames Ok, Errors, Discards, …; Compteurs d‘octets
transmis ou reçus)
 Référence vers des MOs spécifiques
43

44. MIB-II – Groupe " ip"
 Actualisé dans IP-MIB (RFC 2011)
 En même temps que le groupe „icmp“
 Information au sujet de l‘instance du protocole IP
 Disponible sur tous les agents:
 ipForwarding: indique si l‘équipement joue le rôle de router
 ipDefaultTTL: valeur par défaut TTL (Time-To-Live)
 Données statistiques au sujet du trafic IP
 Paquets reçus, erronés, transférés, délivrés aux couches supérieures, ...
 Données concernant la procédure de réassemblage de fragments
 Durée du temporisateur, nombre de paquets réassemblés correctement...
 ipAddrTable: Adresse IP, interface associée, Subnetmask, Adresse de diffusion,
etc.
 ipRouteTable: table de routage (inclus les métriques)
 ipNetToMediaTable: table associative entre adresses IP et Physiques (interface
réseau)
44

45. MIB-II – Groupes " TCP/UDP"
Groupe TCP
tcpRtoMin : valeur minimale de temporisation
tcpMaxConn : nombre maximum de connexions
tcpCurrEstab : nombre de connexions
tcpAttemptFails : nombre d ’échecs d ’ouverture de connexion
Groupe UDP
udpInDatagrams : datagrammes utilisateurs remis à la couche
supérieure
udpNoPorts : datagrammes utilisateurs destinés à un port inconnu
udpInErrs : datagrammes utilisateurs détruits pour cause d
’erreur de structure
45

46. MIB-II – Groupes…
 Groupe AT : table ARP
 Groupe ICMP : statistiques sur les types de paquets ICMP reçus,
envoyés et erronés
 Groupe TCP : nombre maximal de connexions simultanées
permises, nombre d’ouvertures actives…
 Groupe UDP : nombre de fragments UDP envoyés, reçus,
erronés…
 Groupe EGP (External Gateway Protocol) : nombre paquets
entrants, sortants, erronés, table des routeurs adjacents…
 Groupe Transmission : type de support de transmission
 Groupe SNMP : nombre de messages SNMP entrants et sortants,
nombre de mauvaises versions reçues ou de noms de communautés
erronés…
46

47. Vue globale
1. Un modèle architectural
2. Un modèle organisationnel
un ou plusieurs noeuds gérés (agent)
une ou plusieurs stations de gestion (gestionnaire)
1. Un modèle d ’informations
des informations de gestion (échanges agent/gestionnaire)
RFC 1155 (SMI), RFC 1212(Concise MIB definitions), RFC 1213
(MIB II)
1. Un modèle de communications
un protocole de gestion (échanges informations de gestion)
RFC 1157 (SNMP), RFC 1441 (SNMPv2), RFC 2271 (SNMPv3)
47

48. SNMP v1
48

49. Protocole d’administration
Il spécifie la nature des communications entre un programme
client, situé sur la station de gestion et un programme serveur
qui s'exécute sur un nœud.
La station d’administration interagit avec les agents :
Communication type requête/réponse.
L’agent est le serveur et le gestionnaire est le client.
Interrogation de l’état des objets locaux d’un agent.
Changement de l’état d’un objet.
49

50. Le protocole
50

51. Plan Architectural
51

52. Opérations du protocole SNMP
LECTURE : lit la valeur d ’une variable
 get-request, get-response
ECRITURE : affecte une valeur à une variable
 set-request
PARCOURS : pour connaître les variables effectivement gérées
par un noeud
 get-next-request, get-response
NOTIFICATIONS : pour signaler un événement extraordinaire
à un gestionnaire
 trap
52

53. Aperçu
53

54. Modèle Client / Serveur
54

55. Structure des messages SNMP v1
Structure générale
SNMP-Version
„Community-String“ – Pour l‘authentification (en clair!)
55

56. SNMPv1 – Community
Sécurité des accès aux informations de gestion
SNMP-Community
Décrit un groupe d'Agents et de Managers SNMP
L'authentification se fait à l‘aide de la "community-string" qui est
codée en clair dans chaque PDU
Valeur par défaut "public"
Définition dans chaque agent de "community profile" spécifiant les
opérations possibles sur une partie de la MIB pour une certaine
valeur de "community-string"
En général, les valeurs de "community-string" sont différentes pour
les accès en lecture et écriture à la MIB
Moyen d‘authentification peu fiable (Sniffing)
56

57. Format des PDUs
Get, Get-next, Response, Set :
Error Variable
PDU Type Request ID Error index
Status bindings
PDU Type: Identification du message
Request ID: Correspondance requête/réponse
Error status: Type d’erreur (réponse)
Error index: Correspondance erreur/variable (réponse)
Variable bindings: Correspondance variable/valeur
57

58. Champs des PDUs
Type de PDU Type d’erreur
58

59. GET
 Pour demander la valeur d’une ou plusieurs variables de la MIB.
Erreurs possibles :
noSuchName: L’objet n’existe pas / n’est pas une feuille
tooBig: Le résultat ne peut être écrit dans la PDU réponse
genErr: Pour les autres causes
59

60. Exemple de MIB
 Get (1.1.0)
 Response (1.1.0 => 130.89.16.2)
 Get (1.2.0)
 Response (error-status = noSuchName)
 Get (1.1)
 Response (error-status = noSuchName)
 Get (1.1.0; 1.2.2.0)
 Response (1.1.0 => 130.89.16.2; 1.2.2.0 => 123456)
 Get (1.3.1.3.5.1)
 Response (1.3.1.3.5.1 => 2)
 Get (1.3.1.1.5.1)
 Response (1.3.1.1.5.1 => 5)
 Get (1.3.1.1.5.1, 1.3.1.2.5.1, 1.3.1.3.5.1)
 Response (1.3.1.1.5.1 => 5, 1.3.1.2.5.1 => 1, 1.3.1.3.5.1 => 2)
60

61. SET
 Affecte une valeur à une variable sur un noeud donné. Elle permet aussi la
création et la suppression de variable :
 Exemple : Ligne d’une table
 Erreurs possibles :
 noSuchName
 badValue
 tooBig
 genErr
61

62. Exemples de SET
set(1.2.1.0 => my-printer)
response(noError; 1.2.1.0 => my-printer)
set(1.2.1.0 => my-printer, 1.2.3.0 => 0)
response(error-status = noSuchName; error-index = 2)
62

63. GET-NEXT
 Elle retourne le libellé de la variable se trouvant après la variable passée en
argument. Elle effectue un parcours infixé de l’arbre en ne s’arrêtant qu’aux
feuilles.
 => Découvrir la structure de la MIB
 => Découvrir les lignes d’une table
 Erreurs possibles :
 noSuchName (= END OF MIB)
 tooBig
 genErr
63

64. Exemples de GET-NEXT
 getNext(1.1.0)
response(1.2.1.0 => printer-1)
 getNext(1.2.1.0)
response(1.2.2.0 => 123456)
 getNext(1)
response(1.1.0 => 130.89.16.2)
 getNext(1.3.1.3.5.1)
response(1.3.1.3.5.2 => 3)
 getNext(1.3.1.1; 1.3.1.2; 1.3.1.3)
response(1.3.1.1.2.1 => 2; 1.3.1.2.2.1 => 1; 1.3.1.3.2.1 => 2)
 getNext(1.3.1.1.2.1; 1.3.1.2.2.1; 1.3.1.3.2.1)
response(1.3.1.1.3.1 => 3; 1.3.1.2.3.1 => 1; 1.3.1.3.3.1 => 3)
64

65. TRAP
Permet à un noeud géré d'envoyer un message à une station de
gestion lorsqu'un événement s'est produit sur le noeud.
La réception d’un TRAP n’est pas confirmée (UDP…)=> Le
polling de la station de gestion reste nécessaire.
Les agents peuvent être configurés tels que :
Aucun TRAP n’est envoyé.
Les TRAPS ne seront envoyés que vers certains managers.
65

66. Exemples de TRAP
 COLDSTART (0) : Initialisation de l'agent.
 WARMSTART (1) : Réinitialisation de l'agent.
 LINKDOWN (2) : Passage de l'interface à l'état bas.
 LINKUP (3): Passage de l'interface à l'état haut.
 AUTHENTICATION FAILURE (4): Emission par le manager d'une
communauté invalide.
 EGPNEIGHBORLOSS (5) : Un routeur voisin utilisant EGP (External
Gateway Protocol) est décalrée comme étant non focntionnel
 ENTERPRISESPECIFIC (6): champ spécifique pour avoir de
l'information.
66

67. SNMPv1 – Trap
 Trap PDU: Format
Version Community Partie spécifique de l‘opération
PDU- Enter- Agent Generic Specific Time Object Object … Object Object
Typ prise Address Trap ID Trap ID Stamp Name Value Name Value
 PDU-Type = 4
 Enterprise: Contient sysObjectID, l'identification unique de l'agent
 Agent Address: Adresse IP de l'Agent
 Generic Trap ID: Traps prédéfinis
 Specific Trap ID: à consulter si GenericTrap= ENTERPRISESPECIFIC
 Classification des Traps "enterpriseSpecific"
 TimeStamp: Contient sysUpTime, l'heure de l'alarme relative à l'agent
67

68. Exemple de Trap
 L ’adresse IP de agent émetteur : 132.18.54.21
 L ’objet concerné par la trap est : 1.3.6.1.4.1.20.1 (MIB privée)
 Type de de trap : link up
 Indication : les nombre de paquets reçu est 956340
 La dernière réinitialisation de l’agent : 6 heures passées.
68

69. Récapitulitif
69

70. Bibliographie
 « Pratique de la gestion de réseau», Nazim Agoulmine, Omar
Cherkaoui, mars 2003 edition Eyrolles
 « Network Management Fundamentals », Alexander Clemm, Cisco
Press, November 2006
 « Gestion de réseau et service », Noëmie Simoni, Simon Znaty,
InterEditions , Juin 1997
 Les Réseaux - Entraînez-vous à l'administration d'un réseau
2e édition José Dordoigne
 Réseaux Informatiques
Supervision et Administration Auteur : François PIGNET
70