ACE SNMP cesRserverTotalConns "There is no such variable name in this MIB"

Answered Question
Aug 23rd, 2010
User Badges:

I have an ACE 4710 appliance currently running version A3(2.6), though earlier revisions had the same behavior.  I am able to query some parts of the CISCO-ENHANCED-SLB-MIB, but others result in "(noSuchName) [t]here is no such variable name in this MIB." For instance, I can successfully `snmpwalk` cesRserverOperStatus, cesRserverStatechangeDescr, and several other OIDs, but not cesRserverTotalConns, cesRserverFailedConns, nor cesRserverCurrConns.  I've also tried `snmpget` of specific real servers with the same results.  Things like OperStatus and IpAddress work, but Total, Failed, and CurrConns do not.


Here is an snmp debug from the ACE:

First, a query that works:

2010 Aug 23 18:19:46.930481 snmpd[1372]: (ctx:3)asn_parse_objid :   from asn1.c asn_objid, length is 0 
2010 Aug 23 18:19:46.930582 snmpd[1372]: (ctx:3)178189364.000000:iso.3.6.1.4.1.9.9.470.1.1.1.1.14.1.4.116.101.115.116 = NULL  SNMPPKTEND
2010 Aug 23 18:19:46.931635 snmpd[1372]: (ctx:3) SNMPPKTSTRT: 0.000000 160 178189364.000000 0.000000 0.000000 0.000000 0 0 1 1 0   <removed-community-for-security> 12 0 0 0.000000 0.000000 0.0.0.0  0  0  0  0 0 0 0 19 
2010 Aug 23 18:19:46.931661 snmpd[1372]: (ctx:3)snmpv3_get_engineID : context id in snmpv3_get_engineID = 3 
2010 Aug 23 18:19:46.931683 snmpd[1372]: (ctx:3)snmpv3_get_engineID : length in snmpv3_get_engineID = 9 
2010 Aug 23 18:19:46.931725 snmpd[1372]: (ctx:3)snmpv3_get_engineID : context id in snmpv3_get_engineID = 3 
2010 Aug 23 18:19:46.931747 snmpd[1372]: (ctx:3)snmpv3_get_engineID : length in snmpv3_get_engineID = 9 
2010 Aug 23 18:19:46.931780 snmpd[1372]: (ctx:3)var_cesRserverTable : var_cesRserverTable : Request 1 length = 20
2010 Aug 23 18:19:46.931803 snmpd[1372]: (ctx:3)var_cesRserverTable : GET: rservNameLen = 4 groupSubtreeLen 4
2010 Aug 23 18:19:46.931824 snmpd[1372]: (ctx:3)var_cesRserverTable : GET: Incoming rservName  test
2010 Aug 23 18:19:46.931846 snmpd[1372]: (ctx:3)var_cesRserverTable :   GET rservname test magic 17
2010 Aug 23 18:19:46.931384 snmpd[1372]: (ctx:3)var_cesRserverTable :  rs name from tnrpc : test and rs ip 192.0.2.1
2010 Aug 23 18:19:46.931424 snmpd[1372]: (ctx:3)var_cesRserverTable : tnrpc mesg recv successful from rservers stub code
2010 Aug 23 18:19:46.931446 snmpd[1372]: (ctx:3)var_cesRserverTable :  *length 20 rservertype 2 ipaddresstype 1 description 
2010 Aug 23 18:19:46.931504 snmpd[1372]: (ctx:3)178189364.000000:iso.3.6.1.4.1.9.9.470.1.1.1.1.14.1.4.116.101.115.116 = STRING: "ARP-FAILURE"  SNMPPKTEND
2010 Aug 23 18:19:46.931548 snmpd[1372]: (ctx:3) SNMPPKTSTRT: 0.000000 162 178189364.000000 0.000000 0.000000 0.000000 0 0 1 1 0   <removed-community-for-security> 12 0 0 0.00000


Next, a query that does not work:

