Comprendre les Traps SNMP

Sommaire • Introduction • Utilisation de Traps SNMP • Exemples de Traps transmis par l'IOS Cisco

Introduction Ce document fournit une explication simplifiée des Traps SNMP. Il montre comment les Traps SNMP sont utilisés et le rôle qu'ils jouent dans la gestion de réseau. Les traps SNMP permettent à un agent de notifier, à une station de gestion, des évè- nements significatifs au moyen d'un message SNMP non sollicité. SNMP Trap SNMP GetRequest SNMP Response Dans la figure ci-dessus, l'échange de messages situé à gauche montre un système de gestion demandant une information et obtenant une réponse. L'échange situé à droite montre un agent transmettant un message Trap non sollicité ou "asynchrone" au sys- tème de gestion de réseau (Network Management Station). Utilisation de Traps SNMP SNMPv1 (Simple Network Management Protocol) et SNMPv2c en association avec la Management Information Base (MIB), encouragent l'utilisation la notification orientée Trap. L'idée derrière la notification non sollicitée est la suivante: si un gestionnaire est res- ponsable d'un grand nombre d'équipements et que chaque équipement à un grand nombre d'objets, il est impossible pour celui-ci de demander des informations sur cha- que objet de chaque équipement. La solution est pour chaque équipement géré, de no- tifier au gestionnaire sans attendre de sollicitation. Il fait cela en transmettant un mes- sage connu comme message Trap pour l'évènement. Après avoir reçu l'évènement, le gestionnaire l'affiche et peut choisir une action en fonc- tion de l'évènement. Par exemple, le gestionnaire peut interroger l'agent directement ou interroger d'autres agents d'équipements associés afin de mieux comprendre l'évène- ment. La notification de Traps peut entrainer une économie de ressources du réseau et de l'agent en éliminant les requêtes SNMP superflues. Cependant il n'est pas possible d'éliminer totalement l'interrogation SNMP. Les requêtes SNMP sont requises pour la découverte et les changements de topologie. De plus, un équipement géré ne peut plus transmettre de Traps si cet équipement n'est pas en état de fonctionner normalement.

Les Traps SNMPv1 sont définis dans le RFC 1157 avec les champs suivants: ● Enterprise - Identifie le type d'objet générant le Trap ● Agent Address - Fournit l'adresse de l'objet géré qui a généré le Trap. ● Generic trap type - Indique un des numéros de types de Traps générés. ● Specific Trap code - Indique un des numéros de codes de Traps spécifiques. ● Time Stamp - Fournit la durée écoulée entre la dernière réinitialisation réseau et la génération du Trap. ● Variable bindings - Champ données du Trap contenant la PDU. Chaque associa- tion de variable associe une instance d'objet MIB particulière à sa valeur courante. Les Traps génériques standards sont: coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeigghborLoss. Pour les Traps génériques SNMPv1, le champ Enterprise contient la valeur sysObjectID de l'équipement transmettant le Trap. Pour les Traps spécifiques d'un constructeur, le champ Generic trap type est fixé à enter- priseSpecific(6). Cisco a implémenté ses propres Traps spécifiques de manière non conventionnelle. Au lieu d'avoir le champ Enterprise du Trap avec le sysObjectID et le champ Specific trap code pour identifier tous les traps spécifiques supportés par les équipements Cisco, Cisco a implémenté l'identification de Traps en utilisant différents champs Enterprise et Specific trap code. Vous pouvez obtenir les valeurs actuelles à ftp://ftp.cisco.com/pub/mibs/traps/. Cisco a également redéfini quelques Traps génériques dans CISCO-GENERAL-TRAPS MIB en ajoutant plus de variables liées. Notez que pour ces Traps le Generic trap type est le même et n'est pas fixé à enterpri- seSpecific(6) . Dans SNMPv2c un Trap est défini comme NOTIFICATION et formaté différemment par rapport à SNMPv1. Il a les paramètres suivants: ● sysUpTime - Identique à TimeStamp du Trap SNMPv1. ● snmpTrapOID - Champ d'identification du Trap. Pour les Traps génériques, les va- leurs sont définies dans le RFC 1907. Pour les Traps spécifiques constructeur, le snmpTrapOID est essentiellement une concaténation du paramètre Enterprise SNMPv1 et de deux sous-identifieurs additionnels; "0" et le paramètre SNMPv1 Specific trap code. ● VarBindList - Liste de variables liées. Pour qu'un système de gestion comprenne un Trap transmis par un agent, le système de gestion doit connaître ce que le OID (Object Identifier) définit. Par conséquent il doit avoir la MIB chargée pour ce Trap. La MIB fournit l'information OID correcte ainsi le système de gestion réseau peut comprendre les Traps qu'il reçoit. Pour pouvoir recevoir les Traps spécifiques Cisco, le logiciel IOS Cisco doit supporter une MIB appropriée. Pour savoir quelles MIB sont supportées par votre équipement Cisco, visitez le site www.cisco.com/go/mibs. La MIB doit être chargée dans votre système de gestion réseau. Ceci est communément appelé compilation de MIB. Lisez le guide utilisateur de votre système de gestion (HP Open view ou Net View ) au sujet de la compilation de MIB sur votre plateforme NMS. De plus, un équipement ne transmet pas de Trap vers un équipement de gestion ré- seau sauf s'il est configuré pour cela. Un équipement doit savoir qu'il doit transmettre un Trap. La destination du Trap est usuellement définie par une adresse IP mais peut être un nom de host si l'équipement est paramétré pour faire une requête DNS (Domain Name system). Dans les versions récentes du logiciel IOS Cisco, les adminis- trateurs des équipements peuvent choisir quels Traps ils veulent transmettre.

