Grundlegendes zu SNMP (Simple Network Management Protocol)

Einleitung

Dieses Dokument bietet eine Einführung in SNMP-Traps. Es zeigt, wie SNMP-Traps verwendet werden und welche Rolle sie bei der Verwaltung eines Datennetzwerks spielen.

SNMP-Traps ermöglichen es einem Agenten, die Managementstation über wichtige Ereignisse mittels einer nicht angeforderten SNMP-Nachricht zu benachrichtigen.

In diesem Diagramm zeigt die Konfiguration auf der linken Seite ein Netzwerkmanagementsystem, das Informationen abfragt und eine Antwort erhält. Die Konfiguration auf der rechten Seite zeigt einen Agenten, der ein unerwünschtes oder asynchrones Trap an das Netzwerkmanagementsystem (NMS) sendet.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

SNMP-Traps verwenden

SNMPv1 (Simple Network Management Protocol) und SNMPv2c ermutigen zusammen mit der zugehörigen Management Information Base (MIB) zur Benachrichtigung über Traps.

Die Idee hinter der Trap-gesteuerten Benachrichtigung ist, dass, wenn ein Manager für eine große Anzahl von Geräten verantwortlich ist und jedes Gerät eine große Anzahl von Objekten hat, es für den Manager unpraktisch ist, Informationen von jedem Objekt auf jedem Gerät abzufragen oder anzufordern. Die Lösung besteht darin, dass jeder Agent auf dem verwalteten Gerät den Manager ohne Aufforderung benachrichtigt. Dazu sendet er eine Nachricht, die als Trap des Ereignisses bezeichnet wird.

Nachdem der Manager die Veranstaltung erhalten hat, zeigt er sie an und kann je nach Veranstaltung eine Aktion auswählen. So kann der Manager beispielsweise den Agenten direkt abfragen oder andere zugehörige Geräte-Agenten abfragen, um ein besseres Verständnis des Ereignisses zu erhalten.

Trap-gesteuerte Benachrichtigungen können zu erheblichen Einsparungen bei Netzwerk- und Agenten-Ressourcen führen, da keine unlauteren SNMP-Anfragen mehr erforderlich sind. Das SNMP Polling kann jedoch nicht vollständig eliminiert werden. SNMP-Anforderungen sind für die Erkennung und für Topologieänderungen erforderlich. Darüber hinaus kann ein Agent eines verwalteten Geräts kein Trap senden, wenn ein schwerwiegender Geräteausfall aufgetreten ist.

SNMPv1-Traps werden in RFC 1157 definiert und verfügen über die folgenden Felder:

• Enterprise (Enterprise): Identifiziert den Typ des verwalteten Objekts, das das Trap generiert.

• Agent address (Agentadresse): Gibt die Adresse des verwalteten Objekts an, das das Trap generiert.

• Generic trap type: Gibt einen generischen Trap-Typ an.

• Specific trap code (Spezifischer Trap-Code): Gibt einen aus einer Reihe spezifischer Trap-Codes an.

• Time stamp (Zeitstempel): Gibt die Zeit an, die zwischen der letzten Netzwerkneuinitialisierung und der Generierung des Traps vergangen ist.

• Variable Bindings: Das Datenfeld des Traps, das PDU enthält. Jede Variablenbindung ordnet eine bestimmte MIB-Objektinstanz ihrem aktuellen Wert zu.

Allgemeine Traps sind: coldStart, warmStart, linkDown, linkUp, authenticationFailure, egpNeighborLoss. Für generische SNMPv1-Traps enthält das Enterprise-Feld den Wert sysObjectID des Geräts, das Trap sendet. Bei anbieterspezifischen Traps wird das Feld Generic trap type auf enterpriseSpecific(6) gesetzt. Cisco implementierte seine eigenen spezifischen Traps auf unkonventionelle Weise. Statt dass das Trap-Enterprise-Feld immer noch die sysObjectID enthält und der spezifische Trap-Code zur Identifizierung aller spezifischen Traps, die von allen Cisco Geräten unterstützt werden, implementierte Cisco die Trap-Identifizierung mithilfe verschiedener Trap-Enterprise- und spezifischer Trap-Code-Felder. Die tatsächlichen Werte werden im SNMP-Objektnavigatorangezeigt. Darüber hinaus hat Cisco einige generische Traps in CISCO-GENERAL-TRAPS MIB durch Hinzufügen weiterer gebundener Variablen neu definiert. Für diese Traps wird der generische Trap-Typ beibehalten und nicht auf enterpriseSpecific(6) festgelegt.

In SNMPv2c wird Trap als NOTIFICATION definiert und anders formatiert als SNMPv1. Er verfügt über folgende Parameter:

• sysUpTime (sysUpTime): Dies entspricht dem Zeitstempel in SNMPv1-Traps.

