Buy or Renew
Buy or Renew
NOTICE: You can now engage in the community. Learn about the great new Cisco Umbrella content.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2649
Views
0
Helpful
9
Replies

ACE snmpwalk not return values for CISCO-SLB-MIB

sannitigsan
Level 1
Level 1

‎06-14-2011 09:26 PM

Hi everyone,

I need some help with snmp for the ACE. I am unable to get any results when running an snmpwalk for the object slbVServerClientByteCounts.

In fact, I get no results for anything related to CISCO-SLB-MIB. I can run an snmp translate against this mib and I am able to get the OIDs but when I run an snmpwalk against the ACE I get nothing for this mibs. I do however get results for the mibs: SNMPv2-SMI, IF-MIB, IP-MIB etc..etc..

My main goal is to get the traffic going to the virtual server vip and then graph it. I need to use the CISCO-SLB-MIB to do this.

Can someone please help? I will try and answer your questions to the best of my knowledge.

Thank you.

Labels:
0 Helpful
9 Replies 9

sannitigsan
Level 1
Level 1

‎06-15-2011 12:36 AM

Is it possible that the ACE does not have this mib loaded onto it? I searched the "Mib Support and Software" section for my IOS c4710ace-mz.A3_2_5.bin and nothing came up. In fact, it came up invalid and I can not find any info on the ACE and the mibs that it supports...

yeesh, I've been at this for over 5 hours now. SNMP is supposed to be simple...that's what the 'S' is for!

0 Helpful

Daniel Arrondo Ostiz
Cisco Employee
Cisco Employee
In response to sannitigsan

‎06-15-2011 02:43 AM

Hi Daniel,

The CISCO-SLB-MIB is supported in A3.2.5, so, you should not have any problems polling data from that particular mib.

One thing to take into account is that this mib will only return the information for the context where it's being polled, so, make sure you are polling the context where the vservers are configured.

Another thing you can try is doing a snmpwalk on the full mib (

1.3.6.1.4.1.9.9.161) to confirm whether some other OIDs can be polled for that mib or not.

Regards

Daniel

0 Helpful

sannitigsan
Level 1
Level 1
In response to Daniel Arrondo Ostiz

‎06-15-2011 03:04 AM

Thank you for your reply!

"One thing to take into account is that this mib will only return the information for the context where it's being polled, so, make sure you are polling the context where the vservers are configured"

I'm sorry but I don't understand this part. The vservers are configured on the ACE and I'm polling the ACE's ip.

"Another thing you can try is doing a snmpwalk on the full mib (1.3.6.1.4.1.9.9.161) to confirm whether some other OIDs can be polled for that mib or not"

I did this and yes it came up with a lot more results. I did not know that an snmpwalk defaults to the mib-2 tree if you don't specify the oid start. There many results but one of the oids i wanted was not there (slbVServerIndex). This is marked as "not-accessible" on the cisco webpage. I need this oid so I can specify which vserver to monitor the traffic on. I am begning to think what I want to do is not possible.

0 Helpful

Daniel Arrondo Ostiz
Cisco Employee
Cisco Employee
In response to sannitigsan

‎06-15-2011 03:53 AM 

 "One thing to take into account is that this mib will only return the information for the context where it's being polled, so, make sure you are polling the context where the vservers are configured"
I'm sorry but I don't understand this part. The vservers are configured on the ACE and I'm polling the ACE's ip.

What I meant is that the ACE can have different contexts configured. In that situation, when doing the SNMP request, you need to do it against the IP address of the context where the vservers are configured. Once you do it, you should be able to poll the data.

Here is an example from my lab showing the snmpwalk on the vserver table (with 2 vservers configured):

root@ubuntu-server-1:~# snmpwalk -v 2c -c public 172.21.30.6 1.3.6.1.4.1.9.9.161.1.4

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.95 = STRING: "static_http"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.167 = STRING: "ftp"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.95 = STRING: "int530"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.167 = STRING: "int530"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.95 = INTEGER: 2

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.167 = INTEGER: 2

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.95 = STRING: "Operational"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.167 = STRING: "Operational"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.95 = Gauge32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.167 = Gauge32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.95 = Counter32: 364868

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.167 = Counter32: 248

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.95 = Counter32: 1

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.167 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.95 = Counter32: 2187381

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.167 = Counter32: 1306

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.95 = Counter32: 1457801

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.167 = Counter32: 1231

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.11.1.95 = Counter64: 134932830

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.11.1.167 = Counter64: 72023

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.12.1.95 = Counter64: 242218592

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.12.1.167 = Counter64: 764602

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.13.1.95 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.13.1.167 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.14.1.95 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.14.1.167 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.15.1.95 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.15.1.167 = Counter32: 0

