Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

Konfigurieren von Grundlegendem SNMP

Konfigurationsanweisungen auf [bearbeiten snmp] Hierarchieebene

In diesem Thema werden alle möglichen Konfigurationsanweisungen auf Hierarchieebene [edit snmp] und auf deren Ebene in der Konfigurationshierarchie dargestellt. Wenn Sie Junos OS konfigurieren, wird Ihre aktuelle Hierarchieebene im Banner in der Zeile vor der user@host# Eingabeaufforderung angezeigt.

Konfigurieren von SNMP

SNMP wird in der Junos OS-Software implementiert, die auf den Produkten der QFX- und OCX-Serie ausgeführt wird. SNMP ist standardmäßig nicht aktiviert. Um SNMP zu aktivieren, müssen Sie die SNMP-Konfigurationsanweisungen auf Hierarchieebene [edit] einschließen.

Um die Mindestanforderungen für SNMP zu konfigurieren, fügen Sie die folgenden Anweisungen auf der [edit] Hierarchieebene der Konfiguration ein:

Um vollständige SNMP-Funktionen zu konfigurieren, fügen Sie die folgenden Anweisungen auf der [edit] Hierarchieebene der Konfiguration ein:

Optimierung der Netzwerkmanagementsystemkonfiguration für optimale Ergebnisse

Sie können ihre Netzwerkmanagementsystemkonfiguration ändern, um die Reaktionszeit für SNMP-Abfragen zu optimieren. In den folgenden Abschnitten finden Sie einige Tipps zur Konfiguration des Netzwerkmanagementsystems:

Ändern der Polling-Methode von Spalte für Spalte in Zeile für Zeile

Sie können das Netzwerkmanagementsystem so konfigurieren, dass die Methode Zeilen für Zeile für SNMP-Daten polling verwendet wird. Es hat sich gezeigt, dass die Abfragemethoden zeilenweise und mehrere Zeilen für mehrere Zeilen effizienter sind als die Abfrage von Spalten für Spalten. Indem Sie das Netzwerkmanagementsystem so konfigurieren, dass es die Datenabfragemethode zeilenweise verwendet, können Sie sicherstellen, dass Daten für nur eine Schnittstelle in einer Anfrage abgefragt werden, anstatt in einer einzelnen Anforderung Daten für mehrere Schnittstellen, wie dies bei spaltenweiser Abfrage der Fall ist. Zeilen-für-Zeilen-Abrufe reduzieren auch das Risiko, dass die Anforderungen zeitauftakten.

Reduzieren der Anzahl variabler Bindungen pro PDU

Indem Sie die Anzahl der variablen Bindungen pro Protokolldateneinheit (PDU) reduzieren, können Sie die Reaktionszeit für SNMP-Anforderungen verbessern. Eine Anforderung, die Daten abfragt, die sich auf mehrere Objekte beziehen, die verschiedenen Indexeinträgen zugeordnet sind, übersetzt sich am Geräteende in mehrere Anforderungen, da der Subagent möglicherweise verschiedene Module abfragen muss, um Daten zu erhalten, die mit verschiedenen Indexeinträgen verknüpft sind. Die empfohlene Methode besteht darin, sicherzustellen, dass eine Anforderung nur Objekte hat, die mit einem Indexeintrag verknüpft sind, anstatt über mehrere Objekte, die mit verschiedenen Indexeinträgen verknüpft sind.

HINWEIS:

Wenn die Antworten von einem Gerät langsam sind, vermeiden Sie die Verwendung der GetBulk Option für das Gerät, da eine GetBulk Anfrage Objekte enthalten kann, die mit verschiedenen Indexeinträgen verknüpft sind, und die Reaktionszeit weiter erhöhen kann.

snmp Bulk-Get Empfohlene Anzahl von OIDs und max.Repititions

Im Allgemeinen antwortet eine SNMP-Bulk-Get-Anfrage mit insgesamt (max.repetitions * number-of-OIDs) variablen Bindungen. Wenn Schnittstellenstatistikobjekte (z. B. ob InOctets, ifOutOctets usw.) in einer Abfrage vorhanden sind, werden die Anforderungen an niedrigere Ebenen gesendet. Daher werden diese Antworten durch eine Zunahme der "maximalen Wiederholungen", die Sie in einer Massenanfrage senden, beeinträchtigt. Für Massenabfragen wird empfohlen, für Schnittstellenstatistikobjekte den Wert "max-repetitions" von 10 und die maximale Anzahl von OIDs pro Anfrage 10 zu verwenden.

Erhöhung der Timeout-Werte in Polling- und Discovery-Intervallen

Indem Sie die Timeout-Werte für Polling- und Discovery-Intervalle erhöhen, können Sie die Warteschlangenzeit am Geräteende erhöhen und die Anzahl der Drosselungsverluste reduzieren, die aufgrund des Ausfalls der Anforderungs-Zeitsteuerung auftreten.

Reduzierung eingehender Paketraten bei snmpd

Indem Sie die Häufigkeit des Sendens von SNMP-Anforderungen an ein Gerät reduzieren, können Sie das Risiko reduzieren, dass sich SNMP-Anforderungen auf einem bestimmten Gerät anhäufen. Neben der Reduzierung der Häufigkeit des Sendens von SNMP-Anforderungen an ein Gerät können Sie auch das Abrufintervall erhöhen, die Verwendung von GetNext Anforderungen steuern und die Anzahl der Polling-Stationen pro Gerät reduzieren.

Konfiguration von Optionen auf verwalteten Geräten für eine bessere SNMP-Reaktionszeit

Die folgenden Abschnitte enthalten Informationen zu Konfigurationsoptionen auf den verwalteten Geräten, die die SNMP-Leistung verbessern können:

Ermöglichung der Stats-Cache-Lifetime-Option

Junos OS bietet Ihnen eine Option, um die Dauer der Zeit (in Sekunden) zu konfigurieren, die die Schnittstellenstatistiken zwischengespeichert werden. Wenn das NMS innerhalb der Cachezeit erneut für dieselbe Schnittstelle abfragt, werden dieselben Daten zurückgegeben. Wenn nms nach der Cachezeit Abfragen abfragt, ist der Cache nicht mehr gültig, und es werden neue Daten aus den unteren Ebenen abgerufen und der Cache-Zeitstempel aktualisiert. Der Standard stats-cache-lifetime ist 5 Sekunden. Dies kann entsprechend der Polling-Häufigkeit abgestimmt werden.

HINWEIS:

Die Reduzierung des Werts der Option stats-cache-lifetime führt zu mehr Abfragen und kann die Leistung beeinträchtigen. Um die nicht zwischengespeicherten Live-Statistiken zu erhalten, legen Sie den Wert der Option stats-cache-lifetime auf 0 fest. Dies wird jedoch nicht empfohlen, da die Caching-Funktion vollständig deaktiviert wird und die Leistung beeinträchtigt wird.

Herausfiltern doppelter SNMP-Anforderungen

Wenn eine Netzwerkmanagementstation eine oder GetNextGetBulk eine GetSNMP-Anfrage zu häufig an ein Gerät weiterüberträgt, kann diese Anforderung die Verarbeitung früherer Anforderungen stören und die Reaktionszeit des Agenten verlangsamen. Das Filtern dieser doppelten Anforderungen verbessert die Reaktionszeit des SNMP-Agenten. Mit Junos OS können Sie duplikate GetGetNextund GetBulk SNMP-Anforderungen herausfiltern. Junos OS verwendet die folgenden Informationen, um zu bestimmen, ob eine SNMP-Anfrage eine Duplikate ist:

  • Quell-IP-Adresse der SNMP-Anfrage

  • Quell-UDP-Port der SNMP-Anfrage

  • Anforderungs-ID der SNMP-Anforderung

HINWEIS:

Standardmäßig ist die Filterung doppelter SNMP-Anforderungen auf Geräten mit Junos OS deaktiviert.

Um die Filterung doppelter SNMP-Anforderungen auf Geräten mit Junos OS zu aktivieren, fügen Sie die filter-duplicates Anweisung auf [edit snmp] Hierarchieebene ein:

Ausschluss von Schnittstellen, die langsam auf SNMP-Abfragen reagieren

Eine Schnittstelle, die langsam auf SNMP-Anfragen für Schnittstellenstatistiken reagiert, kann Kernelantworten auf SNMP-Anfragen verzögern. Sie können die mib2d-Protokolldatei überprüfen, um herauszufinden, wie lange der Kernel braucht, um auf verschiedene SNMP-Anfragen zu reagieren. Weitere Informationen zur Überprüfung der Protokolldatei auf Kernel-Antwortdaten finden Sie unter "Überprüfen der Kernel- und Packet Forwarding Engine Response" unter Überwachung der SNMP-Aktivität und Nachverfolgung von Problemen, die die SNMP-Leistung auf einem Gerät mit Junos OS beeinträchtigen. Wenn Sie bemerken, dass eine bestimmte Schnittstelle langsam reagiert, und denken, dass sie den Kernel von der Antwort auf SNMP-Anfragen verlangsamt, schließen Sie diese Schnittstelle von den SNMP-Abfragen an das Gerät aus. Sie können eine Schnittstelle von den SNMP-Abfragen ausschließen, indem Sie entweder die filter-interface Anweisung konfigurieren oder die SNMP-Ansichtseinstellungen ändern.

Das folgende Beispiel zeigt eine Beispielkonfiguration für den Ausschluss von Schnittstellen aus SNMP Getund GetNextSet Vorgängen:

Das folgende Beispiel zeigt die SNMP-Ansichtskonfiguration für das Ausschließen der Schnittstelle mit dem Schnittstellenindexwert (ifIndex) von 312 aus einer Anforderung nach Informationen, die sich auf die ifTable- und ifXTable-Objekte beziehen:

Alternativ können Sie die Schnittstelle nutzen, die langsam offline reagiert.

Best Practices für die Konfiguration von SNMP

Die folgenden Abschnitte enthalten Informationen zur grundlegenden SNMP-Konfiguration und einige Beispiele für die Konfiguration der grundlegenden SNMP-Vorgänge auf Geräten, auf denen Junos OS ausgeführt wird:

Konfigurieren von Grundeinstellungen für SNMPv1 und SNMPv2

Standardmäßig ist SNMP auf Geräten mit Junos OS nicht aktiviert. Um SNMP auf Geräten mit Junos OS zu aktivieren, fügen Sie die community public Anweisung auf Hierarchieebene [edit  snmp] ein.

Aktivieren von SNMPv1 und SNMPv2 Get and GetNext Operations

Eine Community, die als öffentlich definiert ist, gewährt jedem Kunden Zugriff auf alle MIB-Daten.

Um SNMPv1- und SNMPv2-Operationen Set auf dem Gerät zu aktivieren, müssen Sie die folgenden Anweisungen auf Hierarchieebene [edit snmp] einschließen:

Aktivieren von SNMPv1- und SNMPv2-Set-Vorgängen

Das folgende Beispiel zeigt die grundlegende Mindestkonfiguration für SNMPv1- und SNMPv2-Traps auf einem Gerät:

Konfigurieren von SNMPv1- und SNMPv2-Traps

Konfigurieren von Grundeinstellungen für SNMPv3

Das folgende Beispiel zeigt die mindeste SNMPv3-Konfiguration für die Aktivierung GetGetNextund Set den Betrieb auf einem Gerät (beachten Sie, dass für die Konfiguration die Authentifizierung und der Datenschutz nonefestgelegt md5 ist):

Aktivieren von SNMPv3 Get, GetNext und Festlegen des Betriebs

Das folgende Beispiel zeigt die Grundlegende Konfiguration für SNMPv3-Informationen auf einem Gerät (die Konfiguration hat Authentifizierung und Datenschutz auf ):none

SNMPv3-Informationen konfigurieren

Sie können die SNMPv3-Informs in Traps konvertieren, indem Sie den Wert der type Anweisung auf Hierarchieebene auf trap den [edit snmp v3 notify N1_all_tl1_informs] im folgenden Beispiel dargestellten Wert setzen:

Umwandlung von Informationen in Traps

Konfigurieren des Systemnamens, des Standorts, der Beschreibung und der Kontaktinformationen

Junos OS ermöglicht es Ihnen, den Namen und den Standort des Systems, administrative Kontaktinformationen und eine kurze Beschreibung des Systems in die SNMP-Konfiguration einzubeziehen.

HINWEIS:

Behalten Sie immer den Namen, den Standort, die Kontakt- und Beschreibungsinformationen für alle Ihre Geräte, die über SNMP verwaltet werden, konfiguriert und aktualisiert.

Das folgende Beispiel zeigt eine typische Konfiguration.

Tipp:

Verwenden Sie Anführungszeichen, um den Systemnamen, den Kontakt, den Standort und die Beschreibungsinformationen zu schließen, die Leerzeichen enthalten.

Konfigurieren von SNMP auf einem Gerät mit Junos OS

Standardmäßig ist SNMP auf Geräten mit Junos OS deaktiviert. Um SNMP auf einem Router oder Switch zu aktivieren, müssen Sie die SNMP-Konfigurationsanweisungen auf Hierarchieebene [edit snmp] einschließen.

Um die Mindestanforderungen für SNMP zu konfigurieren, fügen Sie die folgenden Anweisungen auf der [edit snmp] Hierarchieebene der Konfiguration ein:

Die Community, die public hier definiert ist, gewährt jedem Kunden Lesezugriff auf alle MIB-Daten.

Um vollständige SNMP-Funktionen zu konfigurieren, fügen Sie die folgenden Anweisungen auf Hierarchieebene [edit snmp] ein:

Konfigurieren des Systemkontakts auf einem Gerät mit Junos OS

Sie können einen administrativen Kontakt für jedes System angeben, das über SNMP verwaltet wird. Dieser Name wird in das MIB II sysContact-Objekt platziert. Um einen Kontaktnamen zu konfigurieren, fügen Sie die contact Anweisung auf [edit snmp] Hierarchieebene ein:

Wenn der Name Leerzeichen enthält, schließen Sie ihn in Anführungszeichen ein (" ").

So definieren Sie einen Systemkontaktnamen, der Leerzeichen enthält:

Konfigurieren des Systemstandorts für ein Gerät mit Junos OS

Sie können den Speicherort jedes Systems angeben, das durch SNMP verwaltet wird. Diese Zeichenfolge wird in das MIB II sysLocation-Objekt platziert. Um einen Systemstandort zu konfigurieren, fügen Sie die location Anweisung auf [edit snmp] Hierarchieebene ein:

Wenn die Position Leerzeichen enthält, schließen Sie sie in Anführungszeichen ein (" ").

So geben Sie den Systemstandort an:

Konfigurieren der Systembeschreibung auf einem Gerät mit Junos OS

Sie können eine Beschreibung für jedes System angeben, das über SNMP verwaltet wird. Diese Zeichenfolge wird in das MIB II sysDescription-Objekt platziert. Um eine Beschreibung zu konfigurieren, fügen Sie die description Anweisung auf [edit snmp] Hierarchieebene ein:

Wenn die Beschreibung Leerzeichen enthält, schließen Sie sie in Anführungszeichen ein (" ").

So geben Sie die Systembeschreibung an:

Konfigurieren von SNMP-Details

Sie können SNMP verwenden, um grundlegende administrative Details zu speichern, z. B. einen Kontaktnamen und den Standort des Geräts. Ihr Managementsystem kann diese Informationen dann aus der Ferne abrufen, wenn Sie ein Problem beheben oder ein Audit durchführen. In der SNMP-Terminologie sind dies die Objekte sysContact, sysDescription und sysLocation, die in der Systemgruppe von MIB-2 gefunden werden (wie in RFC 1213, Management Information Base für das Netzwerkmanagement von TCP/IP-basierten Interneten definiert: MIB-II). Sie können die Anfangswerte direkt in der Junos OS-Konfiguration für jedes System festlegen, das über SNMP verwaltet wird.

So setzen Sie die Kontaktdetails des Systems:

  1. Legen Sie die Systemkontaktdetails fest, indem Sie die contact Anweisung auf Hierarchieebene [edit snmp] oder in eine entsprechende Konfigurationsgruppe aufnehmen, wie hier dargestellt.

    Dieser administrative Kontakt wird in das MIB II sysContact-Objekt platziert.

    Wenn der Name Leerzeichen enthält, schließen Sie ihn in Anführungszeichen ein (" ").

    Zum Beispiel:

  2. Konfigurieren Sie eine Systembeschreibung.

    Diese Zeichenfolge wird in das MIB II sysDescription-Objekt platziert. Wenn die Beschreibung Leerzeichen enthält, schließen Sie sie in Anführungszeichen ein (" ").

    Zum Beispiel:

  3. Konfigurieren Sie einen Systemstandort.

    Diese Zeichenfolge wird in das MIB II sysLocation-Objekt platziert. Wenn die Position Leerzeichen enthält, schließen Sie sie in Anführungszeichen ein (" ").

    So geben Sie den Systemstandort an:

    Zum Beispiel:

  4. Wenden Sie auf der obersten Ebene der Konfiguration die Konfigurationsgruppe an.

    Wenn Sie eine Konfigurationsgruppe verwenden, müssen Sie sie anwenden, damit sie wirksam wird.

  5. Commit der Konfiguration.
  6. Geben Sie den Befehl im Betriebsmodus ein, um die show snmp mib walk system Konfiguration zu überprüfen.

    Der show snmp mib walk system Befehl führt einen MIB-Walk durch die Systemtabelle (von MIB-2 wie in RFC 1213 definiert). Der SNMP-Agent in Junos OS antwortet, indem er jede Zeile in der Tabelle und den zugehörigen Wert druckt. Sie können denselben Befehl verwenden, um einen MIB-Walk durch jeden Beliebigen Teil der MIB-Struktur durchzuführen, der vom Agenten unterstützt wird.

