Configuring SNMP Views to Deter Runaway NMS Polling

A reader, Kyle, recently wrote to share his experience troubleshooting an issue with NMS software performing automated SNMP crawling. He encountered an issue where an NMS application was automatically discovering all available SNMP object identifiers (OIDs), which was placing unnecessary strain on the management network and on the devices being polled.

The problem is that, by default, an SNMPv2c community string configured on Cisco IOS will be granted access to all SNMP objects; interface counters, the IP routing table, ARP tables, and so on. Obviously, a network management system typically needs access to only a subset of all available information. Kyle's solution was to implement SNMP views, which we'll discuss here.

Basic SNMPv2c Configuration

For illustration, let's first look at SNMP as configured without a view. Before getting into SNMP configuration, we want to first define an access list which matches all of our NMS servers. This access list will be employed in our SNMP community statement to restrict the source networks from which SNMP queries may be received. For the sake of this example, we'll assume all of our NMS servers reside in the 192.168.1.0/24 subnet.

Router(config)# ip access-list standard NMS_Servers
Router(config-std-nacl)# permit 192.168.1.0 0.0.0.255
Router(config-std-nacl)# exit

Now for the SNMP configuration. We'll specify read-only (ro) access for the community string j7Yr-s-WInlBUU_SpOKb, and apply our NMS_Servers access list.

Router(config)# snmp-server community j7Yr-s-WInlBUU_SpOKb ro NMS_Servers

This configuration makes all objects readable to this community string. To get an idea of just how much information can be gleaned, you can extract all available objects using the snmpwalk utility.

$ snmpwalk -Os -c j7Yr-s-WInlBUU_SpOKb -v 2c 192.168.1.3
sysDescr.0 = STRING: Cisco IOS Software, C181X Software (C181X-ADVIPSERVICESK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Thu 26-Feb-09 03:22 by prod_rel_team
sysObjectID.0 = OID: enterprises.9.1.641
sysUpTimeInstance = Timeticks: (382691) 1:03:46.91
sysContact.0 = STRING: 
sysName.0 = STRING: Router
sysLocation.0 = STRING: 
sysServices.0 = INTEGER: 78
sysORLastChange.0 = Timeticks: (0) 0:00:00.00
sysORID.1 = OID: enterprises.9.7.129
sysORID.2 = OID: enterprises.9.7.115
sysORID.3 = OID: enterprises.9.7.265
sysORID.4 = OID: enterprises.9.7.112
...

Far more information is returned than is needed for the throughput and environmental monitoring operations typically performed by NMS devices. To restrict the volume of information returned, we'll configure an SNMP view.

Configuring an SNMP View

Following the recommendations of Cisco, we'll exclude the following portions of the root MIB:

• 1.3.6.1.2.1.4.21 - ipRouteTable (IP route table)
• 1.3.6.1.2.1.4.22 - ipNetToMediaTable (IPv4 ARP table) (deprecated by ipNetToPhysicalTable)
• 1.3.6.1.2.1.4.35 - ipNetToPhysicalTable (combined IPv4/IPv6 translation table)
• 1.3.6.1.2.1.3 - atTable (layer two address table)

You can find a short description of each of these objects using Cisco's SNMP Object Navigator.

We'll create an SNMP view named NMS relative to the SNMP MIB root of "ISO":

Router(config)# snmp-server view NMS iso included

Next, we'll exclude the above MIB branches one by one:

Router(config)# snmp-server view NMS 1.3.6.1.2.1.4.21 excluded
Router(config)# snmp-server view NMS 1.3.6.1.2.1.4.22 excluded
Router(config)# snmp-server view NMS 1.3.6.1.2.1.4.35 excluded
Router(config)# snmp-server view NMS 1.3.6.1.2.1.3 excluded

As a matter of best practice, we'll also exclude MIB objects which could potentially reveal information about configured SNMP credentials. These objects are snmpUsmMIB, snmpVacmMIB, and snmpCommunityMIB.

Router(config)# snmp-server view NMS 1.3.6.1.6.3.15 excluded
Router(config)# snmp-server view NMS 1.3.6.1.6.3.16 excluded
Router(config)# snmp-server view NMS 1.3.6.1.6.3.18 excluded

Our final SNMP view configuration is below. Note that the OID 1.3.6.1.2.1.3 has been automatically translated to the name at (address table).

snmp-server view NMS iso included
snmp-server view NMS at excluded
snmp-server view NMS internet.6.3.15 excluded
snmp-server view NMS internet.6.3.16 excluded
snmp-server view NMS internet.6.3.18 excluded
snmp-server view NMS ip.21 excluded
snmp-server view NMS ip.22 excluded
snmp-server view NMS ip.35 excluded

That's all we'll exclude for this example. Of course, you are free to exclude as many objects as you'd like; just make sure you don't exclude information your NMS will actually need to retrieve.

Finally, we'll apply our new view to the community string we configured earlier. We can do this simply by overwriting our earlier configuration statement, this time specifying a view:

Router(config)# snmp-server community j7Yr-s-WInlBUU_SpOKb view NMS ro NMS_Servers

Now with our SNMP view in place for this community, if we try to perform an snmpwalk of the IP routing table object, we receive an error:

$ snmpwalk -c j7Yr-s-WInlBUU_SpOKb -v 2c 192.168.1.3 1.3.6.1.2.1.4.21
RFC1213-MIB::ipRouteTable = No Such Object available on this agent at this OID