2010 Aug 23 18:20:55.096428 snmpd[1372]: (ctx:3)asn_parse_objid :   from asn1.c asn_objid, length is 0 
2010 Aug 23 18:20:55.096531 snmpd[1372]: (ctx:3)497544101.000000:iso.3.6.1.4.1.9.9.470.1.1.1.1.17.1.4.116.101.115.116 = NULL  SNMPPKTEND
2010 Aug 23 18:20:55.096577 snmpd[1372]: (ctx:3) SNMPPKTSTRT: 0.000000 160 497544101.000000 0.000000 0.000000 0.000000 0 0 1 1 0   <removed-community-for-security> 12 0 0 0.000000 0.000000 0.0.0.0  0  0  0  0 0 0 0 19 
2010 Aug 23 18:20:55.096603 snmpd[1372]: (ctx:3)snmpv3_get_engineID : context id in snmpv3_get_engineID = 3 
2010 Aug 23 18:20:55.096625 snmpd[1372]: (ctx:3)snmpv3_get_engineID : length in snmpv3_get_engineID = 9 
2010 Aug 23 18:20:55.095827 snmpd[1372]: (ctx:3)snmpv3_get_engineID : context id in snmpv3_get_engineID = 3 
2010 Aug 23 18:20:55.095849 snmpd[1372]: (ctx:3)snmpv3_get_engineID : length in snmpv3_get_engineID = 9 
2010 Aug 23 18:20:55.095883 snmpd[1372]: (ctx:3)var_cesRserverTable : var_cesRserverTable : Request 1 length = 20
2010 Aug 23 18:20:55.095905 snmpd[1372]: (ctx:3)var_cesRserverTable : GET: rservNameLen = 4 groupSubtreeLen 4
2010 Aug 23 18:20:55.095927 snmpd[1372]: (ctx:3)var_cesRserverTable : GET: Incoming rservName  test
2010 Aug 23 18:20:55.095948 snmpd[1372]: (ctx:3)var_cesRserverTable :   GET rservname test magic 26
2010 Aug 23 18:20:55.106549 snmpd[1372]: (ctx:3)var_cesRserverTable :  rs name from tnrpc : test and rs ip 192.0.2.1
2010 Aug 23 18:20:55.106580 snmpd[1372]: (ctx:3)var_cesRserverTable : tnrpc mesg recv successful from rservers stub code
2010 Aug 23 18:20:55.106602 snmpd[1372]: (ctx:3)var_cesRserverTable :  *length 20 rservertype 2 ipaddresstype 1 description 
2010 Aug 23 18:20:55.106669 snmpd[1372]: (ctx:3)497544101.000000:iso.3.6.1.4.1.9.9.470.1.1.1.1.17.1.4.116.101.115.116 = NULL  SNMPPKTEND
2010 Aug 23 18:20:55.105723 snmpd[1372]: (ctx:3) SNMPPKTSTRT: 0.000000 162 497544101.000000 0.000000 2.000000 1.000000 0 0 1 1 0   <removed-community-for-security> 12 0 0 0.0000



I have reviewed the Cisco ACE 4700 Series Appliance Administration Guide - Configuring SNMP document and read the "SNMP Limitations" which states "[i]f an SNMP MIB table has more than one string  index that contains more than 48 characters, the index may not appear in  the MIB table when you perform an SNMP walk. According to SNMP  standards, the SNMP requests, response, or traps cannot have more than  128 subidentifiers."


If that is the reason this doesn't work, could someone please more adequately explain the difference between querying the OperStatus versus the CurrConns when the OID I'm querying in each instance is the exact same length?  And is there anything that I could change in my configuration so that I can query connection information with SNMP?


If that documented SNMP limitation is not the reason that those particular queries fail, does anyone have any idea what the problem might be and/or next steps I should take in troubleshooting and resolving the issue?

Correct Answer by yushimaz about 6 years 11 months ago

Are you using snmp v1? If so, please try snmp v2.

The following is the test result in my lab.


### snmp v1


lin168:~# snmpget -c cdn -v 1 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17.1.3.115.118.49

Error in packet

Reason: (noSuchName) There is no such variable name in this MIB.

Failed object: SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49


### snmp v2

lin168:~# snmpget -c cdn -v 2c 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17.1.3.115.118.49

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49 = Counter64: 251118


snmpwalk also works with snmp v2 as below.



lin168:~# snmpwalk -c cdn -v 2c 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49 = Counter64: 251118

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.50 = Counter64: 0

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.11.65.86.83.45.82.83.69.82.86.69.82 = Counter64: 0

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.12.65.86.83.45.82.82.83.69.82.86.69.82 = Counter64: 0

lin168:~#



ACE4710/Admin# show rserver


rserver              : sv1, type: HOST

state                : OPERATIONAL (verified by arp response)

---------------------------------

                                                ----------connections-----------

       real                  weight state        current    total

   ---+---------------------+------+------------+----------+--------------------

   serverfarm: sf

       192.168.222.20:0      8      OPERATIONAL  0          251118


