Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Konfigurieren von SNMP für Routing-Instanzen

Verstehen der SNMP-Unterstützung für Routing-Instanzen

Mit Junos OS können SNMP-Manager für alle Routing-Instanzen SNMP-Daten in Bezug auf die entsprechenden Routing-Instanzen und logischen Systemnetzwerke anfordern und verwalten.

In Junos OS:

  • Clients von Routinginstanzen und/oder logischen Systemen, die nicht standardgemäß sind, können auf MIB-Objekte zugreifen und SNMP-Vorgänge nur in der Routinginstanz und/oder in logischen Systemnetzwerken ausführen, zu denen sie gehören.

  • Clients der Standardroutinginstanz können auf Informationen zugreifen, die mit allen Routinginstanzen und logischen Systemnetzwerken zusammenhängen.

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

Vor Junos OS Version 8.4 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 besonders 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 Verwaltungsanforderungen verwenden oder die Daten für die Verwendung durch ihre Kunden exportieren.

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

Wenn in der Anforderung keine Routinginstanz angegeben ist, funktioniert der SNMP-Agent wie zuvor:

  • Für tabellenfreie Objekte werden alle Instanzen offengelegt.

  • Für Routing-Tabellenobjekte werden nur die mit der Standardroutinginstanz verknüpften Objekte offengelegt.

    Anmerkung:

    Die tatsächlichen Protokolldateneinheiten (PDUs) werden weiterhin über die Standard-Routinginstanz (inet.0) ausgetauscht, der zurückgegebene Dateninhalt wird jedoch von der in den Anforderungs-PDUs angegebenen Routing-Instanz vorgegeben.

SNMPv3 Management Routing-Instanz

Ausgehend von Junos OS 19.4R1 können Sie auf Informationen zugreifen, die sich auf alle Routinginstanzen und logischen Systemnetzwerke beziehen und nicht spezifisch für die Ingress-Routinginstanz sind, indem Sie die SNMPv3-Verwaltungsschnittstelle in einer erforderlichen Routinginstanz konfigurieren. Sie können die Konfigurationsanweisung für managementinstanzen auf Hierarchieebene [edit SNMP v3] konfigurieren.

Sie können die Junos Management Routing-Instanz (mgmt_junos) nicht über die Management-Routinginstanz SNMPv3 konfigurieren.

Vorteile

Die Management-Routing-Instanz SNMPv3 ermöglicht alle SNMPv3-Anfragen von einer nicht standardmäßigen Routinginstanz, als ob die Anforderungen von der Standardroutinginstanz wären. Mit der SNMPv3 Management Routing-Instanz greifen Sie auf die Informationen zu allen Routing-Instanzen und logischen Systemnetzwerken zu.

Aktivieren der Management-Routing-Instanz

So aktivieren Sie die SNMPv3-Managementrouting-Instanz:

  1. Konfigurieren Sie die Anweisung für Managementinstanzen.

  2. Konfiguration bestätigen.

Entfernen der Management-Routing-Instanz

So entfernen Sie die Management-Routing-Instanz SNMPv3:

  1. Löschen oder deaktivieren Sie die Aussage der SNMPv3 Management Routing Instanz.

UNTERSTÜTZT SNMP-MIBs für Routing-Instanzen

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

Tabelle 1: MIB-Unterstützung für Routing-Instanzen (MIBs von Juniper Networks)

Objekt

Support-Klasse

Beschreibung/Hinweise

jnxProdukte(1)

Produktobjekt-IDs

jnxServices(2)

Services

jnxMibs(3)

jnxBoxAnatomie(1)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

mpls(2)

Klasse 2

Alle Instanzen innerhalb eines logischen Systems werden offengelegt. Die Daten werden nicht nach der Routinginstanzebene getrennt.

ifJnx(3)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxAlarms(4)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxFirewalls(5)

Klasse 4

Die Daten werden nicht nach Routinginstanz getrennt. Alle Instanzen werden offengelegt.

jnxDCUs(6)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxPingMIB(7)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxTraceRouteMIB(8)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxATM(10)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxIpv6(11)

Klasse 4

Die Daten werden nicht nach Routinginstanz getrennt. Alle Instanzen werden offengelegt.

jnxIpv4(12)

Klasse 1

jnxIpv4AddrTable(1). Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxRmon(13)

Klasse 3

jnxRmonAlarmTable(1). Objekte werden nur für das logische Standardsystem offengelegt.

jnxLdp(14)

Klasse 2

jnxLdpTrapVars(1). Alle Instanzen innerhalb eines logischen Systems werden offengelegt. Die Daten werden nicht nach der Routinginstanzebene getrennt.

