IP : Protocole SNMP (Simple Network Management Protocol)

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


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'informer la station de Gestion des événements significatifs par un message SNMP non sollicité.

Dans ce diagramme, l'installation du côté gauche affiche un système d'administration de réseaux que les informations de balayages et obtient une réponse. L'installation du côté droit affiche un agent qui envoie un déroutement non sollicité ou asynchrone au système d'administration de réseaux (NMS).

/image/gif/paws/7244/snmp_trap-01.gif

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour 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.

Déroutements SNMP d'utilisation

SNMPv1 (protocole SNMP) et SNMPv2C, avec le Management Information Base associé (MIB), encouragent la notification déroutement-dirigée.

L'idée derrière la notification déroutement-dirigée est que si un gestionnaire est responsable d'un grand nombre de périphériques, et chaque périphérique a un grand nombre d'objets, il est irréaliste que le gestionnaire de voter ou demander les informations de chaque objet sur chaque périphérique. La solution est pour chaque agent sur le périphérique géré pour informer le gestionnaire sans sollicitation. Il fait ceci en envoyant un message connu sous le nom de déroutement de l'événement.

Après que le gestionnaire reçoive l'événement, le gestionnaire l'affiche et peut choisir de prendre une mesure basée sur l'événement. Par exemple, le gestionnaire peut voter l'agent directement, ou votez d'autres agents de périphérique associé pour obtenir une meilleure compréhension de l'événement.

la notification Déroutement-dirigée peut avoir comme conséquence l'épargne substantielle des ressources en réseau et en agent en éliminant le besoin de demandes frivoles SNMP. Cependant, il n'est pas possible d'éliminer totalement l'interrogation SNMP. Des demandes SNMP sont exigées pour la détection et la topologie change. En outre, un agent de périphérique géré ne peut pas envoyer un déroutement, si le périphérique a eu une panne catastrophique.

Les déroutements SNMPv1 sont définis dans RFC 1157, avec ces champs :

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

  • Adresse d'agent — Fournit l'adresse de l'objet géré qui génère le déroutement.

  • Type générique de déroutement — Indique un d'un certain nombre de types génériques de déroutement.

  • Code spécifique de déroutement — Indique un d'un certain nombre de codes spécifiques de déroutement.

  • Groupe date/heure — Fournit la durée qui s'est écoulée entre la dernières réinitialisation de réseau et génération du déroutement.

  • Attaches variables — La zone d'information du déroutement qui contient le PDU. Chaque attache variable associe un exemple particulier d'objet MIB avec sa valeur courante.

Les déroutements génériques standard sont : coldStart, warmStart, linkDown, lien, authenticationFailure, egpNeighborLoss. Pour les déroutements SNMPv1 génériques, le champ d'entreprise contient la valeur du sysObjectID du périphérique qui envoie le déroutement. Pour les déroutements spécifiques de constructeur, le champ de type générique de déroutement est placé à enterpriseSpecific(6). Cisco a mis en application ses propres déroutements spécifiques d'une manière non conventionnelle. Au lieu de avoir le champ d'entreprise de déroutement toujours le sysObjectID et de avoir le déroutement spécifique codent pour identifier tous les déroutements spécifiques pris en charge par tous les périphériques de Cisco, Cisco a mis en application l'identification de déroutement utilisant la diverse entreprise de déroutement et les champs code spécifiques de déroutement. Vous pouvez voir les valeurs réelles du navigateur d'objet SNMP . En outre, Cisco a redéfini quelques déroutements génériques dans le MIB CISCO-GENERAL-TRAPS en plus de plus de variables attachées. Pour ces déroutements, le type générique de déroutement est maintenu les mêmes et pas placé à enterpriseSpecific(6).