rserver              : sv2, type: HOST

state                : OPERATIONAL (verified by arp response)

---------------------------------

                                                ----------connections-----------

       real                  weight state        current    total

   ---+---------------------+------+------------+----------+--------------------

   serverfarm: sf

       192.168.222.21:0      8      STANDBY      0          0



If you use snmp v1, the behavior looks expected since syntax is not convertable to SMIv1 as below.

It means you have to use snmp v2 if you want to get Total, Failed, and CurrConns MIBs.



### snmp v1 mib


cesRserverTotalConns OBJECT-TYPE

    SYNTAX --?? syntax is not convertable to SMIv1

           Counter

--  Units

--    connections

    ACCESS read-only

    STATUS mandatory

    DESCRIPTION

        "The total number of connections loadbalanced to

        this real server."

    ::= { cesRserverEntry 17 }

ftp://ftp.cisco.com/pub/mibs/v1/CISCO-ENHANCED-SLB-MIB-V1SMI.my



### snmp v2 mib


cesRserverTotalConns OBJECT-TYPE

    SYNTAX          Counter64

    UNITS           "connections"

    MAX-ACCESS      read-only

    STATUS          current

    DESCRIPTION

        "The total number of connections loadbalanced to

        this real server."

    ::= { cesRserverEntry 17 }

ftp://ftp.cisco.com/pub/mibs/v2/CISCO-ENHANCED-SLB-MIB.my



Regards,

Yuji

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
yushimaz Mon, 08/23/2010 - 20:30
User Badges:
  • Cisco Employee,

Are you using snmp v1? If so, please try snmp v2.

The following is the test result in my lab.


### snmp v1


lin168:~# snmpget -c cdn -v 1 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17.1.3.115.118.49

Error in packet

Reason: (noSuchName) There is no such variable name in this MIB.

Failed object: SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49


### snmp v2

lin168:~# snmpget -c cdn -v 2c 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17.1.3.115.118.49

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49 = Counter64: 251118


snmpwalk also works with snmp v2 as below.



lin168:~# snmpwalk -c cdn -v 2c 1.164.0.51 .1.3.6.1.4.1.9.9.470.1.1.1.1.17

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.49 = Counter64: 251118

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.3.115.118.50 = Counter64: 0

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.11.65.86.83.45.82.83.69.82.86.69.82 = Counter64: 0

SNMPv2-SMI::enterprises.9.9.470.1.1.1.1.17.1.12.65.86.83.45.82.82.83.69.82.86.69.82 = Counter64: 0

lin168:~#



ACE4710/Admin# show rserver


rserver              : sv1, type: HOST

state                : OPERATIONAL (verified by arp response)

---------------------------------

                                                ----------connections-----------

       real                  weight state        current    total

   ---+---------------------+------+------------+----------+--------------------

   serverfarm: sf

       192.168.222.20:0      8      OPERATIONAL  0          251118


rserver              : sv2, type: HOST

state                : OPERATIONAL (verified by arp response)

---------------------------------

                                                ----------connections-----------

       real                  weight state        current    total

   ---+---------------------+------+------------+----------+--------------------

   serverfarm: sf

       192.168.222.21:0      8      STANDBY      0          0



If you use snmp v1, the behavior looks expected since syntax is not convertable to SMIv1 as below.

It means you have to use snmp v2 if you want to get Total, Failed, and CurrConns MIBs.



### snmp v1 mib


cesRserverTotalConns OBJECT-TYPE

    SYNTAX --?? syntax is not convertable to SMIv1

           Counter

--  Units

--    connections

    ACCESS read-only

    STATUS mandatory

    DESCRIPTION

        "The total number of connections loadbalanced to

        this real server."

    ::= { cesRserverEntry 17 }

ftp://ftp.cisco.com/pub/mibs/v1/CISCO-ENHANCED-SLB-MIB-V1SMI.my



### snmp v2 mib


cesRserverTotalConns OBJECT-TYPE

    SYNTAX          Counter64

    UNITS           "connections"

    MAX-ACCESS      read-only

    STATUS          current

    DESCRIPTION

        "The total number of connections loadbalanced to

        this real server."

    ::= { cesRserverEntry 17 }

ftp://ftp.cisco.com/pub/mibs/v2/CISCO-ENHANCED-SLB-MIB.my



Regards,

Yuji

9ball Mon, 08/23/2010 - 22:04
User Badges:

Aha, that was it.  Thank you very much.

Actions

This Discussion

Related Content