Exemples de Traps transmis par l'IOS Cisco Cette section contient quelques exemples de traps transmis par l'IOS Cisco, et captu- rés avec la commande debug snmp packet. Trap SNMPv1 redéfini par Cisco May 21 07:44:17: %LINK−3−UPDOWN: Interface Loopback1, changed state to up 4d23h: SNMP: Queuing packet to 172.17.246.162 4d23h: SNMP: V1 Trap, ent products.45, addr 172.17.246.9, gentrap 3, spectrap 0 ifEntry.1.23 = 23 ifEntry.2.23 = Loopback1 ifEntry.3.23 = 24 lifEntry.20.23 = up Ci-dessus, le Trap linkUp redéfini par Cisco à partir de CISCO−GENERAL−TRAPS MIB avec quatre variables liées a les champs suivants: Enterprise = products.45 ( sysObjectID de l'équipement générant le Trap. Dans cet exemple c'est un routeur Cisco 7507. ● Generic trap type = 3 (linkUp) · ● Specific trap code = 0 · Trap SNMPv1 spécifique Cisco: 4d23h: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 172.17.246.9, gentrap 6, spectrap 1 clogHistoryEntry.2.954 = LINK clogHistoryEntry.3.954 = 4 clogHistoryEntry.4.954 = UPDOWN clogHistoryEntry.5.954 = Interface Loopback1, changed state to up clogHistoryEntry.6.954 = 43021184 Ci-dessus, le Trap spécifique Cisco clogMessageGenerated défini par CISCO−SYSLOG -MIB avec cinq variables liées a les champs suivants: ● Enterprise = Valeur Enterprise du Trap clogMessageGenerated ● Generic trap type = 6 (enterpriseSpecific) ● Specific trap code = 1 (Code du Trap spécifique clogMessageGenerated) Trap SNMPv2c spécifique Cisco: 4d23h: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0 sysUpTime.0 = 43053404 snmpTrapOID.0 = clogHistoryEntry.2.958 = SYS clogHistoryEntry.3.958 = 6 clogHistoryEntry.4.958 = CONFIG_I clogHistoryEntry.5.958 = Configured from console by vty0 (10.10.10.10) clogHistoryEntry.6.958 = 43053403 Ci-dessus, la notification SNMPv2c spécifique Cisco clogMessageGenerated défini par CISCO−SYSLOG-MIB avec cinq variables liées.