And below, doing the same for only the slbVServerClientByteCounts OID:

root@ubuntu-server-1:~# snmpwalk -v 2c -c public 172.21.30.6 1.3.6.1.4.1.9.9.161.1.4.2.1.11

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.11.1.95 = Counter64: 134932830

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.11.1.167 = Counter64: 72023

0 Helpful

sannitigsan
Level 1
Level 1
In response to Daniel Arrondo Ostiz

‎06-15-2011 04:04 AM

Interesting, I think we only have one context here. (I'm thinking context like PIX contexts)

So is 172.21.30.6 the vip of the vserver? I ask this becuase the vip does not belong to us, we only manage the ACE and the vip is in a subnet which belongs to the customer. I am currently using the managment ip in my snmpwalk.

By the way, thank you for your help. I am getting a much better understanding of this.

0 Helpful

Daniel Arrondo Ostiz
Cisco Employee
Cisco Employee
In response to sannitigsan

‎06-15-2011 04:09 AM

In the example, 172.21.30.6 is the management IP of the ACE for the context where the vservers are configured.

If I try to use the same command on the Admin context (which in my case doesn't have any vservers), I would just get an empty result.

0 Helpful

sannitigsan
Level 1
Level 1
In response to Daniel Arrondo Ostiz

‎06-15-2011 04:34 AM

Ok I fully understand. I have verified that I have only one context (Admin).

Would you be able to explain why I am able to see some oid data and nothing for others? Your results for oid slbVServerClientByteCounts is exactly what I am looking for.

This is what I have:

snmpwalk  -v 2c -c xxxxx 172.16.14.100  1.3.6.1.4.1.9.9.161.1.4.2.1

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.39 = STRING: "Port80"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.40 = STRING: "Port100"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.41 = STRING: "Port1010"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.42 = STRING: "Port21"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.43 = STRING: "Port444"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.39 = STRING: "test"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.40 = STRING: "test"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.41 = STRING: "test"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.42 = STRING: "test"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.3.1.43 = STRING: "test"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.39 = INTEGER: 2

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.40 = INTEGER: 2

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.41 = INTEGER: 2

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.42 = INTEGER: 1

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.4.1.43 = INTEGER: 1

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.39 = STRING: "Operational"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.40 = STRING: "Operational"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.41 = STRING: "Operational"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.42 = STRING: "No Active serverfarm(s) in Policy"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.5.1.43 = STRING: "No Active serverfarm(s) in Policy"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.39 = Gauge32: 134

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.40 = Gauge32: 25

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.41 = Gauge32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.6.1.42 = Gauge32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.39 = Counter32: 510534985

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.40 = Counter32: 26901235

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.41 = Counter32: 86784

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.42 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.7.1.43 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.39 = Counter32: 128982

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.40 = Counter32: 3167

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.41 = Counter32: 7

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.42 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.8.1.43 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.39 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.40 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.41 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.42 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.9.1.43 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.39 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.40 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.41 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.42 = Counter32: 0

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.10.1.43 = Counter32: 0

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

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

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

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

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

0 Helpful

Daniel Arrondo Ostiz
Cisco Employee
Cisco Employee
In response to sannitigsan

‎06-15-2011 04:49 AM

Hi Daniel,

You are in fact getting results for all your vserves, but it's true that, the slbVServerClientByteCounts OID is returning 0 for each of the vservers:

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.39 = STRING: "Port80"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.40 = STRING: "Port100"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.41 = STRING: "Port1010"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.42 = STRING: "Port21"

SNMPv2-SMI::enterprises.9.9.161.1.4.2.1.2.1.43 = STRING: "Port444"

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

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

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

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

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

Assuming you have traffic going through the device, I find it very strange that all of the counters remain at 0. This looks to me like a software bug, so I would recommend you to check if the issue persists after upgrading to the latest version, and if it does, opening a TAC service request to have it investigated further.

Daniel

0 Helpful

sannitigsan
Level 1
Level 1
In response to Daniel Arrondo Ostiz

‎06-15-2011 04:53 AM

Thanks Daniel. I appriciate all of your help.

0 Helpful
Customers Also Viewed These Support Documents

Review Cisco Networking for a $25 gift card