Konfigurieren eines anderen Systemnamens

Mit Junos OS können Sie den Systemnamen überschreiben, indem Sie die name Anweisung auf [edit snmp] Hierarchieebene angeben:

Wenn der Name Leerzeichen enthält, schließen Sie ihn in Anführungszeichen ein (" ").

So geben Sie den Systemnamen außer Kraft:

Konfigurieren des Commit-Verzögerungs-Timers

Wenn ein Router oder Switch zum ersten Mal eine SNMP-nichtvolatile-Anfrage Set empfängt, wird eine Junos OS XML-Protokollsitzung geöffnet, die andere Benutzer oder Anwendungen daran hindert, die Kandidatenkonfiguration zu ändern (entspricht dem Befehlszeilenbefehl [CLI] configure exclusive -Befehl). Wenn der Router innerhalb von 5 Sekunden keine neuen SNMP-Anforderungen Set empfängt (Standardwert), wird die Kandidatenkonfiguration festgelegt und die Junos OS XML-Protokollsitzung wird geschlossen (die Konfigurationssperre wird freigegeben). Wenn der Router neue SNMP-Anforderungen Set empfängt, während die Kandidatenkonfiguration festgelegt wird, wird die SNMP-Anforderung Set abgelehnt und ein Fehler generiert. Wenn der Router neue SNMP-Anfragen Set empfängt, bevor 5 Sekunden verstrichen sind, wird der Commit-Delay-Timer (die Dauer zwischen dem Erhalt der letzten SNMP-Anfrage und der Commit-Anforderung) auf 5 Sekunden zurückgesetzt.

Standardmäßig ist der Timer auf 5 Sekunden festgelegt. Um den Timer für die SNMP-Antwort Set und den Start des Commit zu konfigurieren, fügen Sie die commit-delay Anweisung auf Hierarchieebene [edit snmp nonvolatile] ein:

seconds ist die Dauer der Zeit zwischen dem Erhalt der SNMP-Anforderung und dem Commit für die Kandidatenkonfiguration. Weitere Informationen zum configure exclusive Befehl und zum Sperren der Konfiguration finden Sie im Junos OS CLI-Benutzerhandbuch .

Filtern doppelter SNMP-Anforderungen

Standardmäßig ist das Filtern duplizierter get, und getNextgetBulk SNMP-Anforderungen auf Geräten mit Junos OS deaktiviert. Wenn eine Netzwerkmanagementstation eine oder GetNextGetBulk eine GetSNMP-Anfrage zu häufig an den Router weiterüberträgt, kann diese Anforderung die Verarbeitung früherer Anforderungen stören und die Reaktionszeit des Agenten verlangsamen. Das Filtern dieser doppelten Anforderungen verbessert die Reaktionszeit des SNMP-Agenten. Junos OS verwendet die folgenden Informationen, um zu bestimmen, ob es sich bei einer SNMP-Anforderung um eine Duplikate handelt:

  • Quell-IP-Adresse der SNMP-Anfrage

  • Quell-UDP-Port der SNMP-Anfrage

  • Anforderungs-ID der SNMP-Anforderung

Um doppelte SNMP-Anforderungen zu filtern, fügen Sie die filter-duplicates Anweisung auf [edit snmp] Hierarchieebene ein:

Konfigurieren von SNMP-Communities

Die Konfiguration des SNMP-Agenten in Junos OS ist eine einfache Aufgabe, die viele vertraute Einstellungen verwendet, die anderen verwalteten Geräten in Ihrem Netzwerk gemeinsam sind. Sie müssen beispielsweise Junos OS mit einer SNMP-Community-Zeichenfolge und einem Ziel für Traps konfigurieren. Community-Zeichenfolgen sind administrative Namen, die Sammlungen von Geräten und den darauf ausgeführten Agenten gemeinsam in gemeinsame Verwaltungsdomänen gruppieren. Wenn ein Manager und ein Agent dieselbe Community teilen, können sie miteinander kommunizieren. Eine SNMP-Community definiert den Grad der Autorisierung, der ihren Mitgliedern gewährt wird, z. B. welche MIB-Objekte verfügbar sind, welche Vorgänge (schreib- oder schreibgeschützte) für diese Objekte gültig sind und welche SNMP-Clients autorisiert sind, basierend auf ihren Quell-IP-Adressen.

Der SNMP-Community-String definiert die Beziehung zwischen einem SNMP-Serversystem und den Client-Systemen. Diese Zeichenfolge fungiert wie ein Kennwort, um den Zugriff der Clients auf den Server zu steuern.

So erstellen Sie eine schreibgeschützte SNMP-Community:

  1. Geben Sie die SNMP-Community ein, die in Ihrem Netzwerk verwendet wird.

    Wenn der Community-Name Leerzeichen enthält, schließen Sie ihn in Anführungszeichen ein (" ").

    Community-Namen müssen eindeutig sein.

    HINWEIS:

    Sie können nicht denselben Community-Namen auf hierarchie- und [edit snmp v3 snmp-community community-index] hierarchieebene [edit snmp community] konfigurieren.

    In diesem Beispiel wird der Standardname public verwendet, um eine Community zu erstellen, die eingeschränkten schreibgeschützten Zugriff bietet.

  2. Definieren Sie die Autorisierungsstufe für die Community.

    Die Standardautorisierungsstufe für eine Community ist read-only.

    Um Anfragen innerhalb einer Community zu ermöglichen Set , müssen Sie diese Community als authorization read-write. Bei Set Anforderungen müssen Sie auch die spezifischen MIB-Objekte einschließen, auf die mithilfe der view Anweisung mit Lese-Schreibberechtigungen zugegriffen werden kann. Die Standardansicht enthält alle unterstützten MIB-Objekte, auf die mit schreibgeschützten Berechtigungen zugegriffen werden kann. Es sind keine MIB-Objekte mit Lese-/Schreibberechtigungen zugänglich. Weitere Informationen zur view Anweisung finden Sie unter Konfigurieren von MIB-Ansichten.

    Dieses Beispiel beschränkt die öffentliche Community auf lesegeschützten Zugriff. Jeder SNMP-Client (z. B. ein SNMP-Managementsystem), der zur öffentlichen Community gehört, kann MIB-Variablen lesen, aber nicht festlegen (ändern).

  3. Definieren Sie eine Liste von Clients in der Community, die zur Kommunikation mit dem SNMP-Agenten in Junos OS autorisiert sind.

    Die clients Erklärung listet die IP-Adressen der Kunden (Community-Mitglieder) auf, die diese Community verwenden dürfen. Listen Sie die Clients nach IP-Adresse und Präfix auf. In der Regel enthält die Liste das SNMP-Netzwerkmanagementsystem in Ihrem Netzwerk oder die Adresse Ihres Verwaltungsnetzwerks. Wenn keine clients Anweisung vorhanden ist, sind alle Clients zulässig. Für addressmüssen Sie eine IPv4- oder IPv6-Adresse und keinen Hostnamen angeben.

    Die folgende Erklärung definiert, dass die Hosts im Netzwerk 192.168.1.0/24 in der öffentlichen Gemeinschaft autorisiert sind.

  4. Definieren Sie die Clients, die innerhalb der Community nicht autorisiert sind, indem Sie ihre IP-Adresse und gefolgt von der restrict Erklärung angeben.

    Die folgende Erklärung definiert, dass alle anderen Hosts von der öffentlichen Community eingeschränkt sind.

  5. Wenden Sie auf der obersten Ebene der Konfiguration die Konfigurationsgruppe an.

    Wenn Sie eine Konfigurationsgruppe verwenden, müssen Sie sie anwenden, damit sie wirksam wird.

  6. Commit der Konfiguration.

So erstellen Sie eine Schreib-/Schreib-SNMP-Community:

  1. Geben Sie die SNMP-Community ein, die in Ihrem Netzwerk verwendet wird.

    Dieser Standard-Community-String private zum Identifizieren der Community, die Lese-/Schreibzugriff auf den SNMP-Agenten auf dem Gerät gewährt wurde.

  2. Definieren Sie die Autorisierungsstufe für die Community.

    Dieses Beispiel beschränkt die öffentliche Community auf lesegeschützten Zugriff. Jeder SNMP-Client (z. B. ein SNMP-Managementsystem), der zur öffentlichen Community gehört, kann MIB-Variablen lesen, aber nicht festlegen (ändern).

  3. Definieren Sie eine Liste von Clients in der Community, die autorisiert sind, Änderungen am SNMP-Agenten in Junos OS vorzunehmen.

    Listen Sie die Clients nach IP-Adresse und Präfix auf.

    Zum Beispiel:

  4. Definieren Sie die Clients, die innerhalb der Community nicht autorisiert sind, indem Sie ihre IP-Adresse und gefolgt von der restrict Erklärung angeben.

    Die folgende Erklärung definiert, dass alle anderen Hosts von der öffentlichen Community eingeschränkt sind.

  5. Wenden Sie auf der obersten Ebene der Konfiguration die Konfigurationsgruppe an.

    Wenn Sie eine Konfigurationsgruppe verwenden, müssen Sie sie anwenden, damit sie wirksam wird.

  6. Commit der Konfiguration.

Konfigurieren der SNMP-Community-Zeichenfolge

Der SNMP-Community-String definiert die Beziehung zwischen einem SNMP-Serversystem und den Client-Systemen. Diese Zeichenfolge fungiert wie ein Kennwort, um den Zugriff der Clients auf den Server zu steuern. Um eine Community-Zeichenfolge in einer Junos OS-Konfiguration zu konfigurieren, fügen Sie die community Anweisung auf [edit snmp] Hierarchieebene ein:

Wenn der Community-Name Leerzeichen enthält, schließen Sie ihn in Anführungszeichen ein (" ").

Die Standardautorisierungsstufe für eine Community ist read-only. Um Anfragen innerhalb einer Community zu ermöglichen Set , müssen Sie diese Community als authorization read-write. Bei Set Anforderungen müssen Sie auch die spezifischen MIB-Objekte einschließen, auf die mithilfe der view Anweisung mit Lese-Schreibberechtigungen zugegriffen werden kann. Die Standardansicht enthält alle unterstützten MIB-Objekte, auf die mit schreibgeschützten Berechtigungen zugegriffen werden kann. miB-Objekte sind nicht mit Lese-/Schreibberechtigungen zugänglich. Weitere Informationen zur view Anweisung finden Sie unter Konfigurieren von MIB-Ansichten.

Die clients Erklärung listet die IP-Adressen der Kunden (Community-Mitglieder) auf, die diese Community verwenden dürfen. Wenn keine clients Anweisung vorhanden ist, sind alle Clients zulässig. Für addressmüssen Sie eine IPv4-Adresse und keinen Hostnamen angeben. Schließen Sie die default restrict Option ein, den Zugriff auf alle SNMP-Clients zu verweigern, für die der Zugriff nicht explizit gewährt wurde. Wir empfehlen, dass Sie immer die Option zur Einschränkung des default restrict SNMP-Client-Zugriffs auf den lokalen Switch einschließen.

HINWEIS:

Community-Namen müssen innerhalb jedes SNMP-Systems eindeutig sein.

Beispiele: Konfigurieren der SNMP-Community-Zeichenfolge

Gewähren Sie schreibgeschützten Zugriff auf alle Clients. Mit der folgenden Konfiguration reagiert das System auf SNMP Getund GetNextGetBulk Anforderungen, die die Community-Zeichenfolge publicenthalten:

Gewähren Sie allen Clients Lese-/Schreibzugriff auf die Ping-MIB und jnxPingMIB. Mit der folgenden Konfiguration reagiert das System auf SNMP , , und Set Anforderungen, die den Community-String private enthalten, und gibt eine OID an, die in der Ping-MIB oder jnxPingMIB -Hierarchie enthalten GetBulkist: GetNextGet

Die folgende Konfiguration ermöglicht schreibgeschützten Zugriff auf Clients mit IP-Adressen im Bereich 1.2.3.4/24und verweigert den Zugriff auf Systeme im Bereich fe80::1:2:3:4/64:

Hinzufügen einer Gruppe von Clients zu einer SNMP-Community

Mit Junos OS können Sie einer SNMP-Community eine oder mehrere Gruppen von Clients hinzufügen. Sie können die client-list-name name Anweisung auf Hierarchieebene [edit snmp community community-name] hinzufügen, um alle Mitglieder der Client- oder Präfixliste einer SNMP-Community hinzuzufügen.

Um eine Liste von Clients zu definieren, fügen Sie die client-list Anweisung gefolgt von den IP-Adressen der Clients auf Hierarchieebene [edit snmp] ein:

Sie können eine Präfixliste auf [edit policy options] Hierarchieebene konfigurieren. Durch die Unterstützung von Präfixlisten in der SNMP-Community-Konfiguration können Sie eine einzige Liste zur Konfiguration der SNMP- und Routing-Richtlinien verwenden. Weitere Informationen zur prefix-list Anweisung finden Sie im Benutzerhandbuch für Routing-Richtlinien, Firewall-Filter und Traffic Policer.

Um einer SNMP-Community eine Client- oder Präfixliste hinzuzufügen, fügen Sie die client-list-name Anweisung auf [edit snmp community community-name] Hierarchieebene ein:

HINWEIS:

Die Client- und Präfixliste dürfen nicht den gleichen Namen haben.

Das folgende Beispiel zeigt, wie Sie eine Client-Liste definieren:

Das folgende Beispiel zeigt, wie Sie einer SNMP-Community eine Client-Liste hinzufügen:

Das folgende Beispiel zeigt, wie Sie einer SNMP-Community eine Präfixliste hinzufügen:

Konfigurieren eines Proxy-SNMP-Agenten

Ab Version 12.3 können Sie mit Junos OS eines der Geräte im Netzwerk als PROXY-SNMP-Agent zuweisen, über den das Netzwerkmanagementsystem (NMS) andere Geräte im Netzwerk abfragen kann. Wenn Sie einen Proxy konfigurieren, können Sie die Namen der Geräte angeben, die über den PROXY-SNMP-Agent verwaltet werden sollen.

Wenn der NMS den SNMP-Proxy-Agent abfragt, gibt der NMS den Community-Namen (für SNMPv1 und SNMPv2) oder den Kontext und den Sicherheitsnamen (für SNMPv3) an, der dem Gerät, von dem die Informationen benötigt werden, zugeordnet sind.

HINWEIS:

Wenn Sie Authentifizierungs- und Datenschutzmethoden sowie Kennwörter für SNMPv3 konfiguriert haben, werden diese Parameter auch in der Abfrage für SNMPv3-Informationen angegeben.

Um einen SNMP-Proxy-Agent zu konfigurieren und Geräte anzugeben, die vom SNMP-Proxy-Agent verwaltet werden sollen, können Sie die folgenden Konfigurationsanweisungen auf [edit snmp] Hierarchieebene einfügen:

  • Mit proxy der Anweisung können Sie einen eindeutigen Namen für die Proxykonfiguration angeben.

  • Mit version-v1den Anweisungen , version-v2c, und version-v3 Anweisungen können Sie die SNMP-Version angeben.

  • Die no-default-comm-to-v3-config Anweisung ist eine optionale Anweisung auf [edit snmp proxy proxy-name <version-v1 | version-v2c>] Hierarchieebene, die bei Der Aufnahme in die Konfiguration erfordert, dass Sie die Anweisungen auf Hierarchieebene [edit snmp v3 snmp-community community-name] und [edit snmp v3 vacm] manuell konfigurieren müssen.

    Wenn die no-default-comm-to-v3-config Anweisung auf [edit snmp proxy proxy-name <version-v1 | version-v2c>] Hierarchieebene nicht enthalten ist, werden die Konfigurationen auf Hierarchieebene [edit snmp v3 snmp-community community-name] und [edit snmp v3 vacm] automatisch initialisiert.

  • Bei den logical-systemrouting-instance Anweisungen handelt es sich um optionale Anweisungen, mit denen Sie logische System- und Routing-Instanznamen angeben können, wenn Sie Proxies für logische Systeme oder Routing-Instanzen auf dem Gerät erstellen möchten.

HINWEIS:

Ab Junos OS Version 15.2 müssen Sie die Anweisung auf Hierarchieebene [edit snmp] für den SNMP-Proxy-Agent konfiguriereninterface <interface-name>.

HINWEIS:

Die Community- und Sicherheitskonfiguration für den Proxy sollte mit der entsprechenden Konfiguration auf dem zu verwaltenden Gerät übereinstimmen.

HINWEIS:

