Formation échiquéenne jwhyCHESS, parallèle avec la planification de projet
Snmp
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
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
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
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
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
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
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
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
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
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
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
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
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
Notes de l'éditeur
Le terme SNMP englobe l‘ensemble des SMIs, MIBs et des protocoles.
NMS: Network Management System
Représenter rapidement le réseaux qui correspond à cette table..
Ceci est nécessaire pour les objets intermédiaires qui n’ont pas de feuilles. Pour les autres voir plus loin…
– « Sequence » : R outeEntry ::= SEQUENCE {dest IpAddress, next IpAddress}: Séquence de définitions de cette liste – “ Sequence of” : RouteTable ….. SEQUENCE of r outeEntry : Séquence d ’OID
OBJECT-TYPE IpAddress, read-write, current doivent appartenir au domaines définis par la SMI ( Structure of Management Information ) OID: parent+rang dans les fils (My-Mib + 1 voir page 58)
Attention différence entre routeEntry et RouteEntry
Donner la définition de MacAddress par exemple
C‘est le troisième groupe du groupe MyGroups
RFC1212 c’est presque SMIv2
Snmp utilise le protocole UDP pour envoyer ses messages (port 161 sur l’agent et port 162 sur le manager pour envoyer les messages). Pourquoi pas TCP ? : va surement alourdir pour rien le réseau avec tous ses mécanismes de contrôle
Error index: si la requête contient plusieurs variables (sous-requête), laquelle a échoué …