Konfigurieren von SNMP für Routing-Instanzen

Junos OS ermöglicht es SNMP-Managern für alle Routing-Instanzen, SNMP-Daten im Zusammenhang mit den entsprechenden Routing-Instanzen und logischen Systemnetzwerken anzufordern und zu verwalten.

In Junos OS:

• Clients von Routinginstanzen und/oder logischen Systemen, die nicht der Standardeinstellung entsprechen, können auf MIB-Objekte zugreifen und SNMP-Operationen nur in den Routinginstanzen und/oder logischen Systemnetzwerken ausführen, zu denen sie gehören.

• Clients aus der Standard-Routinginstanz können auf Informationen zugreifen, die sich auf alle Routinginstanzen und logischen Systemnetzwerke beziehen.

• Die Junos Management Routing-Instanz () ist eine spezielle Instanz.mgmt_junos Clients aus der Management-Routinginstanz werden so behandelt, als ob sie sich in der Standard-Routinginstanz befänden, und können auf Informationen zugreifen, die sich auf alle Routinginstanzen und logischen Systemnetzwerke beziehen.

Vor Version 8.4 von Junos OS hatte nur der SNMP-Manager in der Standardroutinginstanz (inet.0) Zugriff auf die MIB-Objekte.

Mit der Zunahme von VPN-Serviceangeboten (Virtual Private Network) ist diese Funktion insbesondere für Service Provider nützlich, die SNMP-Daten für bestimmte Routing-Instanzen abrufen müssen (siehe ).Abbildung 1 Service Provider können diese Informationen für ihre eigenen Verwaltungszwecke verwenden oder die Daten für die Verwendung durch ihre Kunden exportieren.

Abbildung 1: SNMP-Daten für Routing-Instanzen

Wenn in der Anforderung keine Routing-Instanz angegeben ist, arbeitet der SNMP-Agent wie bisher:

• Bei Nicht-Routing-Tabellenobjekten werden alle Instanzen verfügbar gemacht.

• Bei Routing-Tabellenobjekten werden nur die Objekte verfügbar gemacht, die der Standard-Routinginstanz zugeordnet sind.

  HINWEIS:

  Die tatsächlichen Protokolldateneinheiten (PDUs) werden weiterhin über die Standard-Routinginstanz (inet.0) ausgetauscht, aber der zurückgegebene Dateninhalt wird durch die Routing-Instanz bestimmt, die in den Anforderungs-PDUs angegeben ist.

Ab Junos OS 19.4R1 können Sie auf Informationen zugreifen, die sich auf alle Routing-Instanzen und logischen Systemnetzwerke beziehen und nicht spezifisch für eingehende Routing-Instanzen sind, indem Sie die SNMPv3-Verwaltungsschnittstelle in einer erforderlichen Routing-Instanz konfigurieren. Sie können die Konfigurationsanweisung für Verwaltungsinstanzen auf Hierarchieebene konfigurieren.[edit snmp v3]

• Vorteile
• Aktivieren der Management-Routinginstanz
• Entfernen der Management-Routinginstanz

Tabelle 1 zeigt unternehmensspezifische MIB-Objekte, die von Junos OS unterstützt werden, und enthält Hinweise, die detailliert beschreiben, wie sie behandelt werden, wenn eine Routing-Instanz in einer SNMP-Anforderung angegeben wird. Ein Gedankenstrich (–) gibt an, dass das Element nicht anwendbar ist.

Tabelle 2 zeigt MIB-Objekte der Klasse 1 (Standard- und unternehmensspezifische MIBs), die von Junos OS unterstützt werden. Bei Objekten der Klasse 1 werden nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen) verfügbar gemacht, die zu einer bestimmten Routinginstanz gehören.

Tabelle 3 zeigt MIB-Objekte der Klasse 2 (Standard- und unternehmensspezifische MIBs), die von Junos OS unterstützt werden. Bei Objekten der Klasse 2 werden alle Instanzen innerhalb eines logischen Systems verfügbar gemacht. Die Daten werden nicht bis auf die Ebene der Routinginstanz getrennt.