Da der SNMP-Proxy-Agent keine Trap-Weiterleitungsfunktionen hat, senden die geräte, die vom SNMP-Proxy-Agent verwaltet werden, die Traps direkt an das Netzwerkmanagementsystem.

Sie können den Befehl für den show snmp proxy Betriebsmodus verwenden, um Proxy-Details auf einem Gerät anzuzeigen. Der show snmp proxy Befehl gibt die Proxy-Namen, Gerätenamen, SNMP-Version, Community/Sicherheit und Kontextinformationen zurück.

Konfigurieren von SNMP-Traps

Traps sind unerwünschte Nachrichten, die von einem SNMP-Agenten an Remote-Netzwerkmanagementsysteme oder Trap-Empfänger gesendet werden. Viele Unternehmen verwenden SNMP-Traps zusätzlich zur Systemprotokollierung als Teil einer Lösung zur Fehlerüberwachung. In Junos OS werden SNMP-Traps standardmäßig nicht weitergeleitet, daher müssen Sie eine Trap-Gruppe konfigurieren, wenn Sie SNMP-Traps verwenden möchten.

Sie können eine Gruppe von einem oder mehreren SNMP-Traps erstellen und benennen und dann definieren, welche Systeme die Gruppe der SNMP-Traps empfangen. Der Name der Trap-Gruppe ist in SNMP-Trap-Benachrichtigungspakete als eine variable Bindung (varbind) eingebettet, die als Community-Name bekannt ist.

So konfigurieren Sie eine SNMP-Trap:

  1. Erstellen Sie eine einzige, konsistente Quelladresse, die Junos OS auf alle ausgehenden Traps in Ihrem Gerät anwendet.

    Eine Quelladresse ist nützlich, denn obwohl die meisten Junos OS-Geräte über eine Reihe von ausgehenden Schnittstellen verfügen, hilft die Verwendung einer Quelladresse einem Remote-NMS, die Quelle der Traps einem einzelnen Gerät zu zuordnen.

    In diesem Beispiel wird die IP-Adresse der Loopback-Schnittstelle (lo0) als Quelladresse für alle SNMP-Traps verwendet, die vom Gerät stammen.

  2. Erstellen Sie eine Trap-Gruppe, in der Sie die Typen von Traps, die weitergeleitet werden sollen, und die Ziele (Adressen) der empfangenden Remote-Managementsysteme auflisten können.

    In diesem Beispiel wird eine Trap-Gruppe erstellt managers, die es ermöglicht, snmp Version 2-formatierte Benachrichtigungen (Traps) an den Host unter der Adresse 192.168.1.15 zu senden. Diese Erklärung leitet alle Kategorien von Fallen weiter.

  3. Definieren Sie die spezifische Untermenge der Trap-Kategorien, die weitergeleitet werden sollen.

    Eine Liste von Kategorien finden Sie unter Konfigurieren von SNMP-Trap-Gruppen.

    Die folgende Anweisung konfiguriert die Standard-MIB-II-Authentifizierungsfehler auf dem Agenten (dem Gerät).

  4. Wenden Sie auf der obersten Ebene der Konfiguration die Konfigurationsgruppe an.

    Wenn Sie eine Konfigurationsgruppe verwenden, müssen Sie sie anwenden, damit sie wirksam wird.

  5. Commit der Konfiguration.
  6. Um die Konfiguration zu überprüfen, generieren Sie einen Authentifizierungsfehlerfall.

    Das bedeutet, dass der SNMP-Agent eine Anfrage von einer unbekannten Community erhalten hat. Auch andere Traps-Typen können nachgeeuft werden.

    Diese Funktion ermöglicht es Ihnen, SNMP-Traps von Routern auszulösen und sicherzustellen, dass diese in Ihrer vorhandenen Netzwerkmanagement-Infrastruktur korrekt verarbeitet werden. Dies ist auch für das Testen und Debuggen von SNMP-Verhalten auf dem Switch oder NMS nützlich.

    Mit dem monitor traffic Befehl können Sie überprüfen, ob die Trap an das Netzwerkmanagementsystem gesendet wurde.

Konfigurieren von SNMP-Trap-Optionen und -Gruppen auf einem Gerät mit Junos OS

Einige Netzbetreiber verfügen über mehr als einen Trap-Empfänger, der Traps an ein zentrales NMS weiterleitt. Dies ermöglicht mehr als einen Pfad für SNMP-Traps von einem Router zum zentralen NMS über verschiedene Trap-Empfänger. Ein Gerät mit Junos OS kann so konfiguriert werden, dass dieselbe Kopie jedes SNMP-Traps an jeden trap-Empfänger gesendet wird, der in der Trap-Gruppe konfiguriert ist.

Die Quelladresse im IP-Header jedes SNMP-Trap-Pakets ist standardmäßig auf die Adresse der ausgehenden Schnittstelle festgelegt. Wenn ein Trap-Empfänger das Paket an das zentrale NMS weiterleitt, wird die Quelladresse beibehalten. Die zentrale NMS, die nur die Quelladresse jedes SNMP-Trap-Pakets betrachtet, geht davon aus, dass jede SNMP-Trap von einer anderen Quelle stammt.

Tatsächlich kamen die SNMP-Traps vom selben Router, aber jeder verließ den Router über eine andere ausgehende Schnittstelle.

Die in den folgenden Abschnitten beschriebenen Anweisungen werden bereitgestellt, damit nmS die doppelten Traps erkennen und SNMPv1-Traps basierend auf der ausgehenden Schnittstelle unterscheiden kann.

Um SNMP-Trap-Optionen und Trap-Gruppen zu konfigurieren, fügen Sie die trap-options und trap-group Anweisungen auf Hierarchieebene [edit snmp] ein:

Konfigurieren von SNMP-Trap-Optionen

Mit SNMP-Trap-Optionen können Sie die Quelladresse jedes SNMP-Trap-Pakets, das vom Router gesendet wird, unabhängig von der ausgehenden Schnittstelle an eine einzige Adresse festlegen. Darüber hinaus können Sie die Agent-Adresse der SNMPv1-Traps festlegen. Weitere Informationen zum Inhalt von SNMPv1-Traps finden Sie unter RFC 1157.

HINWEIS:

SNMP kann keiner anderen Routing-Instanz als der Master-Routing-Instanz zugeordnet werden.

Um SNMP-Trap-Optionen zu konfigurieren, fügen Sie die trap-options Anweisung auf Hierarchieebene [edit snmp] ein:

Sie müssen auch eine Trap-Gruppe konfigurieren, damit die Trap-Optionen wirksam werden. Informationen zu Trap-Gruppen finden Sie unter Konfigurieren von SNMP-Trap-Gruppen.

Dieses Thema enthält die folgenden Abschnitte:

Konfigurieren der Quelladresse für SNMP-Traps

Sie können die Quelladresse von Trap-Paketen auf verschiedene Weise konfigurieren: lo0, eine gültige IPv4-Adresse oder IPv6-Adresse, die auf einer der Routerschnittstellen konfiguriert ist, eine logische Systemadresse oder die Adresse einer Routing-Instanz. Der Wert lo0 gibt an, dass die Quelladresse der SNMP-Trap-Pakete auf die niedrigste Loopback-Adresse festgelegt ist, die auf der Schnittstelle lo0 konfiguriert ist.

HINWEIS:

Wenn die Quelladresse eine ungültige IPv4- oder IPv6-Adresse ist oder nicht konfiguriert ist, werden keine SNMP-Traps generiert.

Sie können die Quelladresse von Trap-Paketen in einem der folgenden Formate konfigurieren:

  • Eine gültige IPv4-Adresse, die auf einer der Routerschnittstellen konfiguriert ist

  • Eine gültige IPv6-Adresse, die auf einer der Routerschnittstellen konfiguriert ist

  • lo0; das heißt, die niedrigste Loopback-Adresse, die auf der Schnittstelle lo0 konfiguriert wurde

  • Ein logischer Systemname

  • Name einer Routing-Instanz

Eine gültige IPv4-Adresse als Quelladresse

Um eine gültige IPv4-Schnittstellenadresse als Quelladresse für SNMP-Traps auf einer der Routerschnittstellen anzugeben, fügen Sie die source-address Anweisung auf [edit snmp trap-options] Hierarchieebene ein:

address ist eine gültige IPv4-Adresse, die auf einer der Routerschnittstellen konfiguriert ist.

Eine gültige IPv6-Adresse als Quelladresse

Um eine gültige IPv6-Schnittstellenadresse als Quelladresse für SNMP-Traps auf einer der Routerschnittstellen anzugeben, fügen Sie die source-address Anweisung auf [edit snmp trap-options] Hierarchieebene ein:

address ist eine gültige IPv6-Adresse, die auf einer der Routerschnittstellen konfiguriert ist.

Die niedrigste Loopback-Adresse als Quelladresse

Um die Quelladresse der SNMP-Traps anzugeben, sodass sie die niedrigste Loopback-Adresse verwenden, die auf der Schnittstelle lo0 als Quelladresse konfiguriert ist, fügen Sie die source-address Anweisung auf der [edit snmp trap-options] Hierarchieebene ein:

Um die Loopback-Adresse zu aktivieren und zu konfigurieren, fügen Sie die address Anweisung auf Hierarchieebene [edit interfaces lo0 unit 0 family inet] ein:

So konfigurieren Sie die Loopback-Adresse als Quelladresse von Trap-Paketen:

In diesem Beispiel ist die IP-Adresse 10.0.0.1 die Quelladresse jeder Trap, die von diesem Router gesendet wird.

Logischer Systemname als Quelladresse

Um einen logischen Systemnamen als Quelladresse von SNMP-Traps anzugeben, fügen Sie die logical-system logical-system-name Anweisung auf [edit snmp trap-options] Hierarchieebene ein.

Die folgende Konfiguration legt beispielsweise den logischen Systemnamen ls1 als Quelladresse von SNMP-Traps fest:

Routing-Instanzname als Quelladresse

Um einen Routing-Instanznamen als Quelladresse von SNMP-Traps anzugeben, fügen Sie die routing-instance routing-instance-name Anweisung auf [edit snmp trap-options] Hierarchieebene ein.

In der folgenden Konfiguration wird beispielsweise der Name ri1 der Routing-Instanz als Quelladresse für SNMP-Traps festgelegt:

Konfigurieren der Agentenadresse für SNMP-Traps

Die Agent-Adresse ist nur in Trap-Paketen mit SNMPv1 verfügbar (siehe RFC 1157). Standardmäßig wird die lokale Standardadresse des Routers nicht im Feld der Agentenadresse der SNMPv1-Trap angegeben. Um die Agentenadresse zu konfigurieren, fügen Sie die agent-address Anweisung auf [edit snmp trap-options] Hierarchieebene ein. Derzeit kann die Agent-Adresse nur die Adresse der ausgehenden Schnittstelle sein:

So konfigurieren Sie die ausgehende Schnittstelle als Agent-Adresse:

In diesem Beispiel hat jedes gesendete SNMPv1-Trap-Paket seinen Agentenadressenwert auf die IP-Adresse der ausgehenden Schnittstelle festgelegt.

Hinzufügen von snmpTrapEnterprise-Objektkennung zu Standard-SNMP-Traps

Mit dem snmpTrapEnterprise-Objekt können Sie das Unternehmen identifizieren, das die Falle definiert hat. In der Regel wird das snmpTrapEnterprise-Objekt als letzter Varbind in unternehmensspezifischen SNMP-Version 2-Traps angezeigt. Ab Version 10.0 können Sie mit Junos OS jedoch auch die snmpTrapEnterprise-Objektkennung zu Standard-SNMP-Traps hinzufügen.

Um snmpTrapEnterprise zu Standard traps hinzuzufügen, fügen Sie die enterprise-oid Anweisung auf [edit snmp trap-options] Hierarchieebene ein. Wenn die enterprise-oid Anweisung nicht in der Konfiguration enthalten ist, wird snmpTrapEnterprise nur für unternehmensspezifische Traps hinzugefügt.

Konfigurieren von SNMP-Trap-Gruppen

Sie können eine Gruppe von einem oder mehreren SNMP-Traps erstellen und benennen und dann definieren, welche Systeme die Gruppe der SNMP-Traps empfangen. Die Trap-Gruppe muss so konfiguriert sein, dass SNMP-Traps gesendet werden. Um eine SNMP-Trap-Gruppe zu erstellen, fügen Sie die trap-group Anweisung auf [edit snmp] Hierarchieebene ein:

Der Trap-Gruppenname kann eine beliebige Zeichenfolge sein und ist in das Feld Community-Name der Trap eingebettet. Um Ihren eigenen Trap-Gruppen-Port zu konfigurieren, fügen Sie die Anweisung ein destination-port . Der Standard-Zielport ist Port 162.

Für jede von Ihnen definierte Trapgruppe müssen Sie die target Anweisung einschließen, um mindestens ein System als Empfänger der SNMP-Traps in der Trap-Gruppe zu definieren. Geben Sie die IPv4- oder IPv6-Adresse jedes Empfängers an, nicht den Hostnamen.

Geben Sie die Typen von Traps an, die die Trap-Gruppe in der categories Anweisung empfangen kann. Informationen zu der Kategorie, zu der die Traps gehören, finden Sie in den Themen "Standard SNMP Traps Supported by Junos OS " und "Enterprise-Specific SNMP Traps Supported by Junos OS ".

Geben Sie die Routing-Instanz an, die von der Trap-Gruppe in der routing-instance Anweisung verwendet wird. Alle in der Trap-Gruppe konfigurierten Ziele verwenden diese Routing-Instanz.

Eine Trap-Gruppe kann die folgenden Kategorien erhalten:

  • authentication— Authentifizierungsfehler

  • chassis— Gehäuse- oder Umgebungsbenachrichtigungen

  • chassis-cluster—Clustering-Benachrichtigungen

  • configuration— Konfigurationsbenachrichtigungen

  • link— Link-bezogene Benachrichtigungen (up-down-Übergänge, Änderung des DS-3- und DS-1-Leitungsstatus, Änderung des IPv6-Schnittstellenstatus und passive Überwachungs-PIC-Überlastung)

    HINWEIS:

    Um passive Überwachungs-PIC-Überlastungsschnittstellen-Traps zu senden, wählen Sie die link Trap-Kategorie aus.

  • otn-alarms—OTN-Alarmfall-Unterkategorien

  • remote-operations— Remote-Betriebsbenachrichtigungen

  • rmon-alarm— Alarm für RMON-Ereignisse

  • routing—Routing-Protokollbenachrichtigungen

  • services— Service-Benachrichtigungen wie Herunter- oder Hochschaltung, Verbindung herunter oder hoch, CPU-Überschreitung, Alarme und Statusänderungen.

  • sonet-alarms—SONET/SDH-Alarme

    HINWEIS:

    Wenn Sie die SONET/SDH-Unterkategorien auslassen, werden alle Trap-Alarmtypen von SONET/SDH in Trap-Benachrichtigungen enthalten.

    • loss-of-light—Benachrichtigung über Verlust von Lichtalarm

    • pll-lock— PLL-Sperralarm-Benachrichtigung

    • loss-of-frame— Benachrichtigung über Frameverlust

    • loss-of-signal—Verlust der Signalalarmbenachrichtigung

    • severely-errored-frame— Benachrichtigung über Frame-Alarme mit schwerwiegenden Fehlern

    • line-ais— Line AlarmAnzeige Signal (AIS) Alarmbenachrichtigung

    • path-ais— Path AIS-Alarmbenachrichtigung

    • loss-of-pointer—Benachrichtigung über Pointer-Alarmverluste

    • ber-defect—SONET/SDH Bitfehlerquote Alarmfehlermeldung

    • ber-fault—SONET/SDH Fehlerrate-Alarm-Fehlerbenachrichtigung

    • line-remote-defect-indication— Alarmmeldung zur Remote-Fehleranzeige

    • path-remote-defect-indication—Pfad-Remote-Fehleranzeige-Alarmmeldung

    • remote-error-indication— Remote-Alarmbenachrichtigung bei Fehleranzeigen

    • unequipped— Nichtquippierte Alarmbenachrichtigung

    • path-mismatch— Benachrichtigung über Pfad-Mismatch

    • loss-of-cell—Alarmmeldung zum Verlust der Zellenabgrenzung

    • vt-ais—AIS-Alarmbenachrichtigung für virtuelle Zuflüsse (VT)

    • vt-loss-of-pointer— VT-Pointer-Alarm-Benachrichtigung

    • vt-remote-defect-indication—VT-Alarmmeldung zur Remote-Fehleranzeige

    • vt-unequipped— VT-Benachrichtigung mit nicht ausgefragten Alarmen

    • vt-label-mismatch— Fehlermeldung zu VT-Label-Mismatch

    • vt-loss-of-cell—Benachrichtigung über den Verlust der Zellenabgrenzung

  • startup—Das System beginnt warm und kalt

  • timing-events— Zeitsteuerung von Ereignissen und Mängelmeldungen

  • vrrp-events–VrRP-Ereignisse (Virtual Router Redundancy Protocol) wie Neu-Primär- oder Authentifizierungsfehler

Wenn Sie SONET/SDH-Unterkategorien einbeziehen, werden in Trap-Benachrichtigungen nur die Typen von SONET/SDH Trap-Alarmen berücksichtigt.

