The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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).
There are no specific requirements for this document.
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
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.
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.
This configuration example is based on SNMPv2:
Router1# router ospf 1 router-id 188.8.131.52 log-adjacency-changes snmp context context1 ! router ospf 2 router-id 184.108.40.206 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 220.127.116.11 log-adjacency-changes snmp context context1 ! router ospf 2 router-id 18.104.22.168 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.
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.
linux>snmpwalk -c public -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 22.214.171.124 linux>snmpwalk -c cx1 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 126.96.36.199 linux>snmpwalk -c cx2 -v2c irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 188.8.131.52
linux>snmpwalk -u u1 -v3 irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 184.108.40.206 linux>snmpwalk -u u1 -v3 -n context1 irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 220.127.116.11 linux>snmpwalk -u u1 -v3 -n context2 irp-view14:7890 OSPF-MIB::ospfRouterId.0 OSPF-MIB::ospfRouterId.0 = IpAddress: 18.104.22.168