Dans le SNMPv2C le déroutement est défini comme NOTIFICATION et formaté différemment comparé à SNMPv1. Il a ces paramètres :

  • sysUpTime — C'est identique comme groupe date/heure dans le déroutement SNMPv1.

  • snmpTrapOID — Champ d'identification de déroutement. Pour les déroutements génériques, des valeurs sont définies dans RFC 1907, parce que le snmpTrapOID de déroutements de particularité de constructeur est essentiellement un enchaînement du paramètre de l'entreprise SNMPv1 et deux sous-titre-identifiants supplémentaires, '0', et le paramètre de code spécifique du déroutement SNMPv1.

  • VarBindList — C'est une liste de variable-attaches.

Pour qu'un système de gestion comprenne un déroutement envoyé à lui par un agent, le système de gestion doit savoir ce que l'identifiant d'objet (OID) définit. Par conséquent, il doit avoir le MIB pour ce déroutement chargé. Ceci fournit les informations correctes OID de sorte que le système d'administration de réseaux puisse comprendre les déroutements envoyés à lui.

Pour les déroutements qui sont pris en charge par des périphériques de Cisco dans le MIB spécifique, référez-vous au navigateur d'objet SNMP de Cisco . Ceci répertorie les déroutements disponibles pour un MIB de particularité. Afin de recevoir un de ces déroutements, votre version logicielle de ½ du ¿  de Cisco IOSï doit prendre en charge le MIB répertorié. Afin de découvrir que le MIB est pris en charge sur votre périphérique de Cisco, visite www.cisco.com/go/mibs . Le MIB doit être chargé dans votre système d'administration de réseaux. Ceci désigné généralement sous le nom compilant. Voir le votre guide utilisateur de système d'administration de réseaux (par exemple, HP OpenView ou NetView) au sujet du MIB compilant sur votre plate-forme NMS. Référez-vous également au SNMP : Forums aux questions au sujet de MIB et de compilateurs MIB et de MIB de chargement.

Supplémentaire, un périphérique n'envoie pas un déroutement à un système d'administration de réseaux à moins qu'il soit configuré pour faire ainsi. Un périphérique doit savoir qu'il devrait envoyer un déroutement. La destination de piège est habituellement définie par une adresse IP, mais peut être un nom d'hôte, si le périphérique est installé pour questionner un serveur de Système de noms de domaine (DNS). Dans les versions ultérieures du Cisco IOS logiciel, les administrateurs de périphérique peuvent choisir que les déroutements qu'ils voudraient envoient. Pour les informations sur la façon dont configurer un périphérique de Cisco pour le SNMP, et la façon envoyer des déroutements, référez-vous aux guides de configuration correspondants de périphérique et au guide d'implémentation de base du cadran NMS, des pièges SNMP de Cisco IOS pris en charge et comment configurer eux et le support de Comment-Faire et configurer des déroutements SNMP de Cisco CatalystOS.

Remarque: Le gestionnaire reçoit typiquement des notifications SNMP (les déroutements et informe) sur le numéro de port UDP 162.

Exemples des déroutements envoyés par Cisco IOS

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

Déroutement SNMPv1 générique, 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 

Cette sortie affiche le déroutement de lien redéfini par Cisco du MIB CISCO-GENERAL-TRAPS avec quatre variables attachées. Il a ces champs :

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

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

  • Code spécifique de déroutement = 0

Déroutement spécifique 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 

Cette sortie affiche le déroutement clogMessageGenerated par particularité de Cisco de CISCO-SYSLOG-MIB avec cinq variables attachées. Il a ces champs :

  • Valeur d'entreprise = d'entreprise de déroutement clogMessageGenerated

  • Type générique de déroutement = 6 (enterpriseSpecific)

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

Déroutement spécifique de Cisco de SNMPv2C :

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 affiche à Cisco la notification ciscoConfigManEvent spécifique de SNMPv2C de CISCO-CONFIG-MAN-MIB avec trois variables attachées :

Ce déroutement peut être utilisé s'il y a eu des modifications faites à la configuration de périphérique. Les valeurs des deux derniers composants déterminent si une commande show était émise ou si la configuration était touché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


Document ID: 7244