Mit version der Anweisung können Sie die SNMP-Version der Traps angeben, die an Ziele der Trap-Gruppe gesendet werden. Wenn Sie nur angeben v1 , werden SNMPv1-Traps gesendet. Wenn Sie nur angeben v2 , werden SNMPv2-Traps gesendet. Wenn Sie angeben all, werden für jede Trap-Bedingung sowohl eine SNMPv1- als auch eine SNMPv2-Trap gesendet. Weitere Informationen zur version Anweisung finden Sie unter Version (SNMP).

Unterstützung für SNMP-Traps

Die eigenständigen Switches der QFX-Serie, Virtual Chassis der QFX-Serie und QFabric-Systeme unterstützen Standard-SNMP-Traps und unternehmensspezifische Traps von Juniper Networks.

Weitere Informationen finden Sie unter:

SNMP-Traps werden von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt

Eigenständige Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützen SNMPv1- und v2-Traps. Weitere Informationen finden Sie unter:

SNMPv1-Traps

Die eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützen sowohl Standard-SNMPv1-Traps als auch unternehmensspezifische SNMPv1-Traps von Juniper Networks. Erkennen:

  • Tabelle 1 für Standard-SNMPv1-Traps.

  • Tabelle 2 für unternehmensspezifische SNMPv1-Traps.

Die Fallen werden zuerst nach Trap-Kategorie und dann nach Trap-Namen organisiert. Die Schweregrad der Systemprotokollierung sind für die Traps aufgeführt, die sie haben. Traps ohne den entsprechenden Schweregrad der Systemprotokollierung werden mit einem de(–) markiert.

Tabelle 1: Standard SNMP Version 1 Traps unterstützt von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie

Definiert in

Trap-Name

Unternehmens-ID

Generische Trap-Nummer

Spezifische Trap-Nummer

Schweregrad der Systemprotokollierung

Syslog-Tag

Link-Benachrichtigungen

RFC 1215, Konventionen zur Definition von Traps für die Verwendung mit SNMP

linkDown

1.3.6.1.4.1.2636

2

0

Warnung

SNMP_ TRAP_ LINK_DOWN

Linkup

1.3.6.1.4.1.2636

3

0

Informationen

SNMP_TRAP_ LINK_UP

Remote-Betriebsbenachrichtigungen

RFC 2925, Definitionen verwalteter Objekte für Remote-Ping-, Traceroute- und Lookup-Vorgänge

pingProbeFailed

1.3.6.1.2.1.80.0

6

1

Informationen

SNMP_TRAP _PING_ PROBE_ FEHLGESCHLAGEN

pingTestFailed

1.3.6.1.2.1.80.0

6

2

Informationen

SNMP_TRAP_ PING_TEST _FAILED

pingTest Abgeschlossen

1.3.6.1.2.1.80.0

6

3

Informationen

SNMP_TRAP_ PING_TEST_ ABGESCHLOSSEN

traceRoutePathChange

1.3.6.1.2.1.81.0

6

1

Informationen

SNMP_TRAP_ TRACE_ROUTE_ PATH_CHANGE

traceRouteTestFailed

1.3.6.1.2.1.81.0

6

2

Informationen

SNMP_TRAP_ TRACE_ROUTE_ TEST_FAILED

traceRouteTestErledigt

1.3.6.1.2.1.81.0

6

3

Informationen

SNMP_TRAP_ TRACE_ROUTE_ TEST_COMPLETED

RMON-Alarme

RFC 2819a, RMON-MIB

FallenderAlarm

1.3.6.1.2.1.16

6

2

steigenderAlarm

1.3.6.1.2.1.16

6

1

Routing-Benachrichtigungen

BGP 4 MIB

bgpE-Gründung

1.3.6.1.2.1.15.7

6

1

bgpBackwardTransition

1.3.6.1.2.1.15.7

6

2

OSPF TRAP MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2

6

1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2

6

2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2

6

3

ospfIfConfigError

1.3.6.1.2.1.14.16.2

6

4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2

6

5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2

6

6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2

6

7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2

6

9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2

6

10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2

6

11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2

6

13

ospfIfStateChange

1.3.6.1.2.1.14.16.2

6

16

Startup-Benachrichtigungen

RFC 1215, Konventionen zur Definition von Traps für die Verwendung mit SNMP

AuthentifizierungFailure

1.3.6.1.4.1.2636

4

0

Bemerken

SNMPD_ TRAP_ GEN_FAILURE

coldStart

1.3.6.1.4.1.2636

0

0

Kritisch

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.4.1.2636

1

0

Fehler

SNMPD_TRAP_ WARM_START

VRRP-Benachrichtigungen

RFC 2787, Definitionen verwalteter Objekte für das Virtual Router Redundancy Protocol

vrrpTrapNewMaster

1.3.6.1.2.1.68

6

1

Warnung

VRRPD_NEW MASTER_TRAP

vrrpTrapAuthFailure

1.3.6.1.2.1.68

6

2

Warnung

VRRPD_AUTH_ FAILURE_TRAP

Tabelle 2: Unternehmensspezifische SNMPv1-Traps werden von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt

Definiert in

Trap-Name

Unternehmens-ID

Generische Trap-Nummer

Spezifische Trap-Nummer

Schweregrad der Systemprotokollierung

Systemprotokoll-Tag

Chassis-Benachrichtigungen (Alarmbedingungen)

Gehäuse-MIB (jnx-chassis. mib)

jnxPowerSupplyFailure

1.3.6.1.4.1.2636.4.1

6

1

Warnung

CHASSISD_ SNMP_ FALLE

jnxFanFailure

1.3.6.1.4.1.26361

6

2

Kritisch

CHASSISD_ SNMP_ FALLE

jnxOverTemperature

11.4.1.2636.4.1

6

3

Warnung

CHASSISD_ SNMP_ FALLE

jnxFruRemoval

1.3.6.1.4.1.2636.4.1

6

5

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruInsertion

1.3.6.1.4.1.2636.4.1

6

6

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1

6

7

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1

6

8

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruFailed

1.3.6.1.4.1.2636.4.1

6

9

Warnung

CHASSISD_ SNMP_ FALLE

jnxFruOffline

1.3.6.1.4.1.2636.4.1

6

10

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruOnline

1.3.6.1.4.1.2636.4.1

6

11

Bemerken

CHASSISD_ SNMP_ FALLE

jnxFruCheck

1.3.6.1.4.1.2636.4.1

6

12

Warnung

CHASSISD_ SNMP_ FALLE

jnxPowerSupplyOk

1.3.6.1.4.1.2636.4.2

6

1

Kritisch

CHASSISD_ SNMP_ FALLE

jnxFanOK

1.3.6.1.4.1.2636.4.2

6

2

Kritisch

CHASSISD_ SNMP_ FALLE

jnxTemperatureOK

1.3.6.1.4.1.2636.4.2

6

3

Warnung

CHASSISD_ SNMP_ FALLE

Konfigurationsbenachrichtigungen

Konfigurationsmanagement-MIB (jnx- configmgmt. mib)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5

6

1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5

6

2

Remote-Betrieb

Ping MIB (jnx-ping.mib)

jnxPingRttThresholdExceed

1.3.6.1.4.1.2636.4.9

6

1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

4

jnxPingEgressStdDev-SchwellenwertExceed

1.3.6.1.4.1.2636.4.9

6

5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

6

jnxPingIngressThreshold Exceeded (jnxPingIngressThreshold Exceeded)

1.3.6.1.4.1.2636.4.9

6

7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9

6

9

RMON-Alarme

RMON MIB (jnx-rmon. mib)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4.3

6

1

jnxRmonGetOk

1.3.6.1.4.1.2636.4.3

6

2

SNMPv2-Traps

  • Tabelle 3 listet die standardmäßigen SNMP-Traps auf

  • Tabelle 4 listet die unternehmensspezifischen Fallen von Juniper Networks auf

Tabelle 3: Standard-SNMPv2-Traps, die von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt werden

Definiert in

Trap-Name

SNMP-Trap-OID

Schweregrad der Systemprotokollierung

Syslog-Tag

Link-Benachrichtigungen

RFC 2863, The Interfaces Group MIB

linkDown

1.3.6.1.6.3.1.1.5.3

Warnung

SNMP_TRAP_ LINK_DOWN

Linkup

1.3.6.1.6.3.1.1.5.4

Informationen

SNMP_TRAP_ LINK_UP

Remote-Betriebsbenachrichtigungen

RFC 2925, Definitionen verwalteter Objekte für Remote-Ping-, Traceroute- und Lookup-Vorgänge

pingProbeFailed

1.3.6.1.2.1.80.0.1

Informationen

SNMP_TRAP_ PING_PROBE_ FEHLGESCHLAGEN

pingTestFailed

1.3.6.1.2.1.80.0.2

Informationen

SNMP_TRAP_PING_ TEST_FAILED

pingTest Abgeschlossen

1.3.6.1.2.1.80.0.3

Informationen

SNMP_TRAP_PING_ TEST_COMPLETED

traceRoutePathChange

1.3.6.1.2.1.81.0.1

Informationen

SNMP_TRAP_TRACE_ ROUTE_PATH_ VERÄNDERUNG

traceRouteTestFailed

1.3.6.1.2.1.81.0.2

Informationen

SNMP_TRAP_TRACE_ ROUTE_TEST_FAILED

traceRouteTestErledigt

1.3.6.1.2.1.81.0.3

Informationen

SNMP_TRAP_TRACE_ ROUTE_TEST_ ABGESCHLOSSEN

RMON-Alarme

RFC 2819a, RMON-MIB

FallenderAlarm

1.3.6.1.2.1.16.0.1

steigenderAlarm

1.3.6.1.2.1.16.0.2

Routing-Benachrichtigungen

BGP 4 MIB

bgpE-Gründung

1.3.6.1.2.1.15.7.1

bgpBackwardTransition

1.3.6.1.2.1.15.7.2

OSPF Trap MIB

ospfVirtIfStateChange

1.3.6.1.2.1.14.16.2.1

ospfNbrStateChange

1.3.6.1.2.1.14.16.2.2

ospfVirtNbrStateChange

1.3.6.1.2.1.14.16.2.3

ospfIfConfigError

1.3.6.1.2.1.14.16.2.4

ospfVirtIfConfigError

1.3.6.1.2.1.14.16.2.5

ospfIfAuthFailure

1.3.6.1.2.1.14.16.2.6

ospfVirtIfAuthFailure

1.3.6.1.2.1.14.16.2.7

ospfIfRxBadPacket

1.3.6.1.2.1.14.16.2.8

ospfVirtIfRxBadPacket

1.3.6.1.2.1.14.16.2.9

ospfTxRetransmit

1.3.6.1.2.1.14.16.2.10

ospfVirtIfTxRetransmit

1.3.6.1.2.1.14.16.2.11

ospfMaxAgeLsa

1.3.6.1.2.1.14.16.2.13

ospfIfStateChange

1.3.6.1.2.1.14.16.2.16

Startup-Benachrichtigungen

