Manage Multiple Instances of OSPF with SNMP Contexts

Introduction

This document provides sample configurations for SNMPv2 and SNMPv3 that describe how to use SNMP contexts to manage multiple instances of Open Shortest Path First (OSPF).

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

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

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

The OSPF MIB defined by the IETF (RFC 1850 ) was designed to work with only one OSPF process/instance on a given router.

For example, there is only a single ospfRouterId object, not a table of them. In order to handle multiple instances, RFC 4750 suggests that you use SNMPv3 contexts to provide per-instance views.

SNMP Context Aware

Prior to making the IOS OSPF SNMP code context aware, the system would pick a more or less random "default" instance when it returned the scalar objects and some tables. In these cases, information from the other instances was not available via SNMP. For some other tables, SNMP would mash together the entries from all the instances without any way to discern which was which. In many cases, this could lead to ambiguous or duplicate entries. It was especially not good practice in PE-CE configurations where IP addresses and neighbor router-IDs might not be unique. This made monitoring and troubleshooting individual CE instances difficult or impossible.

With the current context-aware IOS code (when no context is specified), the old behavior for scalar objects still exists. The only change is that it now limits all rather than just some of the tables to the same "default" OSPF instance as the scalars. When contexts are supplied, the SNMP queries can be targeted to a particular OSPF instance, and all the information for that instance can be retrieved in a consistent and unambiguous manner.

If SNMPv3 is used, the context string can be supplied directly with the poll. SNMPv2c does not provide a context. However, you can map SNMP community strings to contexts in the IOS configuration, and these contexts can be used to direct SNMPv2 polls to a specific OSPF instance.

Configuration

This configuration example is based on 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

This configuation example is based on 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

Note: Use the Command Lookup Tool (registered customers only) to find more information on the commands used in this document.

Verify

You can use the snmpwalk command on any client machine in order to verify the output.

Note: The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

SNMPv2 Verification

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 Verification

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

Related Information

• OSPF Configuration Management with SNMP
• Technical Support & Documentation - Cisco Systems