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.

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.