RFC 1907, Management Information Base für Version 2 des Simple Network Management Protocol (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Kritisch

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Fehler

SNMPD_TRAP_ WARM_START

AuthentifizierungFailure

1.3.6.1.6.3.1.1.5.5

Bemerken

SNMPD_TRAP_ GEN_FAILURE

VRRP-Benachrichtigungen

RFC 2787, Definitionen verwalteter Objekte für das Virtual Router Redundancy Protocol

vrrpTrapNewMaster

1.3.6.1.2.1.68.0.1

Warnung

VRRPD_ NEWMASTER_ FALLE

vrrpTrapAuthFailure

1.3.6.1.2.1.68.0.2

Warnung

VRRPD_AUTH_ FAILURE_ FALLE

Tabelle 4: Unternehmensspezifische SNMPv2-Traps werden von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt

Quell-MIB

Trap-Name

SNMP-Trap-OID

Schweregrad der Systemprotokollierung

Systemprotokoll-Tag

Chassis-Benachrichtigungen (Alarmbedingungen)

Gehäuse-MIB (mib-jnx-Chassis)

jnxPowerSupplyFailure

1.3.6.1.4.1.2636.4.1.1

Warnung

CHASSISD_ SNMP_ FALLE

 

jnxFanFailure

1.3.6.1.4.1.2636.4.1.2

Kritisch

CHASSISD_ SNMP_ FALLE

 

jnxOverTemperature

1.3.6.1.4.1.2636.4.1.3

Kritisch

CHASSISD_ SNMP_ FALLE

 

jnxFruRemoval

1.3.6.1.4.1.2636.4.1.5

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruInsertion

1.3.6.1.4.1.2636.4.1.6

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruPowerOff

1.3.6.1.4.1.2636.4.1.7

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruPowerOn

1.3.6.1.4.1.2636.4.1.8

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruFailed

1.3.6.1.4.1.2636.4.1.9

Warnung

CHASSISD_ SNMP_ FALLE

 

jnxFruOffline

1.3.6.1.4.1.2636.4.1.10

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruOnline

1.3.6.1.4.1.2636.4.1.11

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxFruCheck

1.3.6.1.4.1.2636.4.1.12

Bemerken

CHASSISD_ SNMP_ FALLE

 

jnxPowerSupplyOK

1.3.6.1.4.1.2636.4.2.1

Kritisch

CHASSISD_ SNMP_ FALLE

 

jnxFanOK

1.3.6.1.4.1.2636.4.2.2

Kritisch

CHASSISD_ SNMP_ FALLE

 

jnxTemperatureOK

1.3.6.1.4.1.2636.4.2.3

Warnung

CHASSISD_ SNMP_ FALLE

Konfigurationsbenachrichtigungen

Konfigurationsmanagement-MIB (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5.0.2

Remote-Betriebsbenachrichtigungen

Ping MIB (mib-jnx-ping)

jnxPingRttThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngressThreshold Exceeded (jnxPingIngressThreshold Exceeded)

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.9

RMON-Alarme

RMON MIB (mib-jnx-rmon)

jnxRmonAlarmGetFailure

1.3.6.1.4.1.2636.4. 3.0.1

jnxRmonGetOk

1.3.6.1.4.1.2636.4. 3.0.2

SNMP-Traps werden von QFabric-Systemen unterstützt

QFabric-Systeme unterstützen Standard-SNMPv2-Traps und unternehmensspezifische SNMPv2-Traps von Juniper Networks.

HINWEIS:

QFabric-Systeme unterstützen keine SNMPv1-Traps.

Weitere Informationen finden Sie unter:

  • Tabelle 5 für Standard-SNMPv2-Traps

  • Tabelle 6 für unternehmensspezifische SNMPv2-Traps von Juniper Networks

Tabelle 5: Standard-SNMPv2-Traps, die auf QFabric-Systemen unterstützt werden

Definiert in

Trap-Name

SNMP-Trap-OID

Schweregrad der Systemprotokollierung

Syslog-Tag

Link-Benachrichtigungen

RFC 2863, The Interfaces Group MIB

linkDown

1.3.6.1.6.3.1.1.5.3

Warnung

SNMP_TRAP_ LINK_DOWN

Linkup

1.3.6.1.6.3.1.1.5.4

Informationen

SNMP_TRAP_ LINK_UP

Startup-Benachrichtigungen

RFC 1907, Management Information Base für Version 2 des Simple Network Management Protocol (SNMPv2)

coldStart

1.3.6.1.6.3.1.1.5.1

Kritisch

SNMPD_TRAP_ COLD_START

warmStart

1.3.6.1.6.3.1.1.5.2

Fehler

SNMPD_TRAP_ WARM_START

AuthentifizierungFailure

1.3.6.1.6.3.1.1.5.5

Bemerken

SNMPD_TRAP_ GEN_FAILURE

Tabelle 6: Unternehmensspezifische SNMPv2-Traps werden auf QFabric-Systemen unterstützt

Quell-MIB

Trap-Name

SNMP-Trap-OID

Schweregrad der Systemprotokollierung

Systemprotokoll-Tag

MIB für Fabric Chassis (mib-jnx-Fabric-Chassis)

Benachrichtigungen über Fabric Chassis (Alarmbedingungen)

jnxFabricPowerSupplyFailure

1.3.6.1.4.1.2636.4.19.1

Warnung

jnxFabricFanFailure

1.3.6.1.4.1.2636.4.19.2

Kritisch

jnxFabricOverTemperature

1.3.6.1.4.1.2636.4.19.3

Warnung

jnxFabricRedundancySwitchover

1.3.6.1.4.1.2636.4.19.4

Bemerken

jnxFabricFruRemoval

1.3.6.1.4.1.2636.4.19.5

Bemerken

jnxFabricFruInsertion

1.3.6.1.4.1.2636.4.19.6

Bemerken

jnxFabricFruPowerOff

1.3.6.1.4.1.2636.4.19.7

Bemerken

jnxFabricFruPowerOn

1.3.6.1.4.1.2636.4.19.8

Bemerken

jnxFabricFruFailed

1.3.6.1.4.1.2636.4.19.9

Warnung

jnxFabricFruOffline

1.3.6.1.4.1.2636.4.19.10

Bemerken

jnxFabricFruOnline

1.3.6.1.4.1.2636.4.19.11

Bemerken

jnxFabricFruCheck

1.3.6.1.4.1.2636.4.19.12

Warnung

jnxFabricFEBSwitchover

1.3.6.1.4.1.2636.4.19.13

Warnung

jnxFabricHardDiskFailed

1.3.6.1.4.1.2636.4.19.14

Warnung

jnxFabricHardDiskMissing

1.3.6.1.4.1.2636.4.19.15

Warnung

jnxFabricBootFromBackup

1.3.6.1.4.1.2636.4.19.16

Warnung

Benachrichtigungen über Fabric Chassis (Alarm deaktivierte Bedingungen)

jnxFabricPowerSupplyOK

1.3.6.1.4.1.2636.4.20.1

Kritisch

jnxFabricFanOK

1.3.6.1.4.1.2636.4.20.2

Kritisch

jnxFabricTemperatureOK

1.3.6.1.4.1.2636.4.20.3

Warnung

jnxFabricFruOK

1.3.6.1.4.1.2636.4.20.4

QFabric-MIB (mib-jnx-qf-smi)

QFabric MIB-Benachrichtigungen

jnxQFabricDownloadIssued

1.3.6.1.4.1.2636.3.42.1.0.1

jnxQFabricDownloadFailed

1.3.6.1.4.1.2636.3.42.1.0.2

jnxQFabricDownloadSuced

1.3.6.1.4.1.2636.3.42.1.0.3

jnxQFabricUpgradeIssued

1.3.6.1.4.1.2636.3.42.1.0.4

jnxQFabricUpgradeFailed

1.3.6.1.4.1.2636.3.42.1.0.5

jnxQFabricUpgradeSucceed

1.3.6.1.4.1.2636.3.42.1.0.6

Konfigurationsbenachrichtigungen

Konfigurationsmanagement-MIB (mib-jnx-cfgmgmt)

jnxCmCfgChange

1.3.6.1.4.1.2636.4.5.0.1

jnxCmRescueChange

1.3.6.1.4.1.2636.4.5.0.2

Remote-Betriebsbenachrichtigungen

Ping MIB (mib-jnx-ping)

jnxPingRttThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.1

jnxPingRttStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.2

jnxPingRttJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.3

jnxPingEgressThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.4

jnxPingEgressStdDevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.5

jnxPingEgressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.6

jnxPingIngressThreshold Exceeded (jnxPingIngressThreshold Exceeded)

1.3.6.1.4.1.2636.4.9.0.7

jnxPingIngressStddevThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.8

jnxPingIngressJitterThreshold Exceeded

1.3.6.1.4.1.2636.4.9.0.9

Beispiel: Konfigurieren von SNMP-Trap-Gruppen

Richten Sie eine Trap-Benachrichtigungsliste ein, die für Link- und Start-Traps benannt urgent-dispatcher ist. Diese Liste wird verwendet, um die Netzwerkmanagement-Hosts (1.2.3.4 und fe80::1:2:3:4) zu identifizieren, an die vom lokalen Router erzeugte Traps gesendet werden sollen. Der für eine Trapgruppe angegebene Name wird als SNMP-Community-Zeichenfolge verwendet, wenn der Agent Traps an die aufgeführten Ziele sendet.

Konfigurieren der Schnittstellen, auf denen SNMP-Anforderungen akzeptiert werden können

Standardmäßig verfügen alle Router- oder Switch-Schnittstellen über SNMP-Zugriffsrechte. Um den Zugriff nur über bestimmte Schnittstellen einzuschränken, fügen Sie die interface Anweisung auf [edit snmp] Hierarchieebene ein:

Geben Sie die Namen aller logischen oder physischen Schnittstellen an, die SNMP-Zugriffsrechte haben sollen. Alle SNMP-Anfragen, die den Router oder Switch von nicht aufgeführten Schnittstellen eingeben, werden verworfen.

Beispiel: Konfigurieren der Prüfung gesicherter Zugriffslisten

SNMP-Zugriffsrechte werden nur Geräten auf Schnittstellen so-0/0/0 und at-1/0/1. Im folgenden Beispiel wird dazu eine Liste logischer Schnittstellen konfiguriert:

Im folgenden Beispiel wird derselbe Zugriff gewährt, indem eine Liste physischer Schnittstellen konfiguriert wird:

Filtern von Schnittstelleninformationen aus SNMP Get and GetNext Output

Mit Junos OS können Sie Informationen zu bestimmten Schnittstellen aus der SNMP-Ausgabe Get und GetNext Anforderungen herausfiltern, die an schnittstellenbezogenen MIBs wie IF MIB, ATM MIB, RMON MIB und der unternehmensspezifischen IF MIB von Juniper Networks ausgeführt werden.

Sie können die folgenden Optionen der filter-interfaces Anweisung auf Hierarchieebene [edit snmp] verwenden, um die Schnittstellen anzugeben, die Sie aus SNMP Get und GetNext Abfragen ausschließen möchten:

  • interfacesSchnittstellen, die den angegebenen regulären Ausdrücken entsprechen.

  • all-internal-interfaces– Interne Schnittstellen.

Ab Version 12.1 bietet Junos OS eine Ausnahmeoption (! Operator), mit der Sie alle Schnittstellen mit Ausnahme der Schnittstellen herausfiltern können, mit Ausnahme der Schnittstellen, die allen regulären Ausdrücken entsprechen, die mit dem ! Markenzeichen präfixiert sind.

Geben Sie beispielsweise den folgenden Befehl ein, um alle Schnittstellen außer den ge Schnittstellen aus SNMP get und get-next Ergebnissen herauszufiltern:

Wenn dies konfiguriert ist, filtert Junos OS alle Schnittstellen außer den ge Schnittstellen aus SNMP get und get-next den Ergebnissen heraus.

HINWEIS:

Das ! Markenzeichen wird nur als erstes Zeichen des regulären Ausdrucks unterstützt. Wenn er an anderer Stelle in einem regulären Ausdruck angezeigt wird, hält Junos OS den regulären Ausdruck für ungültig und gibt einen Fehler zurück.

Beachten Sie jedoch, dass diese Einstellungen auf SNMP-Vorgänge beschränkt sind, und die Benutzer weiterhin auf Informationen zu den Schnittstellen zugreifen können (einschließlich der mit den filter-interfaces Optionen ausgeblendeten) Mithilfe der entsprechenden Befehlszeilenschnittstelle (CLI) von Junos OS.

Konfigurieren von MIB-Ansichten

SNMPv3 definiert das Konzept der MIB-Ansichten in RFC 3415, View-based Access Control Model (VACM) für das Simple Network Management Protocol (SNMP). MIB-Ansichten bieten einem Agenten eine bessere Kontrolle darüber, wer innerhalb seiner MIB-Struktur auf bestimmte Zweigstellen und Objekte zugreifen kann. Eine Ansicht besteht aus einem Namen und einer Sammlung von SNMP-Objektbezeichnern, die entweder explizit einbezogen oder ausgeschlossen werden. Nach der Definition wird dann einer SNMPv3-Gruppe oder einer SNMPv1/v2c-Community (oder mehreren Communitys) eine Ansicht zugewiesen, wodurch automatisch maskiert wird, welche Teile der MIB-Struktur des Agenten Mitglieder der Gruppe oder Community zugreifen können (oder nicht).

Standardmäßig gewährt eine SNMP-Community Lesezugriff und verweigert den Schreibzugriff auf alle unterstützten MIB-Objekte (sogar Communities, die als konfiguriert wurden authorization read-write). Um Lese- oder Schreibzugriff auf eine Reihe von MIB-Objekten einzuschränken oder zu gewähren, müssen Sie eine MIB-Ansicht konfigurieren und die Ansicht einer Community zuweisen.

Um MIB-Ansichten zu konfigurieren, fügen Sie die view Anweisung auf [edit snmp] Hierarchieebene ein:

Die view Anweisung definiert eine MIB-Ansicht und identifiziert eine Gruppe von MIB-Objekten. Jedes MIB-Objekt einer Ansicht hat ein OID-Präfix (Common Object Identifier). Jeder Objektbezeichner stellt einen Teilbaum der MIB-Objekthierarchie dar. Der Unterbaum kann entweder durch eine Abfolge von gestrichelten Ganzzahlen (z 1.3.6.1.2.1.2. B.) oder durch seinen Unterbaumnamen (z interfaces. B. ) dargestellt werden. Eine Konfigurationsaussage verwendet eine Ansicht, um eine Gruppe von MIB-Objekten anzugeben, auf die der Zugriff definiert werden soll. Sie können auch ein Platzhalterzeichensternchen (*) verwenden, um OIDs einzubeziehen, die einem bestimmten Muster in der SNMP-Ansicht entsprechen. Sie müssen * verwenden, damit jeder Unter-OIDs übereinstimmt. Verwenden Sie beispielsweise OID-Schnittstellen.*.*.123, um mit OID-Schnittstellen zu übereinstimmen.2.1.2.123. Wildcard-Schnittstellen.*.123 entspricht nicht mit OID-Schnittstellen.2.1.2.123. Um eine Ansicht zu aktivieren, müssen Sie die Ansicht einer Community zuordnen.

Um eine OID vollständig zu entfernen, verwenden Sie den delete view all oid oid-number Befehl, lassen aber den include Parameter aus.

Im folgenden Beispiel wird eine MIB-Ansicht namens ping-mib-view erstellt. Für die oid Anweisung ist kein Punkt am Anfang des Objektbezeichners erforderlich. Die snmp view Anweisung umfasst die Zweigstelle unter der Objektkennung .1.3.6.1.2.1.80. Dazu gehört der gesamte DISMAN-PINGMIB-Teilbaum (wie in RFC 2925, Definitionen verwalteter Objekte für Remote-Ping-, Traceroute- und Lookup-Operationen definiert), der effektiv den Zugriff auf jedes Objekt unter dieser Zweigstelle ermöglicht.

Im folgenden Beispiel wird eine zweite Zweigstelle in derselben MIB-Ansicht hinzugefügt.

Weisen Sie einer Community, die Sie steuern möchten, eine MIB-Ansicht zu.

Um MIB-Ansichten einer Community zu zuordnen, fügen Sie die view Aussage auf [edit snmp community community-name] Hierarchieebene ein:

Weitere Informationen zur Ping-MIB finden Sie unter RFC 2925 und PING MIB.

Konfigurieren von Ping-Proxy-MIB

Beschränken Sie die ping-mib Community auf Lese- und Schreibzugriff der Ping-MIB und jnxpingMIB nur. Der Lese- oder Schreibzugriff auf andere MIB, die diese Community nutzen, ist nicht gestattet.

Die folgende Konfiguration verhindert, dass die no-ping-mib Community auf Ping-MIB und jnxPingMIB Objekte zugreifen kann. Diese Konfiguration hindert die no-ping-mib Community jedoch nicht daran, auf ein anderes MIB-Objekt zuzugreifen, das auf dem Gerät unterstützt wird.

Verständnis der integrierten lokalen Managementschnittstelle

Die integrierte lokale Managementschnittstelle (ILMI) bietet einen Mechanismus für Asynchronübertragungsmodus (ATM)-angeschlossene Geräte wie Hosts, Router und ATM-Switches, um Verwaltungsinformationen zu übertragen. ILMI ermöglicht den bidirektionalen Austausch von Verwaltungsinformationen zwischen zwei ATM-Schnittstellen über eine physische Verbindung. ILMI-Informationen werden über eine direkte Kapselung von SNMP Version 1 (RFC 1157, A Simple Network Management Protocol) über ATM Adaptation Layer 5 (AAL5) unter Verwendung eines virtuellen Pfadbezeichners/Virtual Channel Identifier (VPI/VCI)-Werts (VPI=0, VCI=16) ausgetauscht.

Junos OS unterstützt nur zwei ILMI-MIB-Variablen: atmfMYIPNmAddress und atmfPortMyIfname. Für intelligente Warteschlangenschnittstellen (IQ) ATM1 und ATM2 können Sie ILMI so konfigurieren, dass es direkt mit einem angeschlossenen ATM-Switch kommuniziert, um die Abfrage der IP-Adresse und Portnummer des Switches zu ermöglichen.

Weitere Informationen zur ILMI-MIB finden Sie atmfMYIPNmAddress unter oder atmfPortMyIfname im SNMP MIB-Explorer.

MIB für Versorgungsunternehmen

Die unternehmensspezifische Dienstprogramm-MIB von Juniper Networks, deren Objekt-ID {jnxUtilMibRoot 1} lautet, definiert Objekte für Zähler, Ganze Zahlen und Zeichenfolgen. Die MIB des Dienstprogramms enthält eine Tabelle für jeden der folgenden fünf Datentypen:

  • 32-Bit-Zähler

  • 64-Bit-Zähler

  • Signierte Ganzzahlen

  • Ganzzahlen ohne Vorzeichen

  • Oktett-Strings

Jeder Datentyp hat einen beliebigen ASCII-Namen, der definiert ist, wenn die Daten aufgefüllt werden, und einen Zeitstempel, der den letzten Zeitpunkt der Änderung der Dateninstanz anzeigt. Eine Version zum Herunterladen dieser MIB finden Sie unter Routing-Richtlinien, Firewall-Filter und Traffic Policers-Benutzerhandbuch.

Informationen zu den unternehmensspezifischen MIB-Objekten für Dienstprogramme finden Sie in den folgenden Themen:

Unterstützung für SNMP-MIBs

Die eigenständigen Switches der QFX-Serie, Virtual Chassis der QFX-Serie und QFabric-Systeme unterstützen Standard-MIBs und unternehmensspezifische MIBs von Juniper Networks.

HINWEIS:

Informationen zu unternehmensspezifischen SNMP-MIB-Objekten finden Sie im SNMP MIB-Explorer. Sie können SNMP MIB Explorer verwenden, um Informationen zu verschiedenen MIBs, MIB-Objekten und SNMP-Benachrichtigungen anzuzeigen, die auf Geräten von Juniper Networks unterstützt werden.

Weitere Informationen finden Sie unter:

MIBs werden von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt

Die eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützen sowohl Standard-MIBs als auch unternehmensspezifische MIBs von Juniper Networks. Weitere Informationen finden Sie unter:

  • Tabelle 7 für Standard-MIBs.

  • Tabelle 8 für unternehmensspezifische MIBs von Juniper Networks.

Tabelle 7: Standard-MIBs, die von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt werden

RFC

Zusätzliche Informationen

IEEE 802.1ab, Abschnitt 12.1, Link Layer Discovery Protocol (LLDP) MIB

Unterstützte Tabellen und Objekte:

  • lldpRemManAddrOID

  • lldpLocManAddrOID

  • lldpReinitDelay

  • lldpNotificationInterval

  • lldpStatsRxPortFramesDiscardedTotal

  • lldpStatsRxPortFramesError

  • lldpStatsRxPortTLVsDiscardedTotal

  • lldpStatsRxPortTLVsUnerkanntTotal

  • lldpStatsRxPortAgeoutsTotal

IEEE 802.3ad, Aggregation mehrerer Verbindungssegmente

Die folgenden Tabellen und Objekte werden unterstützt:

  • dot3adAggPortTable, dot3adAggAggPortListTable, dot3adAggTable und dot3adAggPortStatsTable

  • dot3adAggPortDebugTable (nur dot3adAggPortDebugRxState, dot3adAggPortDebugMuxState, dot3adAggPortDebugActorSyncTransitionCount, dot3adAggPortDebugPartnerSyncTransitionCount, dot3adAggPortDebugActorChangeCount und dot3adAggPortDebugPartnerChangeCount)

  • dot3adTablesLastChanged

RFC 1155, Struktur und Identifizierung von Managementinformationen für TCP/IP-basierte Internets

RFC 1157, ein einfaches Network Management Protocol (SNMP)

RFC 1212, Präzise MIB-Definitionen

RFC 1213, Management Information Base für das Netzwerkmanagement von TCP/IP-basierten Interneten: MIB-II

Die folgenden Bereiche werden unterstützt:

  • MIB II und ihre SNMP-Version 2-Derivate, einschließlich:

    • Statistikzähler

    • IP, außer ipRouteTable, die durch ipCidrRouteTable ersetzt wurde (RFC 2096, IP Forwarding Table MIB)

    • ipAddrTable

    • SNMP-Verwaltung

    • Schnittstellenverwaltung

  • SNMPv1 Get, GetNext Anfragen und SNMPv2-Anfrage GetBulk

  • Junos OS-spezifische Liste gesicherter Zugriffe

  • Hauptkonfigurations-Keywords

  • Neukonfigurationen bei SIGHUP

RFC 1215, eine Konvention zur Definition von Traps für die Verwendung mit SNMP

Die Unterstützung ist auf MIB II SNMP Version 1 Traps und Version 2-Benachrichtigungen beschränkt.

RFC 1286, Definitionen verwalteter Objekte für Bridges

RFC 1657, Definitionen verwalteter Objekte für die vierte Version des Border Gateway Protocol (BGP-4) mit SMIv2

RFC 1850, Management Information Base der OSPF-Version 2

Die folgenden Tabellen, Objekte und Traps werden nicht unterstützt:

  • Hosttabelle

  • ospfOriginateNewLsas und ospfRxNewLsas-Objekte

  • ospfOriginateLSA, ospfLsdbOverflow und ospfLsdbApproachingOverflow-Traps

RFC 1901, Einführung in communitybasiertes SNMPv2

RFC 1905, Protokollbetrieb für Version 2 des Simple Network Management Protocol (SNMPv2)

RFC 1907, Management Information Base für Version 2 des Simple Network Management Protocol (SNMPv2)

RFC 2011, SNMPv2 Management Information Base für Internet Protocol mit SMIv2

RFC 2012, SNMPv2 Management Information Base für das Transmission Control Protocol mit SMIv2

RFC 2013, SNMPv2 Management Information Base für das User Datagram Protocol mit SMIv2

RFC 2233, The Interfaces Group MIB mit SMIv2

HINWEIS:

RFC 2233 wurde durch RFC 2863 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2233 als auch RFC 2863.

RFC 2287, Definitionen verwalteter Objekte auf Systemebene für Anwendungen

Folgende Objekte werden unterstützt:

  • sysApplInstallPkgTable

  • sysApplInstallElmtTable

  • sysApplElmtRunTable

  • sysApplMapTable

RFC 2570, Einführung in Version 3 des Internet-Standard Network Management Framework

RFC 2571, Eine Architektur zur Beschreibung von SNMP-Management-Frameworks (schreibgeschützter Zugriff)

HINWEIS:

RFC 2571 wurde durch RFC 3411 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2571 als auch RFC 3411.

RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) ( schreibgeschützter Zugriff)

HINWEIS:

RFC 2572 wurde durch RFC 3412 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2572 als auch RFC 3412.

RFC 2576, Koexistenz zwischen Version 1, Version 2 und Version 3 des Internet-Standard Network Management Framework

HINWEIS:

RFC 2576 wurde durch RFC 3584 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2576 als auch RFC 3584.

RFC 2578, Struktur der Verwaltungsinformationen Version 2 (SMIv2)

RFC 2579, Textkonventionen für SMIv2

RFC 2580, Konformitätserklärungen für SMIv2

RFC 2665, Definitionen verwalteter Objekte für ethernetähnliche Schnittstellentypen

RFC 2787, Definitionen verwalteter Objekte für das Virtual Router Redundancy Protocol

Die Unterstützung umfasst nicht die Zeilenerstellung, den Vorgang Set und das vrrpStatsPacketLengthErrors-Objekt.

RFC 2790, MIB für Hostressourcen

Die Unterstützung ist auf die folgenden Objekte beschränkt:

  • Nur hrStorageTable. Das Dateisystem /, /config, und /var/tmp geben immer dieselbe Indexnummer zurück. Wenn SNMP neu gestartet wird, ändern sich möglicherweise die Indexnummern für die verbleibenden Dateisysteme.

  • Nur die Objekte der Gruppen hrSystem und hrSWInstalled.

RFC 2819, Management-Informationsdatenbank für Remote-Netzwerküberwachung

Folgende Objekte werden unterstützt:

  • etherStatsTable (nur für Ethernet-Schnittstellen), alarmTable, eventTable und logTable.

  • historyControlTable und etherHistoryTable (außer dem etherHistoryUtilization-Objekt).

RFC 2863, The Interfaces Group MIB

HINWEIS:

RFC 2233 wurde durch RFC 2863 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2233 als auch RFC 2863.

RFC 2932, IPv4 Multicast-Routing-MIB

RFC 2933, INTERNET Group Management Protocol (IGMP) MIB

RFC 2934, Protokollunabhängige Multicast-MIB für IPv4

In Junos OS wird RFC 2934 basierend auf einer Entwurfsversion, pimmib.mib, des jetzt Standard-RFC implementiert.

RFC 3410, Einführung und Anwendbarkeitsaussagen für Internet Standard Management Framework

RFC 3411, eine Architektur zur Beschreibung von SNMP-Management-Frameworks (Simple Network Management Protocol)

HINWEIS:

RFC 3411 ersetzt RFC 2571. Junos OS unterstützt jedoch sowohl RFC 3411 als auch RFC 2571.

RFC 3412, Nachrichtenverarbeitung und -versendung für das Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3412 ersetzt RFC 2572. Junos OS unterstützt jedoch sowohl RFC 3412 als auch RFC 2572.

RFC 3413, SNMP-Anwendungen (Simple Network Management Protocol)

Mit Ausnahme der Proxy-MIB werden alle MIBs unterstützt.

RFC 3414, Benutzerbasiertes Sicherheitsmodell (USM) für Version 3 des Simple Network Management Protocol (SNMPv3)

RFC 3415, Ansichtsbasiertes Zugriffssteuerungsmodell (VACM) für SNMP (Simple Network Management Protocol)

RFC 3416, Version 2 des Protocol Operations for the Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3416 ersetzt RFC 1905, der in früheren Versionen von Junos OS unterstützt wurde.

RFC 3417, Transportzuordnungen für das Simple Network Management Protocol (SNMP)

RFC 3418, Management Information Base (MIB) für das Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3418 ersetzt RFC 1907, der in früheren Versionen von Junos OS unterstützt wurde.

RFC 3584, Koexistenz zwischen Version 1, Version 2 und Version 3 des Internet-Standard Network Management Framework

RFC 3826, AES-Verschlüsselungsalgorithmus (Advanced Encryption Standard) Cipher-Algorithmus im SNMP-benutzerbasierten Sicherheitsmodell

RFC 4188, Definitionen verwalteter Objekte für Bridges

Die Switches QFX3500 und QFX3600 unterstützen 802.1D STP (1998) und nur die folgenden Unterbäume und Objekte:

  • dot1dTp subbaum – dot1dTpFdbAddress, dot1dTpFdbPort und dot1dTpFdbStatus-Objekte aus der dot1dTpFdbTable-Tabelle.

  • dot1dBase-Subbaum – dot1dBasePort und dot1dBasePortIfIndex-Objekte aus der dot1dBasePortTable-Tabelle.

HINWEIS:

Auf QFX3500- und QFX3600-Switches wird die dot1dTpFdbTable-Tabelle nur mit MAC-Adressen aufgefüllt, die im Standard-VLAN gelernt wurden. Um die MAC-Adressen aller VLANs zu sehen, geben Sie die dot1qTpFdbTable-Tabelle (RFC 4363b, Q-Bridge VLAN MIB) an, wenn Sie den show snmp mib walk Befehl ausstellen.

Wird auf Geräten der OCX-Serie nicht unterstützt.

RFC 4293, Management Information Base for the Internet Protocol (IP)

Unterstützt nur die IpAddrTable-Tabelle.

RFC 4318, Definitionen verwalteter Objekte für Bridges mit Rapid Spanning Tree Protocol

Unterstützt 802.1w- und 802.1t-Erweiterungen für RSTP.

Wird auf Geräten der OCX-Serie nicht unterstützt.

RFC 4363b, Q-Bridge VLAN MIB

HINWEIS:

Auf QFX3500- und QFX3600-Switches wird die dot1dTpFdbTable-Tabelle (RFC 4188, Definitionen verwalteter Objekte für Bridges) nur mit MAC-Adressen aufgefüllt, die im Standard-VLAN gelernt wurden. Um die MAC-Adressen aller VLANs zu sehen, geben Sie die dot1qTpFdbTable-Tabelle (in dieser MIB) an, wenn Sie den show snmp mib walk Befehl ausstellen.

Wird auf Geräten der OCX-Serie nicht unterstützt.

RFC 4444, IS-IS MIB

Internet Assigned Numbers Authority, IANAiftype Textual Convention MIB (referenziert durch RFC 2233)

Siehe http://www.iana.org/assignments/ianaiftype-mib .

Internet draft-reeder-snmpv3-usm-3desede-00.txt, Extension to the User-Based Security Model (USM) to Support Triple-DES EDE in 'Outside' CBC Mode

Internet Draft-ietf-idmr-igmp-mib-13.txt, Internet Group Management Protocol (IGMP) MIB

MIB des ESO-Konsortiums

HINWEIS:

Die MIB des ESO-Konsortiums wurde durch RFC 3826 ersetzt. Siehe http://www.snmp.com/eso/.

Tabelle 8: Unternehmensspezifische MIBs von Juniper Networks, die von eigenständigen Switches der QFX-Serie und Virtual Chassis der QFX-Serie unterstützt werden

MIB

Beschreibung

Alarm-MIB (mib-jnx-Chassis-Alarm)

Bietet Unterstützung für Alarme vom Switch.

MIB-Analyse (mib-jnx-Analyzer)

Enthält Analyse- und Remote-Analysedaten im Zusammenhang mit Portspiegelung.

Wird auf Geräten der OCX-Serie nicht unterstützt.

Gehäuse-MIB (mib-jnx-Chassis)

Bietet Unterstützung für Die Umgebungsüberwachung (Zustand des Netzteils, Boardspannungen, Lüfter, Temperaturen und Luftstrom) und Bestandsunterstützung für Gehäuse, Flexible PIC Concentrators (FPCs) und PICs.

HINWEIS:

Die jnxLEDTable-Tabelle wurde veraltet.

Gehäusedefinitionen für Routermodell-MIB (mib-jnx-chas-defines)

Enthält die Objektbezeichner (OIDs), die von der Chassis-MIB zur Identifizierung von Routing- und Switching-Plattformen und Gehäusekomponenten verwendet werden. Die Gehäuse-MIB liefert Informationen, die sich häufig ändern, während die Gehäusedefinitionen für Routermodell-MIB Informationen liefern, die weniger häufig geändert werden.

Class-of-Service MIB (mib-jnx-cos)

Bietet Unterstützung für die Überwachung von Schnittstellen-Ausgabewarteschlangenstatistiken pro Schnittstelle und Weiterleitungsklasse.

Konfigurationsmanagement-MIB (mib-jnx-cfgmgmt)

Bietet Benachrichtigungen für Konfigurationsänderungen und Wiederherstellungskonfigurationsänderungen in Form von SNMP-Traps. Jeder Trap enthält den Zeitpunkt, zu dem die Konfigurationsänderung vorgenommen wurde, den Namen des Benutzers, der die Änderung vorgenommen hat, und die Methode, mit der die Änderung vorgenommen wurde.

Ein Verlauf der letzten 32 Konfigurationsänderungen wird in jnxCmChgEventTable aufbewahrt.

Ethernet MAC MIB (mib-jnx-mac)

Überwacht MAC-Statistiken (Media Access Control) für Gigabit Ethernet Intelligente Warteschlangenschnittstellen (IQ). Es erfasst MAC-Statistiken; zum Beispiel Inoctets, Inframes, Outoctets und Outframes auf jeder Quell-MAC-Adresse und VLAN-ID für jeden Ethernet-Port.

Wird auf Geräten der OCX-Serie nicht unterstützt.

Ereignis-MIB (mib-jnx-event)

Definiert eine generische Trap, die mithilfe eines Betriebsskripts oder einer Ereignisrichtlinie generiert werden kann. Diese MIB bietet die Möglichkeit, eine Systemprotokollzeichenfolge anzugeben und eine Trap auszuheben, wenn diese Systemprotokollzeichenfolge gefunden wird.

Wenn Sie in Junos OS Version 13.2X51-D10 oder höher eine Ereignisrichtlinie so konfiguriert haben, dass eine Trap ausgelöst wird, wenn ein neues SNMP-Trap-Ziel hinzugefügt wird, wird die SNMPD_TRAP_TARGET_ADD_NOTICE Trap mit Informationen über das neue Ziel generiert.

Firewall MIB (mib-jnx-Firewall)

Bietet Unterstützung für die Überwachung von Firewall-Filterzählern .

MIB für Hostressourcen (mib-jnx-Hostressourcen)

Erweitert das hrStorageTable-Objekt und gibt einen Maßstab für die Nutzung jedes Dateisystems auf dem Switch als Prozentsatz an. Zuvor haben die Objekte in der hrStorageTable die Verwendung nur in Allokationseinheiten gemessen – hrStorageUsed und hrStorageAllocationUnits. Mithilfe der Prozentmessung können Sie Nutzungsschwellenwerte einfacher überwachen und anwenden.

SCHNITTSTELLEN-MIB (Erweiterungen) (mib-jnx-if-extensions)

Erweitert den Standard ifTable (RFC 2863) um zusätzliche Statistiken und unternehmensspezifische Chassis-Informationen von Juniper Networks in den Tabellen ifJnxTable und ifChassisTable.

L2ALD MIB (mib-jnx-l2ald)

Bietet Informationen zu Layer 2 Address Learning und damit verbundenen Traps, wie z. B. mac-Limit-Trap der Routing-Instanz und Mac-Limit-Trap der Schnittstelle. Diese MIB stellt auch VLAN-Informationen in der jnxL2aldVlanTable-Tabelle für ELS-Switches (Enhanced Layer 2 Software) der EX- und QFX-Serie bereit.

HINWEIS:

Switches der EX-Serie ohne ELS verwenden die VLAN MIB (jnxExVlanTable) für VLAN-Informationen anstelle dieser MIB.

MPLS MIB (mib-jnx-mpls)

Stellt MPLS-Informationen bereit und definiert MPLS-Benachrichtigungen.

HINWEIS:

Diese MIB wird auf dem QFX5100-Switch nicht unterstützt.

MPLS LDP MIB (mib-jnx-mpls-ldp)

Enthält Objektdefinitionen wie in RFC 3815, Definitionen verwalteter Objekte für multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) beschrieben.

