Cannot access Cisco MIBs via SNMPGET

[clarsen]

Hello, I'm sure this is a simple fix and I'm too stupid to figure it out, but I'm having trouble accessing Cisco ACE specific OIDs via Net-SNMPs tools. If I run snmpwalk on the device, I get a nice list of standard SNMP OIDs such as SNMPv2-MIB, IF-MIB, IP-MIB, etc with values such as the device name, interface IP counters and all that stuff. But I don't see any Cisco specific OIDs in the list. I really want to be able to monitor the load across real servers and server farms and such on this ACE module.

So, for example, I try running the following command and it says no such object:

snmpget -m +CISCO-SLB-MIB -On -v 2c -c communityname ipaddress CISCO-SLB-MIB::slbServerFarms
.1.3.6.1.4.1.9.9.161.1.2 = No Such Object available on this agent at this OID

I read you should try adding an index to the OID as there may be multiple sub objects (and of course there are multiple server farms) but I get the same thing:

snmpget -m +CISCO-SLB-MIB -On -v 2c -c communityname ipaddress CISCO-SLB-MIB::slbServerFarms.0
.1.3.6.1.4.1.9.9.161.1.2.0 = No Such Object available on this agent at this OID

Just to confirm a valid OID, I get this:

snmpget -m +CISCO-SLB-MIB -On -v 2c -c communityname ipaddress SNMPv2-MIB::sysDescr.0
.1.3.6.1.2.1.1.1.0 = STRING: Application Control Engine Service Module

I also tried snmptable with CISCO-ENHANCED-SLB-MIB::cesServerFarmRserverTable and it just says "Was that a table?"

So I think it must be a permission problem or some config that I have to tweak. Right now the only SNMP config is:

snmp-server community communityname group Network-Monitor

My device version info is:

Software
  loader:    Version 12.2[120]
  system:    Version A2(1.4) [build 3.0(0)A2(1.4) adbuild_11:54:12-2009/03/05_/auto/adbu-rel2/rel_a2_1_4_throttle/REL_3_0_0_A2_1_4]
  system image file: [LCP] disk0:c6ace-t1k9-mz.A2_1_4.bin
  installed license: ACE-SEC-LIC-K9 ACE-SSL-05K-K9

Thank you for your help!

[yjdabear]

You got it: It is a permission problem, because slbServerFarmTable (of CISCO-SLB-MIB) and cesServerFarmRserverTable (of CISCO-ENHANCED-SLB-MIB) are both marked by the vendor as "not-accessible":

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=slbServerFarmTable&translate=Translate&submitValue=SUBMIT

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=cesServerFarmRserverTable&translate=Translate&submitValue=SUBMIT

How did you exactly try to access CISCO-ENHANCED-SLB-MIB::cesServerFarmRserverTable with snmptable? From what I read, one should be able to toggle the snmptable behavior with the "-Ci" switch, as in "snmptable -Ci ... cesServerFarmRserverTable".

[clarsen]

Thank you! Your post led me to search the -Ci option and I found something else that worked with the tables. It turned out that the command I was using didn't include ALL of the Cisco MIB files and all I had to do was include all (just using +) and it worked:

C:\Program Files\Net-SNMP\bin>snmptable -m + -v 2c -c communityname ipaddress CISCO-ENHANCED-SLB-MIB::cesServerFarmRserverTable
SNMP table: CISCO-ENHANCED-SLB-MIB::cesServerFarmRserverTable

cesServerFarmRserverAdminWeight cesServerFarmRserverOperWeight cesServerFarmRserverMaxConns cesServerFarmRserverMinConns cesServerFarmRserverAdminStatus cesServerFarmRserverOperStatus    cesServerFarmRserverStateDescr cesServerFarmRserverBackupName cesServerFarmRserverBackupPort cesServerFarmRserverTotalConns cesServerFarmRserverFailedConns cesServerFarmRserverDroppedConns cesServerFarmRserverCurrentConns cesServerFarmRserverStorageType cesServerFarmRserverRowStatus cesServerFarmRserverDescr

row data....

However I'm still confused on why a table can be marked "non-accessible" but then it is accessible. Does that mean you just have to use a different method to access it? Thank you again!

[yjdabear]

Here're some good explanations of this phenomenon:

"Sometimes, the index value is made not accessible by the manufacturer of the device
(e.g. because the index in the table might change after a reboot)."

"This is because, as I have stated earlier, these objects are not value leaves of the OID tree,
and therefore cannot be returned."

"...because of The Chicken, and because of The Egg. Namely, to GET the value of the index, you would have to know the value

of the index in the first place: asking for "hey, I want the value of the index where the value of the index is Z" would

