Présentation des dérivateurs du protocole SNMP (Simple Network Management Protocol)

Introduction

Ce document fournit une introduction aux interruptions SNMP. Il démontre comment des interruptions SNMP sont utilisées et le rôle qu'elles jouent dans la gestion d'un réseau de données.

Les déroutements SNMP permettent à un agent d'avertir la station de gestion des événements importants par le biais d'un message SNMP non sollicité.

Dans ce schéma, la configuration de gauche montre un système de gestion de réseau qui interroge les informations et obtient une réponse. La configuration de droite montre un agent qui envoie un déroutement non sollicité ou asynchrone au système de gestion du réseau (NMS).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Utiliser les déroutements SNMP

Les protocoles SNMPv1 (Simple Network Management Protocol) et SNMPv2c, ainsi que la base MIB (Management Information Base) associée, encouragent la notification dirigée vers les déroutements.

L'idée derrière la notification dirigée par piège est que si un gestionnaire est responsable d'un grand nombre de périphériques, et que chaque périphérique a un grand nombre d'objets, il est peu pratique pour le gestionnaire d'interroger ou de demander des informations à chaque objet sur chaque périphérique. La solution consiste à ce que chaque agent sur le périphérique géré informe le gestionnaire sans sollicitation. Pour ce faire, il envoie un message appelé « déroutement de l'événement ».

Une fois l'événement reçu par le gestionnaire, ce dernier l'affiche et peut choisir d'effectuer une action en fonction de l'événement. Par exemple, le gestionnaire peut interroger directement l'agent ou interroger d'autres agents de périphérique associés pour mieux comprendre l'événement.

La notification dirigée par déroutement peut entraîner des économies substantielles en ressources réseau et d'agent en éliminant le besoin de requêtes SNMP frivoles. Cependant, il n'est pas possible d'éliminer totalement l'interrogation SNMP. Les requêtes SNMP sont requises pour la découverte et les modifications de topologie. En outre, un agent de périphérique géré ne peut pas envoyer de déroutement si le périphérique a subi une panne catastrophique.

Les déroutements SNMPv1 sont définis dans la RFC 1157, avec les champs suivants :

• Entreprise : identifie le type d'objet géré qui génère le déroutement.

• Agent address : fournit l'adresse de l'objet géré qui génère le déroutement.

• Type de déroutement générique : indique l'un des types de déroutement génériques.

• Specific trap code : indique l'un des codes d'interruption spécifiques.

• Horodatage : indique le temps écoulé entre la dernière réinitialisation du réseau et la génération du déroutement.

• Liaisons de variables : champ de données du déroutement qui contient l'unité de données de protocole. Chaque liaison de variable associe une instance d'objet MIB particulière à sa valeur actuelle.

Les pièges génériques standard sont : coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss. Pour les déroutements SNMPv1 génériques, le champ Enterprise contient la valeur sysObjectID du périphérique qui envoie le déroutement. Pour les déroutements spécifiques au fournisseur, le champ Type de déroutement générique est défini sur EnterpriseSpecific(6). Cisco a mis en oeuvre ses propres pièges spécifiques de manière non conventionnelle. Au lieu d'avoir le champ Enterprise déroutement toujours sysObjectID et d'avoir le code de déroutement spécifique pour identifier tous les déroutements spécifiques pris en charge par tous les périphériques Cisco, Cisco a mis en oeuvre l'identification de déroutement en utilisant divers champs Enterprise déroutement et Specific trap code. Vous pouvez voir les valeurs réelles à partir de l'Object Navigator SNMP. En outre, Cisco a redéfini certains pièges génériques dans la MIB CISCO-GENERAL-TRAPS avec l'ajout de variables liées supplémentaires. Pour ces déroutements, le type de déroutement générique est conservé et n'est pas défini sur enterpriseSpecific(6).

Dans SNMPv2c, le déroutement est défini comme NOTIFICATION et formaté différemment de SNMPv1. Il possède les paramètres suivants :

• sysUpTime : identique à l'horodatage dans le déroutement SNMPv1.

• snmpTrapOID : champ d'identification des déroutements. Pour les déroutements génériques, les valeurs sont définies dans la RFC 1907. Pour les déroutements spécifiques aux fournisseurs, snmpTrapOID est essentiellement une concaténation du paramètre SNMPv1 Enterprise et de deux sous-identificateurs supplémentaires, '0', et du paramètre SNMPv1 Specific trap code.

• VarBindList : il s'agit d'une liste de liaisons de variables.

Pour qu'un système de gestion puisse comprendre un déroutement qui lui est envoyé par un agent, il doit savoir ce que définit l'identificateur d'objet (OID). Par conséquent, la base MIB de ce déroutement doit être chargée. Elle fournit les informations OID correctes afin que le système de gestion du réseau puisse comprendre les déroutements qui lui sont envoyés.

