Verwalten mehrerer Instanzen von OSPF mit SNMP-Kontexten

Einführung

Dieses Dokument enthält Beispielkonfigurationen für SNMPv2 und SNMPv3, in denen die Verwendung von SNMP-Kontexten zum Verwalten mehrerer Instanzen von Open Shortest Path First (OSPF) beschrieben wird.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

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

Hintergrundinformationen

Die von der IETF (RFC 1850 ) definierte OSPF-MIB wurde für die Verwendung mit nur einem OSPF-Prozess/-Prozess auf einem bestimmten Router entwickelt.

Es gibt z. B. nur ein ospfRouterId-Objekt, keine Tabelle davon. Zur Behandlung mehrerer Instanzen empfiehlt RFC 4750 die Verwendung von SNMPv3-Kontexten zur Bereitstellung von Instanzenansichten.

SNMP-Kontextsensitiv

Bevor das System den IOS OSPF-SNMP-Codekontext erkennt, wählte es eine mehr oder weniger zufällige "Standard"-Instanz aus, wenn es die skalaren Objekte und einige Tabellen zurückgab. In diesen Fällen waren die Informationen aus den anderen Instanzen nicht über SNMP verfügbar. Bei einigen anderen Tabellen mischte SNMP die Einträge aller Instanzen zusammen, ohne dass erkennbar war, welche. In vielen Fällen kann dies zu mehrdeutigen oder doppelten Einträgen führen. Besonders bei PE-CE-Konfigurationen, bei denen IP-Adressen und Nachbarrouter-IDs nicht eindeutig sind, war dies keine bewährte Vorgehensweise. Dadurch wurde die Überwachung und Fehlerbehebung einzelner CE-Instanzen schwierig oder unmöglich.

Mit dem aktuellen kontextsensitiven IOS-Code (wenn kein Kontext angegeben ist) existiert das alte Verhalten für skalare Objekte immer noch. Die einzige Änderung besteht darin, dass nun nicht nur einige Tabellen, sondern alle auf die gleiche "Standard"-OSPF-Instanz wie die Skalare beschränkt werden. Wenn Kontexte angegeben werden, können die SNMP-Abfragen auf eine bestimmte OSPF-Instanz ausgerichtet werden, und alle Informationen für diese Instanz können konsistent und eindeutig abgerufen werden.

Wenn SNMPv3 verwendet wird, kann die Kontextzeichenfolge direkt mit der Abfrage bereitgestellt werden. SNMPv2c stellt keinen Kontext bereit. Sie können SNMP-Community-Strings jedoch Kontexten in der IOS-Konfiguration zuordnen. Diese Kontexte können verwendet werden, um SNMPv2-Polls an eine bestimmte OSPF-Instanz zu leiten.

Konfiguration

Dieses Konfigurationsbeispiel basiert auf SNMPv2:

Router1#
 
router ospf 1
 router-id 1.1.1.111
 log-adjacency-changes
 snmp context context1
!
router ospf 2
 router-id 4.4.4.111
 log-adjacency-changes
 snmp context context2

!--- Associates the SNMP context with the instance. 

!
snmp-server user u2 g2 v2c

!--- Configures the user u2 to the SNMP group g2 and


!--- specifies the group is using the SNMPv2c security model.

snmp-server group g2 v2c

!--- Configures the SNMP group g2 and specifies


!--- the group is using the SNMPv2c security model.

snmp-server group g2 v2c context context1
snmp-server group g2 v2c context context2
snmp-server community public RO

!--- Community access string to permit access


!--- to the SNMP.

snmp-server community cx1 RO
snmp-server community cx2 RO
snmp-server context context1
snmp-server context context2
snmp mib community-map cx1 context context1 security-name u2

!--- Associates the SNMP community cx1 with


!--- the context context 1.

snmp mib community-map cx2 context context2 security-name u2

Dieses Konfigurationsbeispiel basiert auf SNMPv3:

Router1#
 
router ospf 1
 router-id 1.1.1.111
 log-adjacency-changes
 snmp context context1
!
router ospf 2
 router-id 4.4.4.111
 log-adjacency-changes
 snmp context context2
!
snmp-server user u1 g1 v3
snmp-server group g1 v3 noauth
snmp-server group g1 v3 noauth context context1
snmp-server group g1 v3 noauth context context2
snmp-server context context1
snmp-server context context2

Hinweis: Verwenden Sie das Command Lookup Tool (nur registrierte Kunden), um weitere Informationen zu den in diesem Dokument verwendeten Befehlen zu erhalten.

Überprüfung

Sie können den Befehl snmpwalk auf jedem Clientcomputer verwenden, um die Ausgabe zu überprüfen.

Hinweis: Das Output Interpreter Tool (nur registrierte Kunden) (OIT) unterstützt bestimmte show-Befehle. Verwenden Sie das OIT, um eine Analyse der Ausgabe des Befehls show anzuzeigen.

SNMPv2-Überprüfung

linux>snmpwalk -c public -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

linux>snmpwalk -c cx1 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 1.1.1.111

linux>snmpwalk -c cx2 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

SNMPv3-Überprüfung

linux>snmpwalk -u u1 -v3 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

linux>snmpwalk -u u1 -v3 -n context1 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 1.1.1.111

linux>snmpwalk -u u1 -v3 -n context2 irp-view14:7890 OSPF-MIB::ospfRouterId.0
OSPF-MIB::ospfRouterId.0 = IpAddress: 4.4.4.111

Zugehörige Informationen

• OSPF-Konfigurationsmanagement mit SNMP
• Technischer Support und Dokumentation für Cisco Systeme