simply get you Z. This would be completely irrelevant and SMIv2 thus mandates that all indexes be declared as

not-accessible - there is one exception, which I'm not going to detail - when the table contains only indexes - e.g.

when it simply defines relationships between indexes in other tables. However, this is for 2nd year in SNMP, so let's

forget about this for now - readers etc... STD 58, RFC 2578 etc"

"InterMapper has a facility that allows you to derive the values of these columns from the index itself, even from

columns that are not accessible. The notation oid[a:b] means to fetch the OID oid and compute the value from the index:"

BTW, it seems to be that "snmptable -Ci -Cb ..." is typically used to print the "tables".

[Joe Clarke]

This is an interesting thread, and probably something which is unclear to a lot of people.  Tables and their entries (think header rows) are inaccessible because they do not contain data directly.  Data is only contained in the cells within the table.  The cells in this case are the SNMP objects defined within each table entry (or row).  So, a table is inaccessible as a whole, but each of its data cells can be accessed.

If you think of it like a spreadsheet, it may be a little more useful.  But let's try a visual.

cesServerFarmRserverTable

cesServerFarmRserverPort	cesServerFarmRserverAdminWeight	cesServerFarmRserverOperWeight
80	100	100
8080	50	10

The header row in this table is called cesServerFarmRserverEntry.  It contains the column names for our data.  Each row has a unique number associated with it.  That is the cseServerFarmRserverPort.  In a typical spreadsheet program, this would be the column at the far left which you cannot edit.  It just enumerates the rows.  In this example, that column is named cesServerFarmRserverPort.  If I wanted to tell someone how to get the value of cesServerFarmRserverAdminWeight at a particular row, I would say, "go to row 80, and read the value from the cesServerFarmRserverAdminWeight column.  In this case, they would read 100.

SNMP operates in the same fashion.  For one to get a specific value (i.e. perform an SNMP GET), one must know the specific column name and row number.  In the actual case of the cesServerFarmRserverTable, the row number is actually a combination of the slbEntity, slbServerFarmName, cesRserverName, and cesServerFarmRserverPort, but the concept is the same.  You can only do an SNMP GET on a precise address in a given table (i.e. on a cell).  To do a GET on cesServerFarmRserverTable directly would make no sense since an atomic value could not be returned.

An SNMP Walk, on the other hand, allows you to start with the table itself, then walk through each cell in the table, printing out the value at that cell.

A tool like snmptable essentially performs recursive GET-NEXT queries to walk through all of the rows, then print the value of each cell in a tabular format.

[clarsen]

Thank ya'll for your help. It makes sense that a table behaves in the same way a spreadsheet or a DB table behaves and SNMP can only return a single value at a time, so requesting just the OID of the table won't work. So that leads to a couple of other questions:

To access a specific value in a table, would you use the "oid[a:b]" notation where "a" is the column and "b" is the row? So for example

CISCO-ENHANCED-SLB-MIB::cesServerFarmRserverTable[0:0] should return "cesServerFarmRserverAdminWeight", i.e. the header for that column, from the results in my second post, right?Or would it return the first row of actual data under that column?

Then if you have a table, you don't necessarily know how many rows there will be, maybe columns are predefined, but not rows. So then is it best-practice to just iterate through the entire table to grab the whole thing each time you need to poll, or do you poll just a cell and check occasionally for row count changes?

And finally, if the MIB name doesn't include the term "table", is there any way to know that a MIB is a table? Maybe the combination of "not-accessible" and "SEQUENCE" or just being marked of the type "SEQUENCE" defines it as a table?

Thank you again for putting up with an SNMP newbie!

[Joe Clarke · Accepted solution]

In order to access the data in a particular cell in the table, you do need to use a notation similar to the one you mention, but it will be in the ASN.1 dotted decimal notation, and you must use the index values within the the cesServerFarmRserverTable.  As I mentioned before, those indexes are slbEntity, slbServerFarmName, cesRserverName, and cesServerFarmRserverPort.  So, an actual cell address would look like cesServerFarmRserverAdminWeight.1.3.119.119.119.3.119.101.98.80.  Where the first .1 is the slbEntity ID, .3.119.119.119 is notation for the string "www", 3.119.101.98 is notation for the string "web", and .80 is the port number 80.

If you need to figure out all of the rows in a table, then you need to do SNMP GET-NEXT queries to iterate through each row and each cell in the table.  If you know of a specific row address (see indexes above), then you can poll the cells at those addresses and forgo the GET-NEXT walking.

Actually, most objects which are tables are named a such.  In fact, that's probably the best rule of thumb.  But really, you know that an object is in a table if its grandparent object will be of type SEQUENCE.