• snmpTrapOID - Trap-Identifikationsfeld. Für generische Traps werden Werte in RFC 1907 definiert. Für anbieterspezifische Traps ist snmpTrapOID im Wesentlichen eine Verkettung des SNMPv1-Enterprise-Parameters und zweier zusätzlicher Sub-Bezeichner, '0', und des SNMPv1-spezifischen Trap-Code-Parameters.

• VarBindList (VarBindList): Dies ist eine Liste von Variablenbindungen.

Damit ein Managementsystem eine von einem Agenten an es gesendete Trap verstehen kann, muss das Managementsystem wissen, was die Objektkennung (OID) definiert. Daher muss die MIB für dieses Trap geladen sein. Hierdurch werden die richtigen OID-Informationen bereitgestellt, sodass das Netzwerkmanagementsystem die an es gesendeten Traps verstehen kann.

Informationen zu Traps, die von Cisco Geräten in bestimmten MIBs unterstützt werden, finden Sie im Cisco SNMP Object Navigator. Hier werden die für eine bestimmte MIB verfügbaren Traps aufgelistet. Um eines dieser Traps zu erhalten, muss Ihre Cisco IOS® Software-Version die aufgelistete MIB unterstützen. Informationen darüber, welche MIBs auf Ihrem Cisco Gerät unterstützt werden, finden Sie unter www.cisco.com/go/mibs. Die MIB muss in das Netzwerkmanagementsystem geladen werden. Dies wird gemeinhin als Kompilieren bezeichnet. Weitere Informationen zur MIB-Kompilierung auf Ihrer NMS-Plattform finden Sie im Benutzerhandbuch des Network Management System (z. B. HP OpenView oder NetView). Siehe auch SNMP: Häufig gestellte Fragen zu MIBs und MIB-Compilern und Laden von MIBs.

Außerdem sendet ein Gerät kein Trap an ein Netzwerkmanagementsystem, es sei denn, es ist dafür konfiguriert. Ein Gerät muss wissen, dass es eine Trap senden sollte. Das Trap-Ziel wird normalerweise durch eine IP-Adresse definiert, kann jedoch ein Hostname sein, wenn das Gerät so konfiguriert ist, dass es einen DNS-Server (Domain Name System) abfragt. In neueren Versionen der Cisco IOS-Software können Geräteadministratoren auswählen, welche Traps gesendet werden sollen. Weitere Informationen zur Konfiguration eines Cisco Geräts für SNMP und zum Senden von Traps finden Sie in den entsprechenden Gerätekonfigurationsanleitungen und im Implementierungsleitfaden für Einwahl-NMS, in den unterstützten Cisco IOS SNMP-Traps und deren Konfiguration sowie in der Anleitung zur Unterstützung und Konfiguration von Cisco CatalystOS SNMP-Traps.

Hinweis: Der Manager empfängt normalerweise SNMP-Benachrichtigungen (TRAPs und INFORMs) über den UDP-Port 162.

Beispiele für von Cisco IOS gesendete Traps

Dieser Abschnitt enthält einige Beispiele für Traps, die von Cisco IOS gesendet werden und die zusammen mit dem SNMP-Paket debuggen.

Generisches SNMPv1-Trap, von Cisco neu definiert:

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 

Diese Ausgabe zeigt den neu definierten linkUp-Trap von Cisco aus CISCO-GENERAL-TRAPS MIB mit vier gebundenen Variablen. Folgende Felder sind vorhanden:

• Enterprise = products.45 (sysObjectID des Geräts, das Trap sendet, in diesem Beispiel ist es der c7507-Router)

• Generic trap type = 3 (linkUp)

• Spezifischer Trap-Code = 0

SNMPv1 Cisco-spezifisches Trap:

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 

Diese Ausgabe zeigt den von Cisco spezifischen clogMessageGenerierten Trap aus CISCO-SYSLOG-MIB mit fünf gebundenen Variablen. Folgende Felder sind vorhanden:

• Enterprise = Enterprise-Wert von clogMessageGenerated-Trap

• Generischer Trap-Typ = 6 (unternehmensspezifisch)

• Spezifischer Trapcode = 1 (spezifischer Trapcode von clogMessageGenerated)

SNMPv2c Cisco-spezifisches Trap:

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 

Diese Ausgabe zeigt die Cisco spezifische SNMPv2c-Benachrichtigung für ciscoConfigManEvent von CISCO-CONFIG-MAN-MIB mit drei gebundenen Variablen:

• ccmVerlaufEreignisBefehlQuelle

• ccmVerlaufEreignisKonfigQuelle

• ccmVerlaufEreignisKonfigZiel

Dieses Trap kann verwendet werden, wenn Änderungen an der Gerätekonfiguration vorgenommen wurden. Die Werte der letzten beiden Komponenten bestimmen, ob ein show-Befehl ausgegeben wurde oder ob die Konfiguration geändert wurde.

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.

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme