Présentation des dérivateurs du protocole SNMP (Simple Network Management Protocol)
Contenu
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 au moyen d'un message SNMP non sollicité.
Dans ce schéma, la configuration de gauche montre un système d'administration 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 de réseau (NMS).
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
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.
Utilisation des interruptions SNMP
SNMPv1 (Simple Network Management Protocol) et SNMPv2c, ainsi que la base d'informations de gestion (MIB) associée, encouragent les notifications d'interruptions.
L'idée derrière la notification dirigée par déroutement est que si un responsable est responsable d'un grand nombre de périphériques et que chaque périphérique a un grand nombre d'objets, il est impossible pour le responsable d'interroger ou de demander des informations de chaque objet sur chaque périphérique. La solution est que chaque agent du périphérique géré informe le responsable sans sollicitation. Pour ce faire, il envoie un message appelé déroutement de l'événement.
Une fois que le responsable a reçu l'événement, il l'affiche et peut choisir d'effectuer une action en fonction de l'événement. Par exemple, le responsable peut interroger directement l'agent ou interroger d'autres agents de périphérique associés pour mieux comprendre l'événement.
La notification par déroutement peut entraîner des économies substantielles sur les ressources du réseau et des agents 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.
-
Adresse de l'agent : 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 nombreux codes de déroutement 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 une unité de données de protocole. Chaque liaison de variable associe une instance d'objet MIB particulière à sa valeur actuelle.
Les interruptions génériques standard sont les suivantes : coldStart, hotStart, 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 pièges spécifiques au fournisseur, le champ Type de piège générique est défini sur EnterpriseSpecific(6). Cisco a mis en oeuvre ses propres pièges de manière non conventionnelle. Au lieu d'avoir le champ de déroutement Enterprise toujours le sysObjectID et 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 des déroutements à l'aide de différents champs de code de déroutement Enterprise et Specific. Vous pouvez voir les valeurs réelles à partir de l'Explorateur d'objets SNMP . En outre, Cisco a redéfini certains pièges génériques dans la MIB CISCO-GENERAL-TRAPS avec l'ajout de variables plus liées. Pour ces déroutements, le type de déroutement générique est conservé et n'est pas défini sur EnterpriseSpecific(6).
Dans le déroutement SNMPv2c 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 interruptions. Pour les déroutements génériques, les valeurs sont définies dans RFC 1907, pour les déroutements spécifiques au fournisseur snmpTrapOID est essentiellement une concaténation du paramètre SNMPv1 Enterprise et de deux sous-identificateurs supplémentaires, '0', et du paramètre de code déroutement spécifique SNMPv1. -
VarBindList : liste de liaisons de variables.
Pour qu'un système de gestion puisse comprendre un déroutement envoyé par un agent, le système de gestion doit savoir ce que l'identificateur d'objet (OID) définit. Par conséquent, la base MIB de ce déroutement doit être chargée. Ceci fournit les informations OID correctes afin que le système d’administration de réseau puisse comprendre les interruptions qui lui sont envoyées.
Pour les déroutements qui sont pris en charge par les périphériques Cisco dans des MIB spécifiques, reportez-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 bases MIB sont prises en charge sur votre périphérique Cisco, visitez le site www.cisco.com/go/mibs . La base MIB doit être chargée dans votre système de gestion de réseau. On parle généralement de compilation. Reportez-vous au guide de l'utilisateur de Network Management System (par exemple, HP OpenView ou NetView) sur la compilation MIB sur votre plate-forme NMS. Reportez-vous également à SNMP : Foire aux questions sur les bases MIB et les compilateurs MIB et le chargement des bases MIB.
En outre, un périphérique n’envoie pas de déroutement à un système d’administration de réseau, sauf s’il est configuré pour le faire. Un périphérique doit savoir qu'il doit envoyer un déroutement. La destination de 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 pièges à envoyer. Pour plus d'informations sur la configuration d'un périphérique Cisco pour SNMP et sur l'envoi d'interruptions, reportez-vous aux guides de configuration des périphériques correspondants et au Guide de mise en oeuvre de la NMS de numérotation de base, aux interruptions SNMP de Cisco IOS prises en charge et à la façon de les configurer et à la prise en charge et à la configuration des interruptions SNMP de Cisco CatalystOS.
Remarque : le gestionnaire reçoit généralement des notifications SNMP (TRAP et INFORM) sur le numéro de port UDP 162.
Exemples d'interruptions envoyées par Cisco IOS
Cette section contient quelques exemples de déroutements envoyés par Cisco IOS, pris avec le paquet debug snmp.
Interruption générique SNMPv1, redéfinie 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 de Cisco de la MIB CISCO-GENERAL-TRAPS avec quatre variables liées. Il comporte les champs suivants :
-
Entreprise = produits.45 (sysObjectID
du périphérique envoyant un déroutement, dans cet exemple, il s'agit d'un routeur c7507) -
Type de déroutement générique = 3 (linkUp)
-
Code de déroutement spécifique = 0
Interruption spécifique de SNMPv1 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 piège spécifique de Cisco clogMessageGenerated de CISCO-SYSLOG-MIB avec cinq variables liées. Il comporte les champs suivants :
-
Entreprise = valeur d'entreprise du piège clogMessageGenerated
-
Type de déroutement générique = 6 (spécifique à l'entreprise)
-
Code de déroutement spécifique = 1 (code de déroutement spécifique de clogMessageGenerated)
Interruption spécifique de SNMPv2c 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
Cette sortie montre la notification SNMPv2c ciscoConfigManEvent de Cisco spécifique de CISCO-CONFIG-MAN-MIB avec trois variables liées :
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é exécutée 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.
Commentaires