Snmp

1,759 views

Published on

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,759
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
113
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 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é …
  • Snmp

    1. 1. II. SNMP1. Architecture SNMP2. Le protocole SNMP3. Les bases d’information: MIB4. La représentation des données5. Les Messages SNMP
    2. 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 darchitecture repose sur un ensemble de composants: de réseau (nœuds ou agents) de stations dadministration (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. 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. 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. 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. 6. ArchitectureSNMP (Simple Network Management Protocol) est un protocole de gestion de réseau.Il part du principe quun système dadministration réseau se compose: de nœuds administrés (MN = Managed Node) chacun contenant un agent.  Les agents sont les serveurs. dau moins une station dadministration. (NMS = Network Management Station).  Cette station dadministration est le Client dun protocole réseau utilisé par la NMS et les agents pour échanger des informations dadministration. (ici SNMP) 6
    7. 7. SNMP – Architecture générale Manager SNMP Réseau Protocole d‘échange IPd‘information de gestion Information de gestion Eléments de réseaux A A A A=Agent 7
    8. 8. SNMP - éléments principaux NMS Agent SNMP SNMP SNMPObjets SNMP (MIB)Ex:-Segments TCP envoyés-Datagrammes IP reçus SNMP Agent Agent Agent Agent mandataire 8
    9. 9. Plan Architectural 9
    10. 10. Agent mandataire (Proxy)Lutilisation de SNMP suppose que tous les agents et les stations dadministration supportent IP et UDP. Ceci limite ladministration 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. 11. Agent mandataire (Proxy) 11
    12. 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. 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. 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. 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. 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 dedirectory (1) management (2) experimental (3) private (4) l‘arbre. … mib-2 (1) system (1) … sysDescr (1) sysObjID (2) sysUpTime (3) … 16
    17. 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. 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. 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. 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. 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. 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. 23. Indexation multiple d’une tableExemple: 23
    24. 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. 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. 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. 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. 28. SMI – Syntax Definit les types simples des Managed Objects 28
    29. 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. 30. Définition d’un objet scalaire 30
    31. 31. SMI – Exemples de définitionDéfinition d‘une Adresse (objet scalaire): address OBJECT-TYPESYNTAX IpAddressMAX-ACCESSread-writeSTATUS currentDESCRIPTION "The Internet address of this system" ::= {MY-MIB 1} 31
    32. 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. 33. Définition de la table de routagerouteTable 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. 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. 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. 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. 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 MacAddressTruthValue AutonomousTypeInstancePointer VariablePointerRowPointer RowStatusTimeStamp TimeIntervalDateAndTime StorageTypeTDomain TAddress 37
    38. 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. 39. Groupes de la MIB 2 39
    40. 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. 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. 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. 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. 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. 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. 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. 47. Vue globale1. Un modèle architectural2. 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. 48. SNMP v1 48
    49. 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 sexé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. 50. Le protocole 50
    51. 51. Plan Architectural 51
    52. 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. 53. Aperçu 53
    54. 54. Modèle Client / Serveur 54
    55. 55. Structure des messages SNMP v1Structure générale SNMP-Version „Community-String“ – Pour l‘authentification (en clair!) 55
    56. 56. SNMPv1 – CommunitySécurité des accès aux informations de gestionSNMP-Community Décrit un groupe dAgents et de Managers SNMP Lauthentification 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. 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. 58. Champs des PDUs Type de PDU Type d’erreur 58
    59. 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. 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. 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. 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. 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. 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. 65. TRAPPermet à un noeud géré denvoyer un message à une station de gestion lorsquun événement sest 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. 66. Exemples de TRAP COLDSTART (0) : Initialisation de lagent. WARMSTART (1) : Réinitialisation de lagent. LINKDOWN (2) : Passage de linterface à létat bas. LINKUP (3): Passage de linterface à létat haut. AUTHENTICATION FAILURE (4): Emission par le manager dune 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 linformation. 66
    67. 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, lidentification unique de lagent  Agent Address: Adresse IP de lAgent  Generic Trap ID: Traps prédéfinis  Specific Trap ID: à consulter si GenericTrap= ENTERPRISESPECIFIC  Classification des Traps "enterpriseSpecific"  TimeStamp: Contient sysUpTime, lheure de lalarme relative à lagent 67
    68. 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. 69. Récapitulitif 69
    70. 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 à ladministration dun réseau 2e édition José Dordoigne Réseaux Informatiques Supervision et Administration Auteur : François PIGNET 70

    ×