jnxCos(15)

jnxCosIfqStatsTable(1) jnxCosFcTable(2) jnxCosFcIdTable(3) jnxCosQstatTable(4)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxScu(16)

jnxScuStatsTable(1)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxRpf(17)

jnxRpfStatsTable(1)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxCfgMgmt(18)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxPMon(19)

jnxPMonFlowTable(1)

jnxPMonErrorTable(2)

jnxPMonMemoryTable(3)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxSonet(20)

jnxSonetAlarmTable(1)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxAtmCos(21)

jnxCosAtmVcTable(1)

jnxCosAtmScTable(2)

jnxCosAtmVcQstatsTable(3)

jnxCosAtmTrunkTable(4)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

ipSecFlowMonitorMIB(22)

jnxMac(23)

jnxMacStats(1)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

apsMIB(24)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxChassisDefines(25)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

jnxVpnMIB(26)

Klasse 2

Alle Instanzen innerhalb eines logischen Systems werden offengelegt. Die Daten werden nicht nach der Routinginstanzebene getrennt.

jnxSericesInfoMib(27)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxCollectorMIB(28)

Klasse 1

Nur die logischen Schnittstellen (und ihre übergeordneten physischen Schnittstellen), die zu einer bestimmten Routinginstanz gehören, werden offengelegt.

jnxHistorie(29)

jnxSpMIB(32)

Klasse 3

Objekte werden nur für das logische Standardsystem offengelegt.

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

Tabelle 2: MIB-Objekte der Klasse 1 (Standard- und Juniper MIBs)

Klasse

MIB

Objekte

Klasse 1

802.3ad.mib

(dot3adAgg) MIB-Objekte:

dot3adAggTable

dot3adAggPortListTable

(dot3adAggPort)

dot3adAggPortTable

dot3adAggPortStatsTable

dot3adAggPortDebugTable

rfc2863a.mib

ifTable

ifXTable

ifStackTable

rfc2011a.mib

ipAddrTable

ipNetToMediatable

rtmib.mib

ipForward (ipCidrRouteTable)

rfc2665a.mib

dot3StatsTable

dot3ControlTable

dot3PauseTable

rfc2495a.mib

dsx1ConfigTable

dsx1CurrentTable

dsx1IntervalTable

dsx1TotalTable

dsx1FarEndCurrentTable

dsx1FarEndIntervalTable

dsx1FarEndTotalTable

dsx1FracTable ...

rfc2496a.mib

dsx3 (dsx3ConfigTable)

rfc2115a.mib

frDlcmiTable (und verwandte MIB-Objekte)

rfc3592.mib

sonetMediumTable (und verwandte MIB-Objekte)

rfc3020.mib

mfrMIB

mfrBundleTable

mfrMibBundleLinkObjects

mfrBundleIfIndexMappingTable

(und verwandte MIB-Objekte)

ospf2mib.mib

Alle Objekte

ospf2trap.mib

Alle Objekte

bgpmib.mib

Alle Objekte

rfc2819a.mib

Beispiel: etherStatsTable

Klasse 1

rfc2863a.mib

Beispiele:

ifXtable

ifStackTable

rfc2665a.mib

etherMIB

rfc2515a.mib

atmMIB-Objekte

Beispiele:

atmInterfaceConfTable

atmVplTable

atmVclTable

rfc2465.mib

ip-v6mib

Beispiele:

ipv6IfTable

ipv6AddrPrefixTable

ipv6NetToMediaTable

ipv6RouteTable

rfc2787a.mib

VRRP MIB

rfc2932.mib

ipMRouteMIB

ipMRouteStdMIB

mroutemib.mib

ipMRoute1MIBObjects

isismib.mib

isisMIB

pimmib.mib

pimMIB

msdpmib.mib

MSDPMIB

jnx-if-extensions.mib

Beispiele:

ifJnxTable

ifChassisTable

jnx-dcu.mib

jnxDCUs

jnx-atm.mib

Beispiele:

jnxAtmIfTable

jnxAtmVCTable

jnxAtmVpTable

jnx-ipv4.mib

jnxipv4

Beispiel: jnxIpv4AddrTable

jnx-cos.mib

Beispiele:

jnxCosIfqStatsTable

jnxCosQstatTable

jnx-scu.mib

Beispiel: jnxScuStatsTable

jnx-rpf.mib

Beispiel: jnxRpfStatsTable

jnx-pmon.mib

Beispiel: jnxPMonFlowTable

jnx-sonet.mib

