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:

  • 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

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.

Comments


Santino Rizzo (guest)
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.


Scott (guest)
December 22, 2010 at 5:59 p.m. UTC

Small spelling error: "Now with our SNMP view in place fpr this community" fpr


Cyrus (guest)
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.


Paul (guest)
March 22, 2014 at 5:30 a.m. UTC

Thanks Jeremy for your efforts.

A great, practical, working example.


dragonballzzie
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.

Comments have closed for this article due to its age.