HINWEIS:

Diese MIB wird auf dem QFX5100-Switch nicht unterstützt.

Ping MIB (mib-jnx-ping)

Erweitert die standardmäßige Ping-MIB-Steuerungstabelle (RFC 2925). Elemente in dieser MIB werden erstellt, wenn Einträge in der pingCtlTable der Ping-MIB erstellt werden. Jedes Element wird genau wie in der Ping-MIB indiziert.

MIB für RMON-Ereignisse und -Alarme (mib-jnx-rmon)

Unterstützt Junos OS-Erweiterungen der standardmäßigen Remote Monitoring (RMON) Events and Alarms MIB (RFC 2819). Die Erweiterung ergänzt das alarmTable-Objekt um zusätzliche Informationen zu jedem Alarm. Es werden auch zwei zusätzliche Traps definiert, die anzeigen, wenn Probleme mit einem Alarm auftreten.

Struktur der MIB für Managementinformationen (mib-jnx-smi)

Erläutert die Struktur der unternehmensspezifischen MIBs von Juniper Networks.

MIB für Systemprotokoll (mib-jnx-syslog)

Aktiviert die Benachrichtigung über eine SNMP-Trap-basierte Anwendung, wenn eine wichtige Systemprotokollnachricht auftritt.

MIB für Versorgungsunternehmen (mib-jnx-util)

Stellt Ihnen SNMP MIB-Containerobjekte der folgenden Typen bereit: 32-Bit-Zähler, 64-Bit-Zähler, signierte Ganzzahlen, unsignierte Ganzzahlen und Oktettzeichenfolgen. Sie können diese Objekte verwenden, um Daten zu speichern, die mit anderen SNMP-Vorgängen abgerufen werden können.

VLAN-MIB (mib-jnx-vlan)

Enthält Informationen zu vorstandardbasierten IEEE 802.10-VLANs und deren Zuordnung zu LAN-Emulations-Clients.

HINWEIS:

Für Switches der ELS EX-Serie und Switches der QFX-Serie sind VLAN-Informationen in der L2ALD MIB in der jnxL2aldVlanTable-Tabelle statt in der VLAN-MIB Verfügbar Bei Switches der EX-Serie, die nicht der ELS-Serie gehören, werden VLAN-Informationen in der VLAN-MIB in der jnxExVlanTable-Tabelle bereitgestellt.

Wird auf Geräten der OCX-Serie nicht unterstützt.

MIBs, die von QFabric-Systemen unterstützt werden

Die QFabric-Systeme unterstützen sowohl Standard-MIBs als auch unternehmensspezifische MIBs von Juniper Networks. Weitere Informationen finden Sie unter:

  • Tabelle 9 für Standard-MIBs.

  • Tabelle 10 für unternehmensspezifische MIBs von Juniper Networks.

Tabelle 9: Von QFabric Systems unterstützte Standard-MIBs

RFC

Zusätzliche Informationen

RFC 1155, Struktur und Identifizierung von Managementinformationen für TCP/IP-basierte Internets

RFC 1157, ein einfaches Network Management Protocol (SNMP)

RFC 1212, Präzise MIB-Definitionen

RFC 1213, Management Information Base für das Netzwerkmanagement von TCP/IP-basierten Interneten: MIB-II

Die folgenden Bereiche werden unterstützt:

  • MIB II und ihre SNMP-Version 2-Derivate, einschließlich:

    • Statistikzähler

    • IP, außer ipRouteTable, die durch ipCidrRouteTable ersetzt wurde (RFC 2096, IP Forwarding Table MIB)

    • ipAddrTable

    • SNMP-Verwaltung

    • Schnittstellenverwaltung

  • SNMPv1 Get, GetNext Anfragen und Version 2-Anfrage GetBulk

  • Junos OS-spezifische Liste gesicherter Zugriffe

  • Hauptkonfigurations-Keywords

  • Neukonfigurationen bei SIGHUP