Beispiel: jnxSonetAlarmTable

Klasse 1

jnx-atm-cos.mib

Beispiele:

jnxCosAtmVcTable

jnxCosAtmVcScTable

jnxCosAtmVcQstatsTable

jnxCosAtmTrunkTable

jnx-mac.mib

Beispiel: jnxMacStatsTable

jnx-services.mib

Beispiel: jnxSvcFlowTableAggStatsTable

jnx-coll.mib

jnxCollectorMIB

Beispiele:

jnxCollPicIfTable

jnxCollFileEntry

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 offengelegt. Die Daten werden nicht nach der Routinginstanzebene getrennt.

Tabelle 3: MIB-Objekte der Klasse 2 (Standard- und Juniper MIBs)

Klasse

MIB

Objekte

Klasse 2

rfc3813.mib

mplsrStdMIB

Beispiele:

mplsInterfaceTable

mplsInSegmentTable

mplsOutSegmentTable

mplsLabelStackTable

mplsXCTable

(und verwandte MIB-Objekte)

igmpmib.mib

igmpStdMIB

Anmerkung:

Es igmpmib.mib handelt sich um den Entwurf der IGMP Standard MIB im Versuchsbaum. Junos OS unterstützt die ursprüngliche IGMP-Standard-MIB nicht.

l3vpnmib.mib

mplsVpnmib

jnx-mpls.mib

Beispiel: mplsLspList

jnx-ldp.mib

jnxLdp

Beispiel: jnxLdpStatsTable

jnx-vpn.mib

jnxVpnMIB

jnx-bgpmib2.mib

jnxBgpM2Experiment

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 offengelegt.

Tabelle 4: MIB-Objekte der Klasse 3 (Standard- und Juniper MIBs)

Klasse

MIB

Objekte

Klasse 3

rfc2819a.mib

rmonVeranstaltungen

Alarmtabelle

logTable

Ereignistabelle

AgentxMIB

rfc2925a.mib

Pingmib

rfc2925b.mib

TracerouteMIB

jnxchassis.mib

jnxBoxAnatomie

jnx-chassis-alarm.mib

jnxAlarms

Standardmäßig abfragen Geräte der SRX-Serie jnxAlarms mib nur am primären Knoten der Redundanzgruppe 0 (RG0) und nicht am sekundären Knoten.

jnx-ping.mib

jnxPingMIB

jnx-traceroute.mib

jnxTraceRouteMIB

jnx-rmon.mib

jnxRmonAlarmTable

jnx-cos.mib

Beispiel: jnxCosFcTable

jnx-cfgmgmt.mib

Beispiel: jnxCfgMgmt

jnx-sonetaps.mib

apsMIBObjects

jnx-sp.mib

jnxSpMIB

ggsn.mib

ejnmobileipABmib

rfc1907.mib

snmpModule

snmpModule

Beispiele:

snmpMIB snmpFrameworkMIB

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 Routinginstanz getrennt. Alle Instanzen werden offengelegt.

Tabelle 5: MIB-Objekte der Klasse 4 (Standard- und Juniper-MIBs)

Klasse

MIB

Objekte

Klasse 4

System

Beispiel: sysORTable

rfc2011a.mib

IP (ipDefaultTTL, ipInReceives)

Icmp

rfc2012a.mib

Tcp

tcpConnTable

ipv6TcpConnTable

rfc2013a.mib

Udp

UDP-Table

ipv6UdpTable

rfc2790a.mib

hrSystem

rfc2287a.mib

sysApplOBJ

jnx-firewall.mib

JNXFirewalls

jnx-ipv6.mib

jnxIpv6

Supportklassen für MIB-Objekte

Wenn eine Routing-Instanz angegeben wird, geben alle Routing-bezogenen MIB-Objekte Daten zurück, die von der Routing-Instanz in der Anfrage verwaltet werden. Bei allen anderen MIB-Objekten werden die zurückgegebenen Daten nach dieser Routinginstanz getrennt. Beispielsweise werden nur die Schnittstellen, die dieser Routinginstanz zugewiesen sind (z. B. die logischen Schnittstellen [ifls] und deren entsprechende physische Schnittstellen [ifds]), vom SNMP-Agent offengelegt. In ähnlicher Weise werden auch Objekte mit eindeutiger Anbindung an eine Schnittstelle (z. B. Adressen) getrennt.

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

Eine andere Objektkategorie 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, Konfigurationsverwaltungsobjekte und V3-Objekte.

