Netzwerküberwachung mithilfe von SNMP
SUMMARY In diesem Abschnitt wird die SNMP-Implementierung in Junos OS beschrieben.
Grundlegendes zur SNMP-Implementierung in Junos OS
SNMP-Architektur
Eine typische SNMP-Implementierung umfasst drei Komponenten:
Netzwerkmanagementsystem (NMS): Eine Kombination aus Hardware (Geräten) und Software (SNMP-Manager), die zur Überwachung und Verwaltung eines Netzwerks verwendet wird. Der Manager fragt die Geräte in Ihrem Netzwerk ab, wie oft Sie informationen über Netzwerkkonnektivität, -aktivitäten und -ereignisse angeben.
Verwaltetes Gerät: Ein verwaltetes Gerät (auch als Netzwerkelement bezeichnet) ist jedes Gerät in einem Netzwerk, das vom NMS verwaltet wird. Router und Switches sind gängige Beispiele für verwaltete Geräte.
SNMP-Agent: Der SNMP-Agent ist der SNMP-Prozess, der sich auf dem verwalteten Gerät befindet und mit dem NMS kommuniziert. Der SNMP-Agent tauscht Netzwerkmanagementinformationen mit der SNMP-Manager-Software aus, die auf einem NMS oder Host ausgeführt wird. Der Agent reagiert auf Informationsanfragen und Aktionen des Managers. Der Agent steuert auch den Zugriff auf die MIB des Agenten, die Sammlung von Objekten, die vom SNMP-Manager angezeigt oder geändert werden können.
Dieses Thema enthält die folgenden Abschnitte:
SNMP-MIBs
SNMP-Daten werden in einem stark strukturierten, hierarchischen Format gespeichert, das als Management Information Base (MIB) bekannt ist. Eine MIB definiert verwaltete Objekte in einem Netzwerkgerät.
Die MIB-Struktur basiert auf einer Baumstruktur und definiert eine Gruppierung von Objekten in zugehörigen Sets. Jedes Objekt in der MIB ist mit einem Objektbezeichner (OID) verknüpft, der das Objekt nennt. Das "Leaf" in der Baumstruktur ist die tatsächliche Verwaltete Objektinstanz, die eine Ressource, ein Ereignis oder eine Aktivität darstellt, die in Ihrem Netzwerkgerät auftritt.
MIBs sind entweder standard- oder unternehmensspezifisch. Standard-MIBs werden von der Internet Engineering Task Force (IETF) erstellt und in verschiedenen RFCs dokumentiert. Je nach Anbieter werden viele Standard-MIBs mit der NMS-Software bereitgestellt. Sie können die Standard-MIBs auch von der IETF-Website herunterladen, www.ietf.org, und sie bei Bedarf in Ihr NMS zusammenstellen.
Eine Liste der standardmäßig unterstützten MIBs finden Sie unter Standard-SNMP-MIBs, die von Junos OS unterstützt werden.
Unternehmensspezifische MIBs werden von einem bestimmten Gerätehersteller entwickelt und unterstützt. Wenn Ihr Netzwerk Geräte mit unternehmensspezifischen MIBs enthält, müssen Sie diese vom Hersteller beziehen und in Ihre Netzwerkmanagementsoftware kompilieren.
Eine Liste der von Juniper Networks unternehmensspezifischen unterstützten MIBs finden Sie unter Unternehmensspezifische SNMP-MIBs, die von Junos OS unterstützt werden.
SNMP-Manager und Agent-Authentifizierung und Kommunikation
SNMP verwendet eine sehr einfache Form der Authentifizierung, die Community-Zeichenfolgen genannt wird, um den Zugriff zwischen einem Manager und Remote-Agenten zu steuern. Community-Zeichenfolgen sind administrative Namen, die verwendet werden, um Sammlungen von Geräten (und die darauf ausgeführten Agenten) in gemeinsamen Verwaltungsdomänen zu gruppieren. Wenn ein Manager und ein Agent dieselbe Community teilen, können sie miteinander sprechen. Viele Personen assoziieren SNMP-Community-Zeichenfolgen mit Passwörtern und Schlüsseln, weil ihre Aufgaben ähnlich sind. Daher werden SNMP-Communitys traditionell als Zeichenfolgen bezeichnet.
Die Kommunikation zwischen dem Agenten und dem Manager erfolgt in einer der folgenden Formen:
Get,GetBulkundGetNextanforderungen: Der Manager fordert Informationen vom Agenten an; der Agent gibt die Informationen in einerGetAntwortnachricht zurück.SetRequests: Der Manager ändert den Wert eines MIB-Objekts, das vom Agenten gesteuert wird. der Agent gibt den Status in einerSetAntwortnachricht an.TrapsBenachrichtigung: Der Agent sendet Traps, um den Manager über wichtige Ereignisse auf dem Netzwerkgerät zu benachrichtigen.
SNMP-Traps and Informs
Router können Benachrichtigungen an SNMP-Manager senden, wenn wichtige Ereignisse auf einem Netzwerkgerät auftreten, am häufigsten Fehler oder Ausausfälle. SNMP-Benachrichtigungen können als Traps oder Inform-Anfragen gesendet werden. SNMP-Traps sind unbestätigte Benachrichtigungen. SNMP-Informationen sind bestätigte Benachrichtigungen.
SNMP-Traps werden entweder in standard- oder unternehmensspezifischen MIBs definiert. Standard traps werden von der IETF erstellt und in verschiedenen RFCs dokumentiert. Die Standardfallen werden in der Netzwerkmanagementsoftware zusammengestellt. Sie können die Standardfallen auch von der IETF-Website herunterladen , www.ietf.org.
Weitere Informationen zu Standard-Traps, die vom Junos OS unterstützt werden, finden Sie unter Standard-SNMP-Traps, die auf Geräten mit Junos OS unterstützt werden.
Unternehmensspezifische Fallen werden von einem bestimmten Gerätehersteller entwickelt und unterstützt. Wenn Ihr Netzwerk Geräte mit unternehmensspezifischen Traps enthält, müssen Sie diese vom Hersteller einholen und in Ihre Netzwerkmanagementsoftware kompilieren.
Weitere Informationen zu unternehmensspezifischen Traps, die vom Junos OS unterstützt werden, finden Sie unter Unternehmensspezifische SNMP-Traps, die von Junos OS unterstützt werden. Informationen zum Schweregrad der Systemprotokollierung für SNMP-Traps finden Sie unter Schweregrad der Systemprotokollierung für SNMP-Traps.
Bei Traps sendet der Empfänger keine Bestätigung, wenn er eine Trap empfängt, und der Absender kann nicht feststellen, ob die Trap empfangen wurde. Um die Zuverlässigkeit zu erhöhen, werden SNMP-Informationen in SNMPv3 unterstützt. Ein SNMP-Manager, der eine Information empfängt, bestätigt die Nachricht mit einer Antwort. Informationen zu SNMP-Informationen finden Sie unter Konfigurieren von SNMP-Informs.
SNMP unter Junos OS
Auf Junos OS verwendet SNMP sowohl Standard (von IETF entwickelt und in RFCs dokumentiert) als auch unternehmensspezifische MIBs von Juniper Networks.
Standardmäßig ist SNMP auf Geräten mit Junos OS nicht aktiviert.
In Junos OS umfassen die Prozesse, die die SNMP-Verwaltungsdaten pflegen, folgendes:
Ein SNMP-Master-Agent, der sich auf dem verwalteten Gerät befindet und vom NMS oder Host verwaltet wird.
Die SNMP-Agent-Software von Junos OS besteht aus einem primären SNMP-Agent (bekannt als SNMP-Prozess oder snmpd). Sie befindet sich auf dem verwalteten Gerät und wird vom NMS oder Host verwaltet.
Verschiedene Subagenten, die sich auf verschiedenen Modulen von Junos OS befinden, wie z. B. die Routing-Engine. Der SNMP-Master-Agent delegiert alle SNMP-Anforderungen an die Subagenten. Jeder Subagent ist für die Unterstützung einer bestimmten Gruppe von MIBs verantwortlich.
Junos OS verarbeitet, die Daten mit den Subagenten teilen, wenn sie für SNMP-Daten abgefragt werden (z. B. schnittstellenbezogene MIBs).
Die Community-Zeichenfolge ist die erste Ebene der Verwaltungsauthentifizierung, die vom SNMP-Agenten in Junos OS implementiert wird.
Weitere Informationen finden Sie in den folgenden Abschnitten.
- Junos OS- Unterstützung von SNMP-Versionen
- Schweregrad der Systemprotokollierung für SNMP-Traps
- SNMP-Kommunikationsfluss
- Trap Queuing
Junos OS- Unterstützung von SNMP-Versionen
Junos OS unterstützt die folgenden SNMP-Versionen:
SNMPv1: Die anfängliche Implementierung von SNMP, die die Architektur und das Framework für SNMP definiert.
SNMPv2c: Das überarbeitete Protokoll mit Verbesserungen bei der Leistung und der Kommunikation zwischen Managern. Insbesondere implementiert SNMPv2c Community-Zeichenfolgen, die als Passwörter fungieren, um zu bestimmen, wer, was und wie die SNMP-Clients auf die Daten im SNMP-Agenten zugreifen können. Die Community-Zeichenfolge ist in SNMP
Get,GetBulk, ,GetNextundSetAnforderungen enthalten. Der Agent benötigt möglicherweise eine andere Community-Zeichenfolge fürGet,GetBulkundGetNextAnforderungen (read-onlyZugriff) als fürSetAnfragen (read-writeZugriff).SNMPv3: Das aktuellste Protokoll konzentriert sich auf die Sicherheit. SNMPv3 definiert ein Sicherheitsmodell, ein benutzerbasiertes Sicherheitsmodell (USM) und ein ansichtsbasiertes Zugriffssteuerungsmodell (VACM). SNMPv3 USM bietet Datenintegrität, Datenursprungsauthentifizierung, Nachrichtenwiedergabeschutz und Schutz vor Offenlegung der Nachrichtennutzlast. SNMPv3 VACM bietet Zugriffskontrolle, um zu bestimmen, ob eine bestimmte Art von Zugriff (Lesen oder Schreiben) auf die Verwaltungsinformationen zulässig ist.
Darüber hinaus akzeptiert die SNMP-Agentsoftware Junos OS IPv4- und IPv6-Adressen für den Transport über IPv4 und IPv6. Für IPv6 unterstützt junos OS die folgenden Funktionen:
SNMP-Daten über IPv6-Netzwerke
IPv6-spezifische MIB-Daten
SNMP-Agenten für IPv6
Schweregrad der Systemprotokollierung für SNMP-Traps
Bei einigen Traps wird die Trap protokolliert, wenn eine Trap-Bedingung auftritt, unabhängig davon, ob der SNMP-Agent eine Trap an einen NMS sendet, wenn die Systemprotokollierung so konfiguriert ist, dass ein Ereignis mit dieser Schweregrad der Systemprotokollierung protokolliert wird.
Weitere Informationen zum Schweregrad der Systemprotokollierung für Standard traps finden Sie unter Standard-SNMP-Traps, die von Junos OS unterstützt werden. Weitere Informationen zum Schweregrad der Systemprotokollierung für unternehmensspezifische Traps finden Sie unter Unternehmensspezifische SNMP-Traps, die von Junos OS unterstützt werden.
SNMP-Kommunikationsfluss
Wenn ein NMS den primären Agenten nach Daten abfragt, teilt der primäre Agent die Daten sofort mit dem NMS, wenn die angeforderten Daten vom primären Agenten oder einem der Subagenten verfügbar sind. Wenn die angeforderten Daten jedoch nicht zu den Kategorien gehören, die vom primären Agenten oder den Subagenten verwaltet werden, fragt der Subagent den Junos OS-Kernel oder den Prozess ab, der diese Daten speichert. Nach dem Erhalt der erforderlichen Daten leitet der Subagent die Antwort zurück an den primären Agenten, der sie wiederum an den NMS weitergibt.
Abbildung 1 zeigt den Kommunikationsfluss zwischen NMS, SNMP-primärem Agent (snmpd), SNMP-Subagenten, Junos OS-Kernel und der Packet Forwarding Engine.
Wenn auf einem Netzwerkgerät ein bedeutendes Ereignis auftritt, meistens ein Fehler oder ein Fehler, sendet der SNMP-Agent Benachrichtigungen an den SNMP-Manager. Die SNMP-Implementierung in Junos OS unterstützt zwei Arten von Benachrichtigungen: fallen und informieren. Traps sind unbestätigte Benachrichtigungen, während Informs bestätigte Benachrichtigungen sind. Informs werden nur auf Geräten unterstützt, die die SNMP-Version 3 (SNMPv3)-Konfiguration unterstützen.
Trap Queuing
Junos OS unterstützt Trap-Warteschlangen, um sicherzustellen, dass Traps nicht aufgrund vorübergehender Nichtverfügbarkeit von Routen verloren gehen. Es werden zwei Arten von Warteschlangen gebildet, Zielwarteschlangen und eine Drosselwarteschlange, um die Bereitstellung von Traps zu gewährleisten und den Trap-Datenverkehr zu kontrollieren.
Trap-Warteschlangen können in Junos OS nicht konfiguriert werden. Informationen zu Trap-Warteschlangen können nur in den Systemprotokollen angezeigt werden.
Junos OS bildet eine Zielwarteschlange, wenn ein Trap an ein bestimmtes Ziel zurückgegeben wird, weil der Host nicht erreichbar ist, und fügt die nachfolgenden Traps demselben Ziel zur Warteschlange hinzu. Junos OS prüft alle 30 Sekunden die Verfügbarkeit von Routen und sendet die Traps aus der Zielwarteschlange in Round-Robin-Art.
Wenn die Trap-Bereitstellung fehlschlägt, wird der Trap wieder zur Warteschlange hinzugefügt, und der Zähler für den Zustellversuch und der Timer für den nächsten Zustellversuch für die Warteschlange werden zurückgesetzt. Nachfolgende Versuche erfolgen in progressiven Intervallen von 1 Minute, 2 Minuten, 4 Minuten und 8 Minuten. Die maximale Verzögerung zwischen den Versuchen beträgt 8 Minuten und die maximale Anzahl von Versuchen beträgt 10. Nach 10 erfolglosen Versuchen werden die Zielwarteschlange und alle Traps in der Warteschlange gelöscht.
Junos OS verfügt auch über einen Drosselmechanismus, um die Anzahl der Traps (Drosselschwellenwert; Standardwert von 500 Traps), die während eines bestimmten Zeitraums (Drosselintervall; Standard von 5 Sekunden) gesendet werden, zu steuern und um die Konsistenz des Trap-Datenverkehrs zu gewährleisten, insbesondere, wenn aufgrund von Änderungen des Schnittstellenstatus eine große Anzahl von Traps generiert wird. Die Drosselintervallperiode beginnt mit dem Eintreffen der ersten Falle am Gashebel. Alle Traps innerhalb des Trap-Schwellenwerts werden verarbeitet, und die Traps, die über die Schwellenwertgrenze hinausgehen, werden in die Warteschlange gestellt.
Die maximale Größe von Trap-Warteschlangen – also Drossel- und Zielwarteschlange zusammengestellt – beträgt 40.000. Auf Ethernet-Switches der EX-Serie beträgt die maximale Größe der Trap-Warteschlange jedoch 1.000. Die maximale Größe einer Warteschlange beträgt 20.000 für andere Geräte als Switches der EX-Serie. Auf Switches der EX-Serie beträgt die maximale Größe einer Warteschlange 500. Wenn der Drosselwarteschlange ein Trap hinzugefügt wird oder wenn die Drosselwarteschlange die maximale Größe überschritten hat, wird die Trap wieder über der Zielwarteschlange hinzugefügt, und alle nachfolgenden Versuche aus der Zielwarteschlange werden für einen Zeitraum von 30 Sekunden angehalten, nach dem die Zielwarteschlange neu gestartet wird, um die Traps zu senden.
Benutzer können Junos OS nicht für Trap-Warteschlangen konfigurieren. Benutzer können keine Informationen zu Trap-Warteschlangen anzeigen, außer was in den protokollierten Informationen verfügbar ist.
SNMPv3 – Übersicht
Der QFX3500-Switch unterstützt SNMP-Version 3 (SNMPv3). SNMPv3 verbessert die Funktionalität von SNMPv1 und SNMPv2c durch die Unterstützung von Benutzerauthentifizierung und Datenverschlüsselung. SNMPv3 verwendet das benutzerbasierte Sicherheitsmodell (USM), um Sicherheit für SNMP-Nachrichten und das ansichtsbasierte Zugriffssteuerungsmodell (VACM) für die Benutzerzugriffskontrolle bereitzustellen.
SNMPv3-Funktionen umfassen:
-
Mit USM können die SNMP-Nachrichten zwischen SNMP-Manager und Agent die Nachrichtenquelle authentifiziert und die Datenintegrität überprüft werden. USM reduziert Messaging-Verzögerungen und Nachrichtenwiedergaben, indem es Timeout-Begrenzungen erzwingt und auf doppelte Nachrichtenanforderungs-IDs überprüft.
-
VACM ergänzt USM durch Die Benutzerzugriffskontrolle für SNMP-Abfragen an den Agenten. Sie definieren Zugriffsrechte, die Sie auf eine Gruppe von einem oder mehreren Benutzern erweitern möchten. Zugriffsberechtigungen werden durch die Sicherheitsmodellparameter (
usmoderv1) undv2Sicherheitsstufenparameter (authentication,privacyodernone) bestimmt. Für jede Sicherheitsstufe müssen Sie der Gruppe eine MIB-Ansicht zuweisen. Durch das Zuordnen einer MIB-Ansicht mit einer Gruppe erhalten Sie lese-, schreib- oder benachrichtigen-Berechtigungen für einen Satz von MIB-Objekten für die Gruppe. -
Sie konfigurieren Sicherheitsparameter für jeden Benutzer, einschließlich Benutzername, Authentifizierungstyp und Authentifizierungskennwort sowie Datenschutztyp und Datenschutzkennwort. Der jedem Benutzer angegebene Benutzername hat ein Format, das vom für diesen Benutzer konfigurierten Sicherheitsmodell abhängt.
-
Um die Messaging-Sicherheit zu gewährleisten, wird in den Messaging-Daten, die zwischen dem lokalen SNMP-Server und dem SNMP-Zielserver gesendet werden, eine andere Art von Benutzername enthalten, der als Sicherheitsname bezeichnet wird. Jeder Benutzername wird einem Sicherheitsnamen zugeordnet, der Sicherheitsname ist jedoch in einem Format, das vom Sicherheitsmodell unabhängig ist.
-
Trap-Einträge in SNMPv3 werden erstellt, indem die Parameter Benachrichtigung, Benachrichtigungsfilter, Zieladresse und Zielparameter konfiguriert werden. Die
notifyAnweisung gibt den Typ der Benachrichtigung (Trap) an und enthält ein einzelnes Tag, das eine Gruppe von Zieladressen definiert, die einen Trap empfangen. Der Notify-Filter definiert den Zugriff auf eine Sammlung von Trap Object Identifiern (OIDs). Die Zieladresse definiert die Adresse einer SNMP-Verwaltungsanwendung und andere Attribute, die beim Senden von Benachrichtigungen verwendet werden. Zielparameter definieren die Nachrichtenverarbeitungs- und Sicherheitsparameter, die beim Senden von Benachrichtigungen an ein bestimmtes Ziel verwendet werden.
Führen Sie die folgenden Aufgaben aus, um SNMPv3 zu konfigurieren:
Laden von MIB-Dateien in ein Netzwerkmanagementsystem
Damit Ihr Netzwerkmanagementsystem (NMS) die vom Junos OS verwendeten MIB-Objekte identifizieren und verstehen kann, müssen Sie die MIB-Dateien zuerst mithilfe eines MIB-Compilers in Ihren NMS laden. Ein MIB-Compiler ist ein Dienstprogramm, das die MIB-Informationen wie den MIB-Objektnamen, die IDs und den Datentyp für das NMS analysiert.
Sie können das Junos MIB-Paket aus dem Junos OS Enterprise MIBs Index unter https://www.juniper.net/documentation/en_US/release-independent/junos/mibs/mibs.html herunterladen. Das Junos MIB-Paket ist in .zip und .tar Paketen verfügbar. Sie können das entsprechende Format herunterladen, das ihren Anforderungen entspricht.
Das Junos MIB-Paket enthält zwei Ordner: StandardMibs und JuniperMibs. Der StandardMibs Ordner enthält die Standard-MIBs und RFCs, die auf Geräten unterstützt werden, auf denen Junos OS ausgeführt wird, während der JuniperMibs Ordner die unternehmensspezifischen MIBs von Juniper Networks enthält.
So laden Sie MIB-Dateien, die für die Verwaltung und Überwachung von Geräten erforderlich sind, auf denen junos OS ausgeführt wird:
Wenn der Compiler beim Laden einer MIB-Datei eine Fehlermeldung zurückgibt, die besagt, dass eines der Objekte undefiniert ist, öffnen Sie die MIB-Datei mit einem Text-Editor, und stellen Sie sicher, dass alle im IMPORT Abschnitt aufgeführten MIB-Dateien auf den Compiler geladen werden. Wenn eine der im Abschnitt aufgeführten MIB-Dateien nicht auf den IMPORT Compiler geladen wird, laden Sie diese MIB-Datei, und versuchen Sie dann, die MIB-Datei zu laden, die nicht geladen werden konnte.
Die unternehmensspezifische PING-MIB, mib-jnx-ping.txthat beispielsweise Abhängigkeiten von RFC 2925, DiSMAN-PING-MIB, mib-rfc2925a.txt. Wenn Sie versuchen, vor dem Laden mib-rfc2925a.txtzu ladenmib-jnx-ping.txt, gibt der Compiler eine Fehlermeldung aus, dass bestimmte Objekte in mib-jnx-ping.txt undefiniert sind. Laden Sie mib-rfc2925a.txt, und versuchen Sie dann, zu laden mib-jnx-ping.txt. Die unternehmensspezifische PING-MIB mib-jnx-ping.txtlädt dann ohne Probleme.
Siehe auch
Das Management von Traps and Informs
In den folgenden Abschnitten finden Sie Details zur Verwaltung von SNMP-Benachrichtigungen:
- Generieren von Traps basierend auf SysLog-Ereignissen
- Filterung von Traps basierend auf der Trap-Kategorie
- Filter-Traps basierend auf dem Objektbezeichner
Generieren von Traps basierend auf SysLog-Ereignissen
Ereignisrichtlinien können eine Aktion enthalten, die traps für Ereignisse auf der Grundlage von Systemprotokollmeldungen löst. Diese Funktion ermöglicht eine Benachrichtigung über eine SNMP-trap-basierte Anwendung, wenn eine wichtige Systemprotokollnachricht auftritt. Sie können jede Systemprotokollnachricht, für die es kein entsprechendes Trap gibt, in ein Trap konvertieren. Wenn Sie Netzwerkmanagementsystem-Traps anstelle von Systemprotokollmeldungen zur Überwachung Ihres Netzwerks verwenden, können Sie diese Funktion verwenden, um sicherzustellen, dass Sie über alle wichtigen Ereignisse informiert werden.
Um eine Richtlinie zu konfigurieren, die beim Erhalt eines Ereignisses eine Falle löst, fügen Sie die folgenden Anweisungen auf der [edit event-options policy policy-name] Hierarchieebene ein:
Das folgende Beispiel zeigt die Beispielkonfiguration für das Aufziehen eines Traps für das Ereignis ui_mgd_terminate:
[edit event-options policy p1]
events ui_mgd_terminate;
then {
raise-trap;
}
Filterung von Traps basierend auf der Trap-Kategorie
SNMP-Traps werden in viele Kategorien kategorisiert. Junos OS bietet eine Konfigurationsoption categories auf Hierarchieebene, mit der [edit snmp trap-group trap-group] Sie Kategorien von Traps angeben können, die Sie auf einem bestimmten Host erhalten möchten. Sie können diese Option verwenden, wenn Sie nur bestimmte Module des Junos OS überwachen möchten.
Das folgende Beispiel zeigt eine Beispielkonfiguration für den Nur-Empfang link, vrrp-events, servicesund otn-alarms Traps:
[edit snmp]
trap-group jnpr {
categories {
link;
vrrp-events;
services;
otn-alarms;
}
targets {
192.168.69.179;
}
}
Filter-Traps basierend auf dem Objektbezeichner
Das Junos OS bietet auch eine erweiterte Filteroption, mit der Sie bestimmte Traps basierend auf ihren Objektbezeichnern herausfiltern können. Sie können die notify-filter Option verwenden, um eine bestimmte Trap oder eine Gruppe von Traps herauszufiltern.
Das folgende Beispiel zeigt die Beispielkonfiguration für den Ausschluss von Traps für das unternehmensspezifische Konfigurationsmanagement von Juniper Networks (beachten Sie, dass die SNMPv3-Konfiguration auch die Filterung von SNMPv1- und SNMPv2-Traps unterstützt, wie im folgenden Beispiel dargestellt):
[edit snmp]
v3 {
vacm {
security-to-group {
security-model v2c {
security-name sn_v2c_trap {
group gr_v2c_trap;
}
}
}
access {
group gr_v2c_trap {
default-context-prefix {
security-model v2c {
security-level none {
read-view all;
notify-view all;
}
}
}
}
}
}
target-address TA_v2c_trap {
address 10.209.196.166;
port 9001;
tag-list tg1;
target-parameters TP_v2c_trap;
}
target-parameters TP_v2c_trap {
parameters {
message-processing-model v2c;
security-model v2c;
security-level none;
security-name sn_v2c_trap;
}
notify-filter nf1;
}
notify v2c_notify {
type trap;
tag tg1;
}
notify-filter nf1 {
oid .1.3.6.1.4.1.2636.4.5 exclude;
oid .1 include;
}
snmp-community index1 {
community-name "$9$tDLl01h7Nbw2axN"; ## SECRET-DATA
security-name sn_v2c_trap;
tag tg1;
}
view all {
oid .1 include;
}
}