RFC 1215, eine Konvention zur Definition von Traps für die Verwendung mit SNMP

Die Unterstützung ist auf MIB II SNMP Version 1 Traps und Version 2-Benachrichtigungen beschränkt.

RFC 1286, Definitionen verwalteter Objekte für Bridges

RFC 1901, Einführung in communitybasiertes SNMPv2

RFC 1905, Protokollbetrieb für Version 2 des Simple Network Management Protocol (SNMPv2)

RFC 1907, Management Information Base für Version 2 des Simple Network Management Protocol (SNMPv2)

RFC 2011, SNMPv2 Management Information Base für Internet Protocol mit SMIv2

HINWEIS:

Auf dem QFabric-System müssen Sie die IP-Adresse mindestens einer Schnittstelle neben den Verwaltungs-Ethernet-Schnittstellen (me0 und me1) in der Director-Gruppe konfigurieren, damit die SNMP-mibwalk-Anforderung funktioniert.

RFC 2012, SNMPv2 Management Information Base für das Transmission Control Protocol mit SMIv2

RFC 2013, SNMPv2 Management Information Base für das User Datagram Protocol mit SMIv2

RFC 2233, The Interfaces Group MIB mit SMIv2

HINWEIS:

RFC 2233 wurde durch RFC 2863 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2233 als auch RFC 2863.

HINWEIS:

Das QFabric-System unterstützt nur die folgenden Objekte: ifNumber, ifTable und ifxTable.

RFC 2571, Eine Architektur zur Beschreibung von SNMP-Management-Frameworks (schreibgeschützter Zugriff)

HINWEIS:

RFC 2571 wurde durch RFC 3411 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2571 als auch RFC 3411.

RFC 2572, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) ( schreibgeschützter Zugriff)

HINWEIS:

RFC 2572 wurde durch RFC 3412 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2572 als auch RFC 3412.

RFC 2576, Koexistenz zwischen Version 1, Version 2 und Version 3 des Internet-Standard Network Management Framework

HINWEIS:

RFC 2576 wurde durch RFC 3584 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2576 als auch RFC 3584.

RFC 2578, Struktur der Verwaltungsinformationen Version 2 (SMIv2)

RFC 2579, Textkonventionen für SMIv2

RFC 2580, Konformitätserklärungen für SMIv2

RFC 2665, Definitionen verwalteter Objekte für ethernetähnliche Schnittstellentypen

Das QFabric-System unterstützt nur die folgenden Tabellen:

  • dot3StatsTable: Es gibt eine Zeile mit Statistiken für jede Ethernet-ähnliche Schnittstelle im QFabric-System. Der dot3StatsIndex ist ein systemweit eindeutiger Schnittstellenindex.

  • dot3ControlTable: Diese Tabelle enthält eine Zeile für jede Ethernet-ähnliche Schnittstelle im QFabric-System, das die MAC-Steuer-Sublayer implementiert. Unterstützte OIDs sind dot3ControlFunctionsSupported und dot3ControlInUnknownOpcode.

  • dot3PauseTable: Diese Tabelle enthält eine Zeile für jede Ethernet-ähnliche Schnittstelle im QFabric-System, die die PAUSE-Funktion des MAC-Steuerelements unterstützt. Unterstützte OIDs sind dot3PauseAdminMode, dot3PauseOperMode, dot3InPauseFrames und dot3OutPauseFrames.

HINWEIS:

Scalar-Variablen werden auf dem QFabric-System nicht unterstützt.

RFC 2863, The Interfaces Group MIB

HINWEIS:

RFC 2233 wurde durch RFC 2863 ersetzt. Junos OS unterstützt jedoch sowohl RFC 2233 als auch RFC 2863.

HINWEIS:

Das QFabric-System unterstützt nur die folgenden Objekte: ifNumber, ifTable und ifxTable.

RFC 2933, INTERNET Group Management Protocol (IGMP) MIB

RFC 3410, Einführung und Anwendbarkeitsaussagen für Internet Standard Management Framework

RFC 3411, eine Architektur zur Beschreibung von SNMP-Management-Frameworks (Simple Network Management Protocol)

HINWEIS:

RFC 3411 ersetzt RFC 2571. Junos OS unterstützt jedoch sowohl RFC 3411 als auch RFC 2571.

RFC 3412, Nachrichtenverarbeitung und -versendung für das Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3412 ersetzt RFC 2572. Junos OS unterstützt jedoch sowohl RFC 3412 als auch RFC 2572.

RFC 3416, Version 2 des Protocol Operations for the Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3416 ersetzt RFC 1905, der in früheren Versionen von Junos OS unterstützt wurde.

RFC 3417, Transportzuordnungen für das Simple Network Management Protocol (SNMP)

RFC 3418, Management Information Base (MIB) für das Simple Network Management Protocol (SNMP)

HINWEIS:

RFC 3418 ersetzt RFC 1907, der in früheren Versionen von Junos OS unterstützt wurde.

RFC 3584, Koexistenz zwischen Version 1, Version 2 und Version 3 des Internet-Standard Network Management Framework

RFC 4188, Definitionen verwalteter Objekte für Bridges

Die QFabric-Systemunterstützung ist auf die folgenden Objekte beschränkt:

  • Unter der dot1dBase-OID unterstützt die dot1dBasePortTable-Tabelle nur die ersten beiden Spalten in der Tabelle: dot1dBasePort und dot1dBasePortIfIndex.

  • Das System implementiert die optionalen Traps, die dot1dNotifications (dot1dBridge 0) unterstützen, nicht.

  • Unter der dot1dStp OID unterstützt nur die dot1dStpPortTable-Tabelle. Unterstützt die Skalarvariablen unter dot1dStp nicht.

  • Das System unterstützt keine Skalarvariablen unter dot1dTp, aber darin wird die dot1dTpFdbTable-Tabelle unterstützt (dot1dBridge 4).

  • Für OIDS, die nur Tabellen unterstützen, sind Skalarwerte, die vom SNMP-Agenten zurückgegeben werden, möglicherweise nicht sinnvoll und werden daher für die Verwendung nicht empfohlen.

Wird auf Geräten der OCX-Serie nicht unterstützt.

RFC 4293, Management Information Base for the Internet Protocol (IP)

Unterstützt nur die IpAddrTable-Tabelle.

Im QFabric-System werden folgende Objekte in der ipAddrTable-Tabelle unterstützt: ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask, ipAdEntBcastAddr und ipAdEntReasmMaxSize.

HINWEIS:

Auf dem QFabric-System müssen Sie die IP-Adresse mindestens einer Schnittstelle neben den Verwaltungs-Ethernet-Schnittstellen (me0 und me1) in der Director-Gruppe konfigurieren, damit die SNMP-mibwalk-Anforderung funktioniert.

RFC 4363b, Q-Bridge VLAN MIB

Das QFabric-System unterstützt nur die folgenden Tabellen:

  • dot1qTpFdbTable

  • dot1qVlanStaticTable

  • dot1qPortVlanTable

  • dot1qFdbTable

Wird auf Geräten der OCX-Serie nicht unterstützt.

HINWEIS:

QFabric-spezifische MIBs werden auf Geräten der OCX-Serie nicht unterstützt.

Tabelle 10: Unternehmensspezifische MIBs von Juniper Networks, die von QFabric-Systemen unterstützt werden

MIB

Beschreibung

MIB-Analyse (mib-jnx-Analyzer)

Enthält Analyse- und Remote-Analysedaten im Zusammenhang mit Portspiegelung.

Das QFabric-System unterstützt:

  • Analysetabelle – jnxAnalyzerName, jnxMirroringRatio, jnxLossPriority.

  • Eingabetabelle des Analysegeräts – jnxAnalyzerInputValue, jnxAnalyzerInputOption, jnxAnalyzerInputType.

  • Analyse-Ausgabetabelle – jnx AnalyzerOutputValue, jnxAnalyzerOutputType.

Gehäuse-MIB (mib-jnx-Chassis)

HINWEIS:

Die Chassis-MIB wurde für das QFabric-System veraltet. Wir empfehlen, für Informationen zum QFabric-System die Fabric Chassis-MIB (mib-jnx-fabric-chassis) zu verwenden.

Class-of-Service MIB (mib-jnx-cos)

Bietet Unterstützung für die Überwachung von Schnittstellen-Ausgabewarteschlangenstatistiken pro Schnittstelle und Weiterleitungsklasse.

Das QFabric-System unterstützt die folgenden Tabellen und Objekte:

  • Jnxcosifstatflagtable – jnxCosIfstatFlags und jnxCosIfIndex.

  • Jnxcosqstattable – jnxCosQstatTxedPkts, jnxCosQstatTxedPktRate, jnxCosQstatTxedBytes und jnxCosQstatTxedByteRate.

  • Jnxcosfcidtable – jnxCosFcIdToFcName.

  • Jnxcosfctable – jnxCosFcQueueNr.

Das QFabric-System unterstützt keine Traps für diese MIB.

Konfigurationsmanagement-MIB (mib-jnx-cfgmgmt)

Bietet Benachrichtigungen für Konfigurationsänderungen und Wiederherstellungskonfigurationsänderungen in Form von SNMP-Traps. Jeder Trap enthält den Zeitpunkt, zu dem die Konfigurationsänderung vorgenommen wurde, den Namen des Benutzers, der die Änderung vorgenommen hat, und die Methode, mit der die Änderung vorgenommen wurde.

Ein Verlauf der letzten 32 Konfigurationsänderungen wird in jnxCmChgEventTable aufbewahrt.

HINWEIS:

Auf dem QFabric-System gelten folgende Bedingungen:

  • Alle Scalar-Variablen unter der jnxCmCfgChg-Tabelle werden unterstützt.

  • Unterstützte Scalar-OIDs sind jnxCmCfgChgLatestIndex, jnxCmCfgChgLatestTime, jnxCmCfgChgLatestDate, jnxCmCfgChgLatestSource, jnxCmCfgChgLatestUser und jnxCmCfgChgMaxEventEntries.

  • Scalar-Variablen unter der jnxCmRescueChg-Tabelle werden nicht unterstützt.

MIB für Fabric Chassis (mib-jnx-Fabric-Chassis)

Stellt Hardwareinformationen zum QFabric-System und seinen Komponentengeräten bereit. Diese MIB basiert auf der unternehmensspezifischen Chassis-MIB von Juniper Networks, fügt jedoch eine weitere Ebene der Indizierung hinzu, die Informationen für QFabric-Systemkomponentengeräte bereitstellt.

SCHNITTSTELLEN-MIB (Erweiterungen) (mib-jnx-if-extensions)

Erweitert den Standard ifTable (RFC 2863) um zusätzliche Statistiken und unternehmensspezifische Chassis-Informationen von Juniper Networks in den Tabellen ifJnxTable und ifChassisTable.

HINWEIS:

Im QFabric-System werden Skalarvariablen nicht unterstützt.

Netzteil MIB (mib-jnx-Netzteil)

Bietet Unterstützung für die Umgebungsüberwachung des Netzteils für das Interconnect-Gerät des QFabric-Systems.

HINWEIS:

Im QFabric-System werden Scalar-Variablen für die jnxPsuObjects 1-Objekt-ID in der jnxPsuScalars-Tabelle nicht unterstützt.

QFabric-MIB (jnx-qf-smi)

Erläutert die Struktur der unternehmensspezifischen QFabric-MIBs von Juniper Networks. Definiert die MIB-Objekte, die vom QFabric-System gemeldet werden, und den Inhalt der Traps, die vom QFabric-System ausgegeben werden können.

MIB für Versorgungsunternehmen (mib-jnx-util)

Stellt Ihnen SNMP MIB-Containerobjekte der folgenden Typen bereit: 32-Bit-Zähler, 64-Bit-Zähler, signierte Ganzzahlen, unsignierte Ganzzahlen und Oktettzeichenfolgen. Sie können diese Objekte verwenden, um Daten zu speichern, die mit anderen SNMP-Vorgängen abgerufen werden können.

MIB-Objekte für die QFX-Serie

In diesem Thema werden die unternehmensspezifischen SNMP Chassis MIB-Definitionsobjekte von Juniper Networks für die QFX-Serie aufgelistet:

Eigenständige Switches der QFX-Serie

QFabric-Systeme

QFabric System QFX3100 Director Gerät

QFabric System QFX3008-I Interconnect Gerät

QFabric-System QFX3600-I Interconnect-Gerät

QFabric-Systemknotengeräte

Fabric Chassis-MIB

Die unternehmensspezifische SNMP Fabric Chassis MIB (mib-jnx-fabric-chassis) von Juniper Networks stellt Hardwareinformationen über das QFabric-System und seine Komponentengeräte in einer einzigen MIB bereit. Die Fabric Chassis-MIB basiert auf der unternehmensspezifischen Chassis-MIB von Juniper Networks, die Informationen für einzelne Geräte bereitstellt. Im Gegensatz zur Chassis-MIB stellt die Fabric Chassis-MIB die QFabric-Systemkomponentengeräte als Teil des QFabric-Systems dar. Nur die Informationen aus der Fabric Chassis-MIB (und nicht von einzelnen Chassis-MIBs) stehen SNMP-Management-Clients des QFabric-Systems zur Verfügung.

Die Fabric Chassis-MIB verwendet die grundlegende Informationsstruktur der Chassis-MIB, fügt jedoch eine weitere Ebene der Indizierung hinzu, die detaillierte Informationen zu QFabric-Systemgeräten bereitstellt. Jedes physische Gerät in einem QFabric-System (z. B. ein Node-Gerät oder ein Interconnect-Gerät) wird mit seinen Hardwarekomponenten dargestellt, einschließlich Netzteil, Lüftern und Vorder- und Rückseitenkarten.

Wie in anderen SNMP-Systemen befindet sich der SNMP-Manager im Netzwerkmanagementsystem (NMS) des Netzwerks, zu dem das QFabric-System gehört. Der SNMP-Agent (snmpd) befindet sich in der QFabric System Director-Software und ist für den Empfang und die Verteilung aller Traps sowie für die Beantwortung aller Abfragen vom SNMP-Manager verantwortlich. Darüber hinaus wird in der Routing-Engine jeder Node-Gruppe und jedem Interconnect-Gerät ein SNMP-Subagent ausgeführt. Der SNMP-Subagent verwaltet die Informationen über das Komponentengerät, und diese Informationen werden nach Bedarf an den SNMP-Agenten in der Director-Software übermittelt. Traps, die von einem Node-Gerät generiert werden, werden an den SNMP-Agenten in der Director-Software gesendet, der sie wiederum verarbeitet und an die in der SNMP-Konfiguration definierten Ziel-IP-Adressen sendet.

Tabelle 11 beschreibt die Tabellen und Objekte in der Fabric Chassis-MIB.

Tabelle 11: MIB-Tabellen und -Objekte für Fabric Chassis

Tabellen- oder Objektname

Root-OID

Beschreibung

Tabellen mit Gegenstücken in der Chassis-MIB

jnxFabricContainersTable

1.3.6.1.4.1.2636.3.42.2.2.2

Bietet Informationen über verschiedene Arten von Containern in QFabric-Systemgeräten.

  • Container für Interconnect-Geräte umfassen Lüftereinschübe, Netzteile, Steuertafeln und so weiter.

  • Container für Node-Geräte umfassen Lüftereinschübe, Netzteile, Flexible PIC Concentrator (FPC), PICs und so weiter.

  • Die Container für die Director-Geräte umfassen CPU, Speicher, Lüftereinschübe, Netzteile und Festplatten. Die Container haben eine nicht hierarchische oder flache Struktur, und die Komponenten in ihnen sind als geschwisterliche Komponenten zueinander organisiert.

jnxFabricContentsTable

1.3.6.1.4.1.2636.3.42.2.2.3

Enthält Inhalte, die auf allen Geräten vorhanden sind, die im jnxFabricDeviceTable-Objekt dargestellt werden. Diese Tabelle enthält alle vor Ort austauschbaren Einheiten (FRUs) und nicht-FRUs für QFabric-Systemgeräte.

  • Der Inhalt der Interconnect-Geräte umfasst Lüftereinschübe und Steuertafeln.

  • Der Inhalt der Node-Geräte umfasst Lüftereinschübe und Netzteile.

  • Zu den Inhalten der Director-Geräte gehören CPUs, Speicher, Lüftereinschübe, Netzteile und Festplatten, nicht jedoch Netzwerkschnittstellenkarten (NICs).

jnxFabricFilledTable

1.3.6.1.4.1.2636.3.42.2.2.4

Zeigt den Status von Containern in QFabric-Geräten an. Das jnxFabricFilledState-Objekt stellt den Zustand der Komponente dar: (1) unbekannt, (2) leer oder (3) gefüllt.

HINWEIS:

Das jnxFabricFilledTable-Objekt enthält keine Informationen zur Director-Gruppe.

jnxFabricOperatingTable

1.3.6.1.4.1.2636.3.42.2.2.5

