Gestione di più istanze di OSPF con contesti SNMP

Introduzione

In questo documento vengono fornite configurazioni di esempio per SNMPv2 e SNMPv3 che descrivono come utilizzare i contesti SNMP per gestire più istanze di Open Shortest Path First (OSPF).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Il MIB OSPF definito dall'IETF (RFC 1850 ) è stato progettato per funzionare con un solo processo/istanza OSPF su un determinato router.

Ad esempio, esiste solo un singolo oggetto ospfRouterId, non una relativa tabella. Per gestire più istanze, la RFC 4750 suggerisce di utilizzare i contesti SNMPv3 per fornire viste per istanza.

Sensibile al contesto SNMP

Prima di rendere il contesto di codice SNMP IOS OSPF compatibile, il sistema sceglieva un'istanza "predefinita" più o meno casuale quando restituiva gli oggetti scalari e alcune tabelle. In questi casi, le informazioni delle altre istanze non erano disponibili tramite SNMP. Per alcune altre tabelle, il protocollo SNMP unisce le voci di tutte le istanze senza individuare quale sia la tabella selezionata. In molti casi, ciò potrebbe portare a voci ambigue o duplicate. In particolare, non era buona norma nelle configurazioni PE-CE dove gli indirizzi IP e gli ID dei router adiacenti potrebbero non essere univoci. Ciò rendeva difficile o impossibile il monitoraggio e la risoluzione dei problemi di singole istanze CE.

Con il codice IOS sensibile al contesto corrente (quando non è specificato alcun contesto), il vecchio comportamento per gli oggetti scalari esiste ancora. L'unica modifica consiste nel fatto che ora tutte le tabelle, anziché solo alcune, vengono limitate alla stessa istanza OSPF "predefinita" degli scalari. Quando vengono forniti i contesti, le query SNMP possono essere indirizzate a una particolare istanza OSPF e tutte le informazioni relative a tale istanza possono essere recuperate in modo coerente e non ambiguo.

Se si utilizza SNMPv3, la stringa di contesto può essere fornita direttamente con il polling. SNMPv2c non fornisce un contesto. Tuttavia, è possibile mappare le stringhe della community SNMP ai contesti nella configurazione IOS e questi contesti possono essere utilizzati per indirizzare i polling SNMPv2 a un'istanza OSPF specifica.

Configurazione

Questo esempio di configurazione è basato su 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

Questo esempio di configurazione è basato su 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

Nota: per ulteriori informazioni sui comandi menzionati in questo documento, usare lo strumento di ricerca dei comandi (solo utenti registrati).

Verifica

È possibile utilizzare il comando snmpwalk su qualsiasi computer client per verificare l'output.

Nota: lo strumento Output Interpreter (solo utenti registrati) (OIT) supporta alcuni comandi show. Usare l'OIT per visualizzare un'analisi dell'output del comando show.

Verifica SNMPv2

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

Verifica SNMPv3

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

Informazioni correlate

• Gestione della configurazione OSPF con SNMP
• Documentazione e supporto tecnico – Cisco Systems