Pour les déroutements qui sont pris en charge par les périphériques Cisco dans des MIB spécifiques, référez-vous à Cisco SNMP Object Navigator. Cette liste répertorie les déroutements disponibles pour une MIB spécifique. Pour recevoir l'un de ces déroutements, votre version du logiciel Cisco IOS® doit prendre en charge la MIB répertoriée. Pour savoir quelles MIB sont prises en charge sur votre périphérique Cisco, consultez le site www.cisco.com/go/mibs. La MIB doit être chargée dans votre système de gestion du réseau. Cette opération est généralement appelée compilation. Consultez le guide de l'utilisateur de votre système de gestion de réseau (par exemple, HP OpenView ou NetView) sur la compilation de MIB sur votre plate-forme NMS. Reportez-vous également à SNMP : Foire aux questions sur les MIB et les compilateurs MIB et le chargement des MIB.

En outre, un périphérique n'envoie pas de déroutement à un système de gestion du réseau, sauf s'il est configuré à cet effet. Un périphérique doit savoir qu'il doit envoyer un déroutement. La destination du déroutement est généralement définie par une adresse IP, mais peut être un nom d'hôte, si le périphérique est configuré pour interroger un serveur DNS (Domain Name System). Dans les versions ultérieures de la plate-forme logicielle Cisco IOS, les administrateurs de périphériques peuvent choisir les déroutements qu'ils souhaitent envoyer. Pour plus d'informations sur la façon de configurer un périphérique Cisco pour SNMP et sur la façon d'envoyer des déroutements, référez-vous aux guides de configuration des périphériques correspondants et au Basic Dial NMS Implementation Guide, Cisco IOS SNMP Traps Supported and How to Configure Them and How-To Support and Configure Cisco CatalystOS SNMP Traps.

Remarque : le gestionnaire reçoit généralement des notifications SNMP (TRAP et INFORM) sur le port UDP numéro 162.

Exemples de déroutements envoyés par Cisco IOS

Cette section contient quelques exemples de déroutements envoyés par Cisco IOS, pris avec debug snmp packet.

Déroutement générique SNMPv1, redéfini par Cisco :

Nov 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 

Ce résultat montre le déroutement linkUp redéfini par Cisco à partir de la base de données MIB CISCO-GENERAL-TRAPS avec quatre variables liées. Il comporte les champs suivants :

• Entreprise = products.45 (sysObjectID du périphérique envoyant le déroutement, dans cet exemple, il s'agit du routeur c7507)

• Type de déroutement générique = 3 (linkUp)

• Code de déroutement spécifique = 0

SNMPv1 Interruption spécifique à Cisco :

4d23h: SNMP: Queuing packet to 172.17.246.162 
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 

Ce résultat montre le trap spécifique à Cisco clogMessageGenerated de CISCO-SYSLOG-MIB avec cinq variables liées. Il comporte les champs suivants :

• Entreprise = valeur entreprise du trap clogMessageGenerated

• Type de déroutement générique = 6 (spécifique à l'entreprise)

• Code d'interruption spécifique = 1 (code d'interruption spécifique de clogMessageGenerated)

SNMPv2c Interruption spécifique à Cisco :

4d23h: SNMP: Queuing packet to 172.17.246.162 
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 

Ce résultat montre la notification ciscoConfigManEvent SNMPv2c spécifique à Cisco de CISCO-CONFIG-MAN-MIB avec trois variables liées :

• ccmHistoryEventCommandSource

• ccmHistoryEventConfigSource

• CcmHistoryEventConfigDestination

Ce déroutement peut être utilisé si des modifications ont été apportées à la configuration du périphérique. Les valeurs des deux derniers composants déterminent si une commande show a été émise ou si la configuration a été modifiée.

6506E#term mon
6506E#debug snmp packet
SNMP packet debugging is on

6506E#sh run
Building configuration...
...
6506E#
19:24:18: SNMP: Queuing packet to 10.198.28.80
19:24:18: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 6981747
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.100 = 1 

!--- 1 -> commandLine. Executed via CLI.

ccmHistoryEventEntry.4.100 = 3 

!--- 3 -> running

ccmHistoryEventEntry.5.100 = 2 

!--- 2 -> commandSource. Show command was executed.

6506E#term mon
6506E#debug snmp packet
SNMP packet debugging is on

6506E#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
6506E(config)#exit

22:57:37: SNMP: Queuing packet to 10.198.28.80
22:57:37: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0
 sysUpTime.0 = 8261709
 snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
 ccmHistoryEventEntry.3.108 = 1 

!--- 1 -> commandLine. Executed via CLI.

 ccmHistoryEventEntry.4.108 = 2 

!--- 2 -> commandSource

 ccmHistoryEventEntry.5.108 = 3 

!--- 3 -> running. Change was destined to the running configuration.

Informations connexes

• Assistance et documentation techniques - Cisco Systems