Tabelle 4 zeigt MIB-Objekte der Klasse 3 (Standard- und unternehmensspezifische MIBs), die von Junos OS unterstützt werden. Bei Klasse 3 werden Objekte nur für das logische Standardsystem verfügbar gemacht.

Tabelle 5 zeigt MIB-Objekte der Klasse 4 (Standard- und unternehmensspezifische MIBs), die von Junos OS unterstützt werden. Bei Objekten der Klasse 4 werden die Daten nicht nach Routing-Instanz getrennt. Alle Instanzen werden verfügbar gemacht.

Wenn eine Routing-Instanz angegeben wird, geben alle routingbezogenen MIB-Objekte Daten zurück, die von der Routing-Instanz in der Anforderung verwaltet werden. Bei allen anderen MIB-Objekten werden die zurückgegebenen Daten entsprechend dieser Routinginstanz getrennt. Beispielsweise werden nur die Schnittstellen, die dieser Routinginstanz zugewiesen sind (z. B. die logischen Schnittstellen [ifls] sowie die entsprechenden physischen Schnittstellen [ifds]), vom SNMP-Agenten verfügbar gemacht. In ähnlicher Weise werden auch Objekte mit einer eindeutigen Verbindung zu einer Schnittstelle (z. B. Adressen) getrennt.

Für Objekte, bei denen der Anhang mehrdeutig ist (z. B. Objekte in sysApplMIB), wird keine Trennung vorgenommen, und alle Instanzen sind in allen Fällen sichtbar.

Eine andere Kategorie von Objekten ist nur sichtbar, wenn kein logisches System angegeben ist (nur innerhalb des logischen Standardsystems), unabhängig von der Routinginstanz innerhalb des logischen Standardsystems. Objekte in dieser Kategorie sind Chassis-MIB-Objekte, Objekte in der SNMP-Gruppe, RMON-Alarm-, Ereignis- und Protokollgruppen, Ping-MIB-Objekte, Konfigurationsmanagementobjekte und V3-Objekte.

Zusammenfassend lässt sich sagen, dass MIB-Objekte zur Unterstützung von Routinginstanzen in eine der folgenden Kategorien fallen:

• Klasse 1 - Die Daten werden entsprechend der Routing-Instanz in der Anforderung getrennt. Dies ist die granularste der Segregationsklassen.

• Klasse 2 – Die Daten werden entsprechend dem in der Anforderung angegebenen logischen System getrennt. Für alle Routinginstanzen, die zu einem bestimmten logischen System gehören, werden dieselben Daten zurückgegeben. In der Regel gilt dies für Routing-Tabellenobjekte, bei denen es schwierig ist, Routing-Instanzinformationen zu extrahieren, oder bei denen Routing-Instanzen nicht zutreffen.

• Klasse 3 – Daten werden nur für das logische Standardsystem verfügbar gemacht. Für alle Routinginstanzen, die zum logischen Standardsystem gehören, wird derselbe Datensatz zurückgegeben. Wenn Sie ein anderes logisches System angeben (nicht das Standardsystem), werden keine Daten zurückgegeben. In der Regel gilt diese Klasse für Objekte, die in Subagenten implementiert sind, die logische Systemänderungen nicht überwachen und ihre Objekte nur mit dem Standardkontext registrieren (z. B. Chassis-MIB-Objekte).

• Klasse 4 – Die Daten werden nicht nach Routing-Instanzen getrennt. Für alle Routing-Instanzen werden dieselben Daten zurückgegeben. Dies gilt in der Regel für Objekte, die in Subagenten implementiert sind, die logische Systemänderungen überwachen und alle ihre Objekte für jede logische Systemänderung registrieren oder die Registrierung aufheben. Objekte, deren Werte nicht nach Routinginstanz getrennt werden können, fallen in diese Klasse.

Eine Liste der Objekte, die den einzelnen Klassen zugeordnet sind, finden Sie unter Für Routing-Instanzen unterstützte SNMP-MIBs .

Sie können die Trap-Empfänger daran hindern, Traps zu empfangen, die nicht mit den logischen Systemnetzwerken in Verbindung stehen, zu denen sie gehören. Fügen Sie dazu die Anweisung auf Hierarchieebene ein:logical-system-trap-filter[edit snmp]

