Configuring SNMP Views to Deter Runaway NMS Polling
By stretch | Monday, December 20, 2010 at 2:28 a.m. UTC
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:
- 220.127.116.11.18.104.22.168 - ipRouteTable (IP route table)
- 22.214.171.124.126.96.36.199 - ipNetToMediaTable (IPv4 ARP table) (deprecated by ipNetToPhysicalTable)
- 188.8.131.52.184.108.40.206 - ipNetToPhysicalTable (combined IPv4/IPv6 translation table)
- 220.127.116.11.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 18.104.22.168.22.214.171.124 excluded 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.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 22.214.171.124.6.3.15 excluded Router(config)# snmp-server view NMS 126.96.36.199.6.3.16 excluded Router(config)# snmp-server view NMS 188.8.131.52.6.3.18 excluded
Our final SNMP view configuration is below. Note that the OID 184.108.40.206.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 220.127.116.11.18.104.22.168 RFC1213-MIB::ipRouteTable = No Such Object available on this agent at this OID
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
December 20, 2010 at 2:54 a.m. UTC
Limiting the ARP and MAC tables from polling is recommended if that polling impacts CPU performance on the devices. However, if your NMS platform provides any kind of user tracking, it will need those tables to put that information together. If performance is not impacted, it's best to leave them in there.
December 22, 2010 at 5:59 p.m. UTC
Small spelling error: "Now with our SNMP view in place fpr this community" fpr
December 27, 2010 at 2:18 a.m. UTC
Thanks for this write up, this post saved my day :D I was testing Cisco netManager before implementing it on site.
March 22, 2014 at 5:30 a.m. UTC
Thanks Jeremy for your efforts.
A great, practical, working example.
August 29, 2016 at 6:08 p.m. UTC
hi stretch....this is my config.
access-list 100 permit 10.10.10.10 snmp-server view abc-V3 iso included snmp-server group abc-PRIME v3 auth read abc-V3 access 50 snmp-server user abcprimeuser abc-PRIME v3 auth md5 cisco123 priv des 123cisco access 100 snmp-server trap-source loopback 0 snmp-server host 10.10.10.10 version 3 auth abcprimeuser
this is created for Prime and i need it to for only read view.i need it for only read view.