Stellt verschiedene Betriebsparameter für den Inhalt dar, der im jnxFabricContentsTable-Objekt aufgefüllt wird.

  • Der Inhalt in jedem Node-Gerät und jedem Interconnect-Gerät umfasst Lüftereinschübe, Netzteile, FPC, PIC und Routing-Engine.

  • Der Inhalt des Director-Geräts umfasst CPUs, Speicher, Lüftereinschübe, Netzteile und Festplatten, nicht jedoch Netzwerkschnittstellenkarten (NICs).

Das jnxFabricOperatingState-Objekt stellt den Zustand des Geräts bereit: (1) unbekannt, (2) ausgeführt, (3) bereit, (4) zurücksetzen, (5) ausführenAtFullSpeed (nur für Lüfter), (6) herunter, (6) aus (für Netzteile) oder (7) Standby.

jnxFabricRedundancyTable

1.3.6.1.4.1.2636.3.42.2.2.6

Stellt die Redundanzinformationen dar, die auf verschiedenen Subsystemebenen im gesamten QFabric-System verfügbar sind. Informationen zu den Routing-Engines in Node-Geräten sind enthalten, aber es gibt keine entsprechenden Einträge für Interconnect-Geräte in dieser Tabelle. Das jnxFabricRedundancyState-Objekt gibt den Zustand des Subsystems an: (1) unbekannt, (2) primär, (3) Backup oder (4) deaktiviert.

HINWEIS:

Informationen über redundante Director-Geräte, virtuelle Maschinen (VMs) in Director-Gruppen und Virtual Chassis-Geräte sind derzeit nicht verfügbar.

jnxFabricFruTable

1.3.6.1.4.1.2636.3.42.2.2.7

Enthält alle FRUs für das QFabric-System in der jnxFabricDeviceTable-Tabelle. Die FRUs werden unabhängig davon aufgelistet, ob sie installiert oder online sind. Das jnxFabricFruState-Objekt stellt den Zustand der FRU dar, einschließlich online, offline oder leer usw. Diese Tabelle enthält auch Informationen zu jeder FRU, z. B. Name, Typ, Temperatur, Uhrzeit des letzten Einschaltens und Uhrzeit des letzten Einschaltens.

HINWEIS:

Die jnxFabricFruTable-Tabelle enthält keine Netzwerkschnittstellenkarten (NICs) auf Director-Geräten.

Tabelle spezifisch für die Fabric Chassis-MIB

jnxFabricDeviceTable

1.3.6.1.4.1.2636.3.42.2.2.1

Enthält Informationen zu allen Geräten im QFabric-System. Diese Tabelle organisiert Skalarvariablen, die in der Chassis-MIB dargestellt werden, in einem Tabellenformat für die QFabric-Systemkomponentengeräte. Die Spalten in dieser Tabelle enthalten Geräteinformationen wie Modell, Gerätealias und Seriennummer. Der jnxFabricDeviceIndex identifiziert jedes QFabric-Systemgerät (Node-Gerät, Interconnect-Gerät und Director-Gerät).

HINWEIS:

Derzeit sind keine Informationen zum Virtual Chassis verfügbar.

HINWEIS:

Die folgenden Objekte werden nicht unterstützt:

  • jnxFabricDeviceETryRevision

  • jnxFabricDeviceTryFirmwareVision

  • jnxFabricDeviceEntryKernelMemoryUsedPercent

Scalar-Variablen

Die folgenden Skalarvariablen werden unterstützt:

  • jnxFabricClass

  • jnxFabricDescr

  • jnxFabricSerialNo

  • jnxFabric-Vision

  • jnxFabricLastInstalled

  • jnxFabricContentsLastChange

  • jnxFabricFilledLastChange

1.3.6.1.4.1.2636.3.42.2.1

Beschreiben des QFabric-Systems als Ganzes.

HINWEIS:

Die Skalarvariable jnxFabricFirmwareRevision wird derzeit nicht unterstützt.

Tabelle 12 beschreibt die SNMPv2-Traps, die in der Fabric Chassis-MIB definiert sind.

HINWEIS:

Nur SNMPv2-Traps werden auf dem QFabric-System unterstützt.

Tabelle 12: MiB-SNMPv2-Traps für Fabric Chassis

Trap-Gruppe und Name

Root-OID

Beschreibung

jnxFabricChassisTraps-Gruppe – Enthält die folgenden Traps:

  • jnxFabricPowerSupplyFailure

  • jnxFabricFanFailure

  • jnxFabricOverTemperature

  • jnxFabricRedundancySwitchover

  • jnxFabricFruRemoval

  • jnxFabricFruInsertion

  • jnxFabricFruPowerOff

  • jnxFabricFruPowerOn

  • jnxFabricFruFailed

  • jnxFabricFruOffline

  • jnxFabricFruOnline

  • jnxFabricFruCheck

  • jnxFabricFEBSwitchover

  • jnxFabricHardDiskFailed

  • jnxFabricHardDiskMissing

  • jnxFabricBootFromBackup

  • jnxFabricHighPower

1.3.6.1.4.1.2636.4.19

Gibt eine Alarmbedingung an.

HINWEIS:

Hardwareereignisse in der Director-Gruppe werden durch scannen erkannt. Daher kann eine Trap erst bis zu 30 Sekunden nach dem Ereignis generiert werden.

HINWEIS:

Die Software unterscheidet nicht zwischen Lüfterentfernung und Lüfterausfällen in der Director-Gruppe. In jedem Fall werden sowohl jnxFabricFanFailure als auch jnxFabricFruFailed Traps generiert.

jnxFabricChassisOKTraps-Gruppe – Enthält die folgenden Traps:

  • jnxFabricPowerSupplyOK

  • jnxFabricFanOK

  • jnxFabricTemperatureOK

  • jnxFabricFruOK

  • jnxFabricHighPowerCleared

1.3.6.1.4.1.2636.4.20

Gibt einen Alarm an, der die Bedingung deaktiviert hat.

Weitere Informationen finden Sie in der MiB für Fabric Chassis unter:

https://www.juniper.net/documentation/en_US/junos13.1/topics/reference/mibs/mib-jnx-fabric-chassis.txt

Überwachung von RMON MIB-Tabellen

Zweck

Überwachen Sie Alarm-, Ereignis- und Protokolltabellen für Remote-Überwachung (RMON).

Aktion

So zeigen Sie die RMON-Tabellen an:

Bedeutung

Die Anzeige zeigt, dass ein Alarm zur Überwachung des jnxRmon MIB-Objekts jnxOperatingCPU definiert wurde, das die CPU-Auslastung der Routing-Engine darstellt. Der Alarm wird so konfiguriert, dass ein Ereignis generiert wird, das eine SNMP-Trap sendet, und fügt der logTable in der RMON-MIB einen Eintrag hinzu. Die Protokolltabelle zeigt, dass zwei Ereignisse des Ereignisses generiert wurden – eine für das Überschreiten einer Schwelle von 90 Prozent und eine für das Unterschreiten einer Schwelle von 75 Prozent.

Verwendung der unternehmensspezifischen MIB für versorgungsbezogene Anwendungen zur Verbesserung der SNMP-Abdeckung

Obwohl das Junos OS integrierte Leistungsmetriken und Überwachungsoptionen bietet, benötigen Sie möglicherweise benutzerdefinierte Leistungsmetriken. Um ihnen die Überwachung solcher benutzerdefinierter Daten durch ein Standardüberwachungssystem zu erleichtern, bietet Ihnen Junos OS eine unternehmensspezifische Utility-MIB, die solche Daten speichern und somit SNMP-Unterstützung für die Verwaltung und Überwachung der Daten Ihrer Wahl erweitern kann.

Die unternehmensspezifische MIB für Versorgungsunternehmen stellt Ihnen Containerobjekte der folgenden Typen zur Verfügung: 32-bit counters, 64-bit counters, signed integers, , unsigned integersund octet strings. Sie können diese Container-MIB-Objekte verwenden, um die Daten zu speichern, die ansonsten für SNMP-Vorgänge nicht unterstützt werden. Sie können Daten für diese Objekte entweder mithilfe von CLI-Befehlen oder mithilfe von Op-Skripten und einer RPC-API füllen, die die CLI-Befehle aufrufen kann.

Mit den folgenden CLI-Befehlen können Sie Die Werte der UTILITY-MIB-Objektwerte festlegen und löschen:

  • request snmp utility-mib set instance name object-type <counter | counter 64 | integer | string | unsigned integer> object-value value

  • request snmp utility-mib clear instance name object-type <counter | counter 64 | integer | string | unsigned integer>

Die instance name Option des request snmp utility-mib <set | clear> Befehls gibt den Namen der Dateninstanz an und ist der Hauptbezeichner der Daten. Mit object-type <counter | counter 64 | integer | string | unsigned integer> der Option können Sie den Objekttyp angeben, und mit der object-value value Option können Sie den Wert des Objekts festlegen.

Um den Prozess der Füllvorgangs-MIB-Daten zu den Dienstprogrammen zu automatisieren, können Sie eine Kombination aus Einer Ereignisrichtlinie und einem Ereignisskript verwenden. Die folgenden Beispiele zeigen die Konfiguration einer Ereignisrichtlinie, die stündlich ausgeführt wird show system buffers und die show system buffers Daten durch Ausführen eines Ereignisskripts in MIB-Objekten von Dienstprogrammen gespeichert wird (check-mbufs.slax).

Konfiguration von Ereignisrichtlinien

Um eine Ereignisrichtlinie zu konfigurieren, die den show system buffers Befehl stündlich ausführt und zum Speichern der Daten in MIB-Objekten des show system buffers Dienstprogramms check-mbufs.slax aufruft, fügen Sie die folgenden Anweisungen auf der Hierarchieebene [edit] ein:

check-mbufs.slax-Skript

Das folgende Beispiel zeigt das check-mbufs.slax Skript, das unter /var/db/scripts/event/:

Sie können den folgenden Befehl ausführen, um die in der MIB des Dienstprogramms gespeicherten Daten aufgrund der Ereignisrichtlinie und des Skripts in den vorhergehenden Beispielen zu überprüfen:

HINWEIS:

Der show snmp mib walk Befehl ist auf dem QFabric-System nicht verfügbar, sie können jedoch externe SNMP-Clientanwendungen verwenden, um diesen Vorgang auszuführen.

Beispiel: Konfigurieren von SNMP

Standardmäßig ist SNMP auf Geräten mit Junos OS deaktiviert. In diesem Beispiel werden die Schritte zur Konfiguration von SNMP im QFabric-System beschrieben.

Anforderungen

In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:

  • Junos OS Version 12.2

  • Netzwerkmanagementsystem (NMS) (ausführung des SNMP-Managers)

  • QFabric-System (unter Ausführung des SNMP-Agenten) mit mehreren Node-Geräten

Überblick

Da SNMP auf Geräten mit Junos OS standardmäßig deaktiviert ist, müssen Sie SNMP auf Ihrem Gerät aktivieren, indem Sie Konfigurationsanweisungen auf Hierarchieebene [edit snmp] hinzufügen. Sie müssen die community public Anweisung mindestens konfigurieren. Die Community, die als öffentlich definiert ist, gewährt jedem Kunden lesegeschützten Zugriff auf MIB-Daten.

Wenn keine clients Anweisung konfiguriert ist, sind alle Clients zulässig. Wir empfehlen, dass Sie immer die Option zur Einschränkung des restrict SNMP-Client-Zugriffs auf den Switch einschließen.

Topologie

Die Netzwerktopologie in diesem Beispiel umfasst ein NMS, ein QFabric-System mit vier Node-Geräten und externe SNMP-Server, die für den Empfang von Traps konfiguriert sind.

Konfiguration

Verfahren

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen sie in eine Textdatei ein, entfernen alle Zeilenumbrüche, ändern alle erforderlichen Details, um mit Ihrer Netzwerkkonfiguration zu übereinstimmen, und kopieren Sie dann die Befehle und fügen sie auf Hierarchieebene in die [edit] CLI ein.

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie auf verschiedenen Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im Junos OS CLI-Benutzerhandbuch .

So konfigurieren Sie SNMP auf dem QFabric-System:

HINWEIS:

Wenn der Name, die Beschreibung, der Standort, der Kontakt oder der Community-Name Leerzeichen enthält, schließen Sie den Text in Anführungszeichen ("").

  1. Konfigurieren Sie den SNMP-Systemnamen:

    HINWEIS:

    Der oben konfigurierte SNMP-Systemname kann abgerufen werden:

    • Führen Sie eine Abfrage mit SNMP Auf Policy Object Identifier (OID) sysName.0.

    • Aus dem generischen jnxSyslogTrap. Um jnxSyslogTrap zu senden, konfigurieren Sie die Trap-Ereignisse in der [edit event-options policy] Hierarchie.

  2. Geben Sie eine Beschreibung an.

    Diese Zeichenfolge wird in das MIB II sysDescription-Objekt platziert.

  3. Geben Sie den physischen Speicherort des QFabric-Systems an.

    Diese Zeichenfolge wird in das MIB II sysLocation-Objekt platziert.

  4. Geben Sie einen administrativen Kontakt für das SNMP-System an.

    Dieser Name wird in das MIB II sysContact-Objekt platziert.

  5. Geben Sie einen eindeutigen SNMP-Community-Namen und die schreibgeschützte Autorisierungsebene an.

    HINWEIS:

    Die read-write Option wird vom QFabric-System nicht unterstützt.

  6. Erstellen Sie eine Client-Liste mit einer Reihe von IP-Adressen, die die SNMP-Community verwenden können.

  7. Geben Sie DIE IP-Adressen von Clients an, die für die Nutzung der Community eingeschränkt sind.

  8. Konfigurieren Sie eine Trap-Gruppe, einen Ziel-Port und ein Ziel, um die SNMP-Traps in der Trap-Gruppe zu empfangen.

    HINWEIS:

    Wenn Sie den destination-port Standardport 162 verwenden, müssen Sie die Anweisung nicht einschließen.

    Die Trap-Gruppe qf-traps ist so konfiguriert, dass Traps an 192.168.0.100 gesendet werden.

Ergebnisse

Bestätigen Sie ihre Konfiguration im Konfigurationsmodus, indem Sie den show Befehl eingeben. Wenn die gewünschte Konfiguration in der Ausgabe nicht angezeigt wird, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, geben Sie im Konfigurationsmodus ein commit .

Konfigurieren von RMON-Alarmen und -Ereignissen

Das Junos OS unterstützt die Remote Network Monitoring (RMON) MIB (RFC 2819), mit der ein Verwaltungsgerät die Werte von MIB-Objekten oder -Variablen auf konfigurierte Schwellenwerte überwachen kann. Wenn der Wert einer Variablen einen Schwellenwert überschreitet, werden ein Alarm und das entsprechende Ereignis generiert. Das Ereignis kann protokolliert werden und eine SNMP-Trap generieren.

Führen Sie die folgenden Aufgaben aus, um RMON-Alarme und -Ereignisse mithilfe der CLI zu konfigurieren:

Konfigurieren von SNMP

So konfigurieren Sie SNMP:

  1. Gewähren Sie schreibgeschützten Zugriff auf alle SNMP-Clients:

    Zum Beispiel:

  2. Gewähren Sie Schreibzugriff auf die RMON- und jnx-rmon-MIBs:

    Zum Beispiel:

    OIDs 1.3.6.1.2.1.16 und 1.3.6.1.4.1.2636.13 entsprechen den RMON- und jnxRmon-MIBs.

  3. Konfigurieren einer SNMP-Trap-Gruppe:

    Zum Beispiel:

    Die Trap-Gruppe rmon-trap-group ist so konfiguriert, dass sie RMON-Traps an 192.168.5.5 sendet.

Konfigurieren eines Ereignisses

So konfigurieren Sie ein Ereignis:

  1. Konfigurieren Sie einen Ereignisindex, einen Community-Namen und einen Typ:

    Zum Beispiel:

    Die Ereignis-Community entspricht der SNMP-Trap-Gruppe und ist nicht gleich einer SNMP-Community. Dieses Ereignis generiert eine SNMP-Trap und fügt der logTable in der RMON-MIB einen Eintrag hinzu.

  2. Konfigurieren Sie eine Beschreibung für das Ereignis:

    Zum Beispiel:

Konfigurieren eines Alarms

So konfigurieren Sie einen Alarm:

  1. Konfigurieren Sie einen Alarmindex, die zu überwachende Variable, die steigenden und fallenden Schwellenwerte und die entsprechenden steigenden und fallenden Ereignisse:

    Zum Beispiel:

    Die Variable .1.3.6.1.4.1.2636.3.1.13.1.8.9.1.0.0 entspricht dem jnxRmon MIB-Objekt jnxOperatingCPU, das die CPU-Auslastung der Routing-Engine darstellt. Die sinkenden und steigenden Integer-Schwellenwerte sind 75 und 90. Die steigenden und fallenden Ereignisse generieren beide dasselbe Ereignis (Ereignisindex 1).

  2. Konfigurieren Sie das Stichprobenintervall und -typ sowie den Alarmtyp:

    Zum Beispiel:

    Der absolute Wert der überwachten Variablen wird alle 30 Sekunden gemessen. Der anfängliche Alarm kann auftreten, weil der steigende Schwellenwert übersteigt oder unter die fallende Schwelle fällt.