Zusammengefasst fallen MIB-Objekte zur Unterstützung von Routing-Instanzen in eine der folgenden Kategorien:

  • Klasse 1: Die Daten werden nach der Routinginstanz in der Anfrage getrennt. Dies ist die granularste der Trennungsklassen.

  • Klasse 2: Die Daten werden nach dem in der Anfrage angegebenen logischen System getrennt. Dieselben Daten werden für alle Routing-Instanzen zurückgegeben, die zu einem bestimmten logischen System gehören. Dies gilt in der Regel für Routing-Tabellenobjekte, bei denen es schwierig ist, Routinginstanzinformationen zu extrahieren oder wenn Routinginstanzen nicht zutreffen.

  • Klasse 3: Daten werden nur für das logische Standardsystem offengelegt. Für alle Routing-Instanzen, die zum logischen Standardsystem gehören, wird derselbe Datensatz zurückgegeben. Wenn Sie ein anderes logisches System angeben (nicht den Standard), werden keine Daten zurückgegeben. Normalerweise gilt diese Klasse für Objekte, die in Subagenten implementiert sind, die logische Systemänderungen nicht überwachen und ihre Objekte nur über den Standardkontext registrieren (z. B. Chassis-MIB-Objekte).

  • Klasse 4: Die Daten werden nicht nach Routinginstanz getrennt. Für alle Routing-Instanzen werden dieselben Daten zurückgegeben. In der Regel gilt dies für Objekte, die in Subagenten implementiert sind, die Änderungen des logischen Systems überwachen und alle ihre Objekte für jede Änderung des logischen Systems registrieren oder deaktivieren. Objekte, deren Werte nicht durch eine Routinginstanz getrennt werden können, fallen in diese Klasse.

Eine Liste der mit jeder Klasse verknüpften Objekte finden Sie unter SNMP MIBs Supported for Routing Instances .

Unterstützte SNMP-Traps für Routing-Instanzen

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

Wenn die logical-system-trap-filter Anweisung nicht in der SNMP-Konfiguration enthalten ist, werden alle Traps an die konfigurierten Routinginstanzziele weitergeleitet. Selbst wenn diese Anweisung konfiguriert ist, empfängt der der Standardroutinginstanz zugeordnete Trap-Empfänger jedoch alle SNMP-Traps.

Bei der Konfiguration unter dem Trap-Gruppenobjekt haben alle v1- und v2c-Traps, die für Routing-Instanzen (oder Schnittstellen einer Routing-Instanz) gelten, den Namen der Routing-Instanz in der Community-Zeichenfolge codiert. Die Codierung ist identisch mit der in Anfrage-PDUs verwendeten.

Bei Traps, die im v3-Framework konfiguriert sind, wird der Name der Routing-Instanz im Kontextfeld übertragen, wenn das v3-Nachrichtenverarbeitungsmodell konfiguriert wurde. Bei anderen Modellen zur Nachrichtenverarbeitung (v1 oder v2c) wird der Name der Routing-Instanz nicht im Header der Trap-Nachricht übertragen (und nicht in der Community-Zeichenfolge codiert).

Identifizieren einer Routing-Instanz

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

Wenn der Name der Routinginstanz in einer Community-Zeichenfolge codiert wird, wird er zuerst angezeigt und durch das @ Zeichen von der tatsächlichen Community-Zeichenfolge getrennt.

Um Konflikte mit gültigen Community-Zeichenfolgen zu vermeiden, die das @ Zeichen enthalten, wird die Community nur analysiert, wenn eine typische Community-Zeichenfolgenverarbeitung ausfällt. Wenn beispielsweise eine Routinginstanz mit dem Namen RI konfiguriert ist, wird eine SNMP-Anfrage mit RI@public im Kontext der RI Routinginstanz verarbeitet. Die Zugriffssteuerung (Ansichten, Beschränkungen der Quelladresse, Zugriffsrechte usw.) wird entsprechend der tatsächlichen Community-Zeichenfolge (dem Datensatz nach dem Zeichen – in diesem @ Fall public) angewendet. Wenn die Community-Zeichenfolge RI@public jedoch konfiguriert ist, wird die Protokolldateneinheit (Protocol Data Unit, PDU) entsprechend dieser Community verarbeitet und der Name der eingebetteten Routing-Instanz ignoriert.

Logische Systeme führen eine Teilmenge der Aktionen eines physischen Routers aus und verfügen über eigene, eindeutige 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 codiert werden, indem ein Slash ( / ) verwendet wird, um die beiden zu trennen. Wenn die Routing-Instanz RI beispielsweise innerhalb des logischen Systems LSkonfiguriert ist, muss diese Routinginstanz innerhalb einer Community-Zeichenfolge als LS/RI@publiccodiert werden. Wenn eine Routinginstanz außerhalb eines logischen Systems (innerhalb des logischen Standardsystems) konfiguriert wird, ist kein logischer Systemname (oder / Zeichen) erforderlich.