Wenn die Anweisung nicht in der SNMP-Konfiguration enthalten ist, werden alle Traps an die konfigurierten Routing-Instanzziele weitergeleitet.logical-system-trap-filter Aber auch wenn diese Anweisung konfiguriert ist, empfängt der Trap-Empfänger, der der Standard-Routinginstanz zugeordnet ist, alle SNMP-Traps.

Bei der Konfiguration unter dem trap-group-Objekt ist bei allen v1- und v2c-Traps, die für Routinginstanzen (oder Schnittstellen, die zu einer Routinginstanz gehören) gelten, der Name der Routinginstanz in der Communityzeichenfolge codiert. Die Codierung ist identisch mit der in Anforderungs-PDUs verwendeten.

Bei Traps, die unter dem v3-Framework konfiguriert wurden, wird der Name der Routing-Instanz im context-Feld übernommen, wenn das v3-Nachrichtenverarbeitungsmodell konfiguriert wurde. Bei anderen Nachrichtenverarbeitungsmodellen (v1 oder v2c) wird der Name der Routinginstanz nicht im Header der Trap-Nachricht enthalten (und nicht in der Community-Zeichenfolge codiert).

Mit dieser Funktion werden Routing-Instanzen entweder durch das Kontextfeld in v3-Anforderungen identifiziert oder in v1- oder v2c-Anforderungen in der Community-Zeichenfolge codiert.

Bei der Codierung in einer Communityzeichenfolge wird der Name der Routinginstanz zuerst angezeigt und durch das Zeichen von der eigentlichen Communityzeichenfolge getrennt.@

Um Konflikte mit gültigen Community-Zeichenfolgen zu vermeiden, die das Zeichen enthalten, wird die Community nur analysiert, wenn bei der typischen Verarbeitung von Community-Zeichenfolgen ein Fehler auftritt.@ Wenn beispielsweise eine Routing-Instanz mit dem Namen konfiguriert ist, wird eine SNMP-Anforderung mit im Kontext der Routing-Instanz verarbeitet.RIRI@publicRI Die Zugriffssteuerung (Ansichten, Quelladressbeschränkungen, Zugriffsrechte usw.) wird entsprechend der tatsächlichen Community-Zeichenfolge (in diesem Fall der Datensatz nach dem Zeichen) angewendet.@public Wenn die Community-Zeichenfolge jedoch konfiguriert ist, wird die PDU (Protocol Data Unit) entsprechend dieser Community verarbeitet, und der Name der eingebetteten Routinginstanz wird ignoriert.RI@public

Logische Systeme führen eine Teilmenge der Aktionen eines physischen Routers aus und verfügen über eigene Routing-Tabellen, Schnittstellen, Richtlinien und Routing-Instanzen. Wenn eine Routinginstanz in einem logischen System definiert ist, muss der Name des logischen Systems zusammen mit der Routinginstanz mit einem Schrägstrich ( ) codiert werden, um die beiden zu trennen./ Wenn die Routinginstanz z. B. innerhalb des logischen Systems konfiguriert ist, muss diese Routinginstanz in einer Communityzeichenfolge als codiert werden.RILSLS/RI@public Wenn eine Routinginstanz außerhalb eines logischen Systems (innerhalb des logischen Standardsystems) konfiguriert wird, ist kein logischer Systemname (oder kein Zeichen) erforderlich./

Wenn ein logisches System erstellt wird, wird außerdem immer eine Standard-Routinginstanz (mit dem Namen ) innerhalb des logischen Systems erstellt.default Dieser Name sollte beim Abfragen von Daten für diese Routinginstanz verwendet werden (z. B. ).LS/default@public Bei v3-Anforderungen sollte der Name direkt im Kontextfeld angegeben werden.logical system/routing instance

Dieses Beispiel zeigt eine 802.3ad ae0-Schnittstellenkonfiguration, die einer Routinginstanz mit dem Namen INFrtd zugewiesen ist:

Der folgende Befehl zeigt, wie Sie SNMP-bezogene Informationen von router1 und der 802.3ae-Bundle-Schnittstelle abrufen, die zur Routing-Instanz INFrtd mit der SNMP-Community gehört:snmpwalkpublic