Gestion de plusieurs instances OSPF avec les contextes SNMP

Introduction

Ce document fournit des exemples de configurations pour SNMPv2 et SNMPv3 qui décrivent comment utiliser des contextes SNMP pour gérer plusieurs instances d'Open Shortest Path First (OSPF).

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

La MIB OSPF définie par l'IETF (RFC 1850 ) a été conçue pour fonctionner avec un seul processus/instance OSPF sur un routeur donné.

Par exemple, il n'y a qu'un seul objet ospfRouterId, pas une table d'entre eux. Afin de gérer plusieurs instances, RFC 4750 suggère que vous utilisiez des contextes SNMPv3 pour fournir des vues par instance.

Prise en compte du contexte SNMP

Avant de prendre en compte le contexte du code SNMP OSPF IOS, le système sélectionnait une instance par défaut plus ou moins aléatoire lorsqu'il retournait les objets scalaires et certaines tables. Dans ces cas, les informations des autres instances n'étaient pas disponibles via SNMP. Pour d'autres tables, le protocole SNMP rassemblerait les entrées de toutes les instances, sans aucun moyen de déterminer lesquelles. Dans de nombreux cas, cela peut conduire à des entrées ambiguës ou en double. Ce n'était surtout pas une bonne pratique dans les configurations PE-CE où les adresses IP et les ID de routeur voisins peuvent ne pas être uniques. Cela rendait difficile ou impossible la surveillance et le dépannage des instances CE individuelles.

Avec le code IOS sensible au contexte actuel (quand aucun contexte n'est spécifié), l'ancien comportement des objets scalaires existe toujours. Le seul changement est qu'il limite maintenant tous les tableaux plutôt que seulement quelques-uns à la même instance OSPF « par défaut » que les scalaires. Lorsque des contextes sont fournis, les requêtes SNMP peuvent être ciblées vers une instance OSPF particulière, et toutes les informations de cette instance peuvent être récupérées de manière cohérente et sans ambiguïté.

Si SNMPv3 est utilisé, la chaîne de contexte peut être fournie directement avec le sondage. SNMPv2c ne fournit pas de contexte. Cependant, vous pouvez mapper des chaînes de communauté SNMP à des contextes dans la configuration IOS, et ces contextes peuvent être utilisés pour diriger les interrogations SNMPv2 vers une instance OSPF spécifique.

Configuration

Cet exemple de configuration est basé sur 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

Cet exemple de configuration est basé sur 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

Remarque : Utilisez l’outil de recherche de commandes (clients inscrits seulement) pour en savoir plus sur les commandes figurant dans le présent document.

Vérification

Vous pouvez utiliser la commande snmpwalk sur n'importe quel ordinateur client afin de vérifier le résultat.

Note : L'outil Output Interpreter Tool (clients enregistrés uniquement) (OIT) prend en charge certaines commandes show. Utilisez l'OIT pour afficher une analyse de la sortie de la commande show .

Vérification de 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

Vérification 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

Informations connexes

• Gestion de la configuration OSPF avec SNMP
• Support et documentation techniques - Cisco Systems