Wenn ein logisches System erstellt wird, wird immer eine Standardroutinginstanz (benannt default) innerhalb des logischen Systems erstellt. Dieser Name sollte bei der Abfrage von Daten für diese Routing-Instanz verwendet werden (z. B LS/default@public. ). Bei v3-Anfragen sollte der Name der logischen System-/Routinginstanz direkt im Kontextfeld identifiziert werden.

Anmerkung:

Um eine virtuelle LAN(VLAN)-Spanning Tree-Instanz (VSTP auf universellen 5G-Routing-Plattformen der MX-Serie) zu identifizieren, geben Sie den Namen der Routing-Instanz gefolgt von einem Doppelkolon (::) und der VLAN-ID an. Um beispielsweise die VSTP-Instanz für VLAN 10 in der globalen Standardroutinginstanz zu identifizieren, fügen Sie die context Zeichenfolge (SNMPv3) oder community (SNMPv1 oder v2) eindefault::10@public.

Aktivieren des SNMP-Zugriffs über Routing-Instanzen

Um SNMP-Manager in anderen Routinginstanzen als der Standardroutinginstanz den Zugriff auf SNMP-Informationen zu ermöglichen, fügen Sie die routing-instance-access Anweisung auf der [edit snmp] Hierarchieebene ein:

Wenn diese Anweisung nicht in der SNMP-Konfiguration enthalten ist, können SNMP-Manager von anderen Routinginstanzen als der Standardroutinginstanz nicht auf SNMP-Informationen zugreifen. Diese Einstellung gilt für Anfragen für jede SNMP-Version (SNMP v1, v2 oder v3).

Angeben einer Routing-Instanz in einer SNMPv1- oder SNMPv2c-Community

Sie können die Routing-Instanz zusammen mit den Clientinformationen angeben, wenn Sie einen Client zu einer SNMP-Community hinzufügen. Um die Routing-Instanz anzugeben, zu der ein Client gehört, fügen Sie die routing-instance Anweisung gefolgt vom Namen der Routing-Instanz und den Clientinformationen in die SNMP-Konfiguration ein.

Das folgende Beispiel zeigt die Konfigurationsanweisung zum Hinzufügen von Routing-Instanz test-ri zur SNMP-Community1.

Anmerkung:

Routing-Instanzen, die auf Hierarchieebene [edit snmp community community-name] angegeben sind, werden dem logischen Standardsystem in der Community hinzugefügt.

Wenn die Routinginstanz in einem logischen System definiert ist, fügen Sie die routing-instance Anweisung auf der [edit snmp community community-name logical-system logical-system-name] Hierarchieebene wie im folgenden Beispiel ein:

Beispiel: Konfigurieren von Schnittstelleneinstellungen für eine Routing-Instanz

In diesem Beispiel wird einer Routinginstanz namens INFrtd eine 802.3ad ae0-Schnittstellenkonfiguration zugewiesen:

Der folgende snmpwalk Befehl zeigt, wie Sie SNMP-bezogene Informationen von Router1 und der 802.3ae-Bündelschnittstelle der Routinginstanz INFrtd mit der SNMP-Community publicabrufen:

Konfigurieren von Zugriffslisten für SNMP-Zugriff über Routing-Instanzen

Sie können Zugriffslisten erstellen und pflegen, um den Zugriff auf SNMP-Informationen zu verwalten. Die Konfiguration von Zugriffslisten ermöglicht es Ihnen, den SNMP-Zugriff auf Clients einer bestimmten Routinginstanz zuzulassen oder abzulehnen, und gilt für Anforderungen für eine beliebige SNMP-Version.

Das folgende Beispiel zeigt, wie Sie eine Zugriffsliste erstellen:

Die im Beispiel angegebene Konfiguration:

  • Schränkt clients ri1 beim Zugriff auf SNMP-Informationen ein.

  • Ermöglicht Clients in ls1/default, ls1/ri2und allen anderen Routing-Instanzen mit Namen, die mit ls1 dem Zugriff auf SNMP-Informationen beginnen.

Sie können das Platzhalterzeichen (*) verwenden, um eine Zeichenfolge im Namen der Routinginstanz darzustellen.

Anmerkung:

Sie können den SNMP-Manager der Standardroutinginstanz nicht daran hindern, auf SNMP-Informationen zuzugreifen.