Partial results from NSA snmp.walk() function

[Anon Anon]

I am working on a probe using the NSA, and the probe needs to get SNMP values from a device.  Many of these values are from a single SNMP table, so I am using the snmp.walk() function.  Here is what the NSA whitepaper says about it:

snmp.walk (SnmpHandle, RootPath, RestrictToPath)
    Performs a “snmpwalk” starting at the rootpath, limiting it to the restrictpath.

I am not 100% sure how to use RootPath and RestrictToPath together, but I found that I could use the same OID for both and get the results I wanted.  (Any hints about how I should be using those arguments would be appreciated.)  In my testing, here is the call I am currently making:

result = snmp.walk(snmph, ".1.3.6.1.4.1.789.1.5.4.1", ".1.3.6.1.4.1.789.1.5.4.1")

I noticed that I received exactly 300 results, which is the same thing that happens by default when using the SNMP Browser in the snmpget probe GUI.  Because there are 16 unique indexes in the SNMP table, it did not seem likely there are 300 values.  With the snmpget probe GUI, was able to retrieve 448 values from that OID when I enabled the Full Browse option.

How can I get all of the values I need from the snmp.walk() function?

Thanks,
Keith

[Anon Anon]

Keith,

Glad to see that you are playing with the NSA!
The snmp.walk is operating in chunks of 300 oids per run.  The next version of the NSA (1.04) will allow you to add a fourth parameter to snmp.walk stating the maximum number oids returned per request. This will give you a large single table to work with.

The solution is to repetitively call the snmp.walk until the walk is completed.  The returned table contains 3 elements that are critical to succeeding in this task.  They are also exposed in the example_snmp script, but should also be addressed in the documentation (I'll fix that in 1.04).  Anyway, pay attention to the done, numoids and the lastoid element (as well as the oids table) .

printf ("--------")
h   = snmp.create (1,"193.71.55.245","public")
out = snmp.walk   (h,"1.3.6.1.2.1","1.3.6.1.2.1")
idx = 0

while out ~= nil do

    for i=0,out.numoids-1 do
        printf ("%d oid: %s, type: %s", idx, out.oids.oid, out.oids.type)
        idx=idx+1
    end
   
    if out.done == 1 then break end
   
    out = snmp.walk   (h,out.lastoid,"1.3.6.1.2.1")
end
snmp.delete(h)

The lastoid and root oid is too limit the request starting point (starting from the lastoid in the previous walk but within the base of root oid)

Hope this clears things up,
Carstein

PS. NSA v. 1.04 will leave my desk shortly...

[Anon Anon]

Thanks for the help, Carstein!  I noticed the lastoid element in the table, and I thought that might be the key to this but was not sure how to use it.  I think I even tried calling snmp.walk() using that OID, but I think I put it as the last argument instead of the second argument.  The way you are using the RootPath and RestrictToPath arguments now makes more sense to me too.

While working on the probe, I concluded that I probably do not need to pull the entire SNMP table of 448 OIDs.  If all of the various OIDs in the table, I am only using around five different ones for all 16 indexes, which is 80 total.  Of course, now I am doing five separate calls to snmp.walk() to get those OIDs.  I may go back to pulling the whole table, especially when I start needing more data, but this got me around the 300 limit without too much complication.

This got me wondering...  From an efficiency standpoint, when does it make sense to pull more OIDs in a single call versus making multiple calls to snmp.walk()?  Do you have any insights on this based on how the NSA stores the data or how SNMP works?

Thanks,
Keith

[Anon Anon]

You should always reduce the amount of time that the target snmp agent will spend on your request.  A large walk will induce more cpu cycles than a small one. As a consequence, more UDP packets will flow between the two (first a SNMP_MSG_GET, then subsequent SNMP_MSG_GETNEXT requests).  The return data is also parsed and stored (first as PDS, then converted to Lua table).  Thus large data sets, causes large lua tables.

If you need to work on many parts of the MIB then it would be useful to grab the whole thing otherwise I would go for smaller walks.