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:
- 22.214.171.124.126.96.36.199 - ipRouteTable (IP route table)
- 188.8.131.52.184.108.40.206 - ipNetToMediaTable (IPv4 ARP table) (deprecated by ipNetToPhysicalTable)
- 220.127.116.11.18.104.22.168 - ipNetToPhysicalTable (combined IPv4/IPv6 translation table)
- 22.214.171.124.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 126.96.36.199.188.8.131.52 excluded Router(config)# snmp-server view NMS 184.108.40.206.220.127.116.11 excluded Router(config)# snmp-server view NMS 18.104.22.168.22.214.171.124 excluded Router(config)# snmp-server view NMS 126.96.36.199.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 188.8.131.52.6.3.15 excluded Router(config)# snmp-server view NMS 184.108.40.206.6.3.16 excluded Router(config)# snmp-server view NMS 220.127.116.11.6.3.18 excluded
Our final SNMP view configuration is below. Note that the OID 18.104.22.168.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 22.214.171.124.126.96.36.199 RFC1213-MIB::ipRouteTable = No Such Object available on this agent at this OID