SNMPv2 discover fails due to use of get-bulk SNMP request

Products

• CA Infrastructure Management
• CA Performance Management - Usage and Administration

Issue/Introduction

SNMPv2c based discovery fails due to use of get-bulk SNMP requests.

Environment

r3.0 and older releases

Cause

By design CAPM uses get-bulk for SNMPv2c requests. This provides better/faster response for larger tables in modern network devices. 

Many older network devices also running older firmware either outright don't support get-bulk, or do support it but perform very poorly when trying to respond to these types of requests. 

When we see failure of any kind for get-bulk, we default back to trying with SNMPv1, where it often works due to use of get-next. 

In many cases the devices will respond to get-next via SNMPv2c. But due to how we default at failure of get-bulk, we succeed for v1 get-next. The problem is when it comes to many things, especially interfaces, we don't get the correct data for the high speed interfaces (v1 only supports the low speed interface table). 

Resolution

The code change implemented by engineering solves this problem. It now takes the following steps:

1. Try SNMPv2c by sending a get-bulk request
2. If the SNMPv2c based get-bulk request fails send SNMPv2c get-next request
3. If the SNMPv2c get-bulk and subsequent get-next requests both fail fall back to utilizing SNMPv1 if it is responsive on the device

This fix will make it into r3.1 and also the next monthly update kit for r3.0, likely the February kit.

 

Note doing so will require they upgrade next to a minimum of r3.1 or the r3.0 or newer February kit (or whatever month kit it makes it into). Updating to any release prior to those would remove the new code that resolves this.

Additional Information

After the fix was installed, we can observe the get-bulk failure followed by the switch to try using the SNMPv2c get-next request method.

 

Jan 25 18:07:29.788: Column 1.3.6.1.2.1.4.20.1.3 has 1 entries with reading error: SUCCESS

Jan 25 18:07:29.788: DEBUG Send on-demand request for table 1 with maximum repetitions 10: [1.3.6.1.2.1.2.2.1.6, 1.3.6.1.2.1.2.2.1.5, 1.3.6.1.2.1.2.2.1.7, 1.3.6.1.2.1.2.2.1.3, 1.3.6.1.2.1.2.2.1.8, 1.3.6.1.2.1.2.2.1.2, 1.3.6.1.2.1.2.2.1.1]

Jan 25 18:07:29.874: DEBUG  Got RESOURCE_NOT_AVAILABLE error

Jan 25 18:07:29.874: SNMP error 13 for column 1.3.6.1.2.1.2.2.1.6 that already has 0 rows.  Re-read table=true

...

Jan 25 18:07:29.875: SNMP error 13 for column 1.3.6.1.2.1.2.2.1.1 that already has 0 rows.  Re-read table=true

Jan 25 18:07:29.875: Re-read table 1 with GetNext method.

Jan 25 18:07:29.875: DEBUG Use GetNext to read table 1 with OIDs: [1.3.6.1.2.1.2.2.1.6, 1.3.6.1.2.1.2.2.1.5, 1.3.6.1.2.1.2.2.1.7, 1.3.6.1.2.1.2.2.1.3, 1.3.6.1.2.1.2.2.1.8, 1.3.6.1.2.1.2.2.1.2, 1.3.6.1.2.1.2.2.1.1]

Jan 25 18:08:16.898: Read completed for table 1

Jan 25 18:08:16.898: Column 1.3.6.1.2.1.2.2.1.6 has 28 entries with reading error: SUCCESS

...

Jan 25 18:08:16.898: Column 1.3.6.1.2.1.2.2.1.2 has 169 entries with reading error: SUCCESS