Hi Robert,

I don't know the code, looking at it, at least I see that the webinterface pulls data from SQL. What I don't see in your poller output is that it is indeed doing an SQL update. So I guess that piece of code went missing... or I am confused.

Adam?

Tom

On 10/11/2012 15:34, Robert Williams wrote:

Hi,

 

Thanks - I just tried that and I found these relevant looking sections:

 

/usr/bin/snmpbulkwalk -v2c -c MyString -OQUs  -m CISCO-CAT6K-CROSSBAR-MIB -M /opt/observium/mibs udp:MyHost:161 cc6kxbarModuleModeTable

cc6kxbarModuleModeSwitchingMode.1 = dcefmode

cc6kxbarModuleModeSwitchingMode.2 = crossbarmode

cc6kxbarModuleModeSwitchingMode.3 = crossbarmode

cc6kxbarModuleModeSwitchingMode.5 = dcefmode

 

DEBUG: SNMP Auth options =  -v2c -c MyString

/usr/bin/snmpbulkwalk -v2c -c MyString -OQUs  -m CISCO-CAT6K-CROSSBAR-MIB -M /opt/observium/mibs udp:MyHost:161 cc6kxbarModuleChannelTable

cc6kxbarModuleChannelModStatus.1.0 = ok

cc6kxbarModuleChannelModStatus.1.1 = ok

cc6kxbarModuleChannelModStatus.2.0 = ok

cc6kxbarModuleChannelModStatus.3.0 = ok

cc6kxbarModuleChannelModStatus.5.0 = ok

cc6kxbarModuleChannelFabStatus.1.0 = ok

cc6kxbarModuleChannelFabStatus.1.1 = ok

cc6kxbarModuleChannelFabStatus.2.0 = ok

cc6kxbarModuleChannelFabStatus.3.0 = ok

cc6kxbarModuleChannelFabStatus.5.0 = ok

cc6kxbarModuleChannelSpeed.1.0 = 20000

cc6kxbarModuleChannelSpeed.1.1 = 20000

cc6kxbarModuleChannelSpeed.2.0 = 8000

cc6kxbarModuleChannelSpeed.3.0 = 8000

cc6kxbarModuleChannelSpeed.5.0 = 20000

 

DEBUG: SNMP Auth options =  -v2c -c MyString

/usr/bin/snmpbulkwalk -v2c -c MyString -OQUs  -m CISCO-CAT6K-CROSSBAR-MIB -M /opt/observium/mibs udp:MyHost:161 cc6kxbarStatisticsTable

cc6kxbarStatisticsInErrors.1.0 = 0

cc6kxbarStatisticsInErrors.1.1 = 0

cc6kxbarStatisticsInErrors.2.0 = 0

cc6kxbarStatisticsInErrors.3.0 = 0

cc6kxbarStatisticsInErrors.5.0 = 0

cc6kxbarStatisticsOutErrors.1.0 = 0

cc6kxbarStatisticsOutErrors.1.1 = 0

cc6kxbarStatisticsOutErrors.2.0 = 0

cc6kxbarStatisticsOutErrors.3.0 = 0

cc6kxbarStatisticsOutErrors.5.0 = 0

cc6kxbarStatisticsOutDropped.1.0 = 0

cc6kxbarStatisticsOutDropped.1.1 = 0

cc6kxbarStatisticsOutDropped.2.0 = 0

cc6kxbarStatisticsOutDropped.3.0 = 11

cc6kxbarStatisticsOutDropped.5.0 = 0

cc6kxbarStatisticsInUtil.1.0 = 3

cc6kxbarStatisticsInUtil.1.1 = 2

cc6kxbarStatisticsInUtil.2.0 = 0

cc6kxbarStatisticsInUtil.3.0 = 0

cc6kxbarStatisticsInUtil.5.0 = 0

cc6kxbarStatisticsOutUtil.1.0 = 2

cc6kxbarStatisticsOutUtil.1.1 = 3

cc6kxbarStatisticsOutUtil.2.0 = 0

cc6kxbarStatisticsOutUtil.3.0 = 0

cc6kxbarStatisticsOutUtil.5.0 = 0

cc6kxbarStatisticsPeakInUtil.1.0 = 50

cc6kxbarStatisticsPeakInUtil.1.1 = 51

cc6kxbarStatisticsPeakInUtil.2.0 = 15

cc6kxbarStatisticsPeakInUtil.3.0 = 6

cc6kxbarStatisticsPeakInUtil.5.0 = 5

cc6kxbarStatisticsPeakTmInUtil.1.0 = 2012-10-9,13:36:22.2,+0:0

cc6kxbarStatisticsPeakTmInUtil.1.1 = 2012-10-9,13:36:22.2,+0:0

cc6kxbarStatisticsPeakTmInUtil.2.0 = 2012-10-26,19:38:5.9,+0:0

cc6kxbarStatisticsPeakTmInUtil.3.0 = 2012-11-10,9:59:57.2,+0:0

cc6kxbarStatisticsPeakTmInUtil.5.0 = 2012-11-8,20:31:44.3,+0:0

cc6kxbarStatisticsPeakOutUtil.1.0 = 51

cc6kxbarStatisticsPeakOutUtil.1.1 = 50

cc6kxbarStatisticsPeakOutUtil.2.0 = 24

cc6kxbarStatisticsPeakOutUtil.3.0 = 3

cc6kxbarStatisticsPeakOutUtil.5.0 = 5

cc6kxbarStatisticsPeakTmOutUtil.1.0 = 2012-10-9,13:36:22.2,+0:0

cc6kxbarStatisticsPeakTmOutUtil.1.1 = 2012-10-9,13:36:22.2,+0:0

cc6kxbarStatisticsPeakTmOutUtil.2.0 = 2012-11-9,19:40:16.1,+0:0

cc6kxbarStatisticsPeakTmOutUtil.3.0 = 2012-11-10,14:20:13.9,+0:0

cc6kxbarStatisticsPeakTmOutUtil.5.0 = 2012-11-9,19:40:16.1,+0:0

 

/opt/observium/rrd/MyHost/c6kxbar-1-0.rrd OK u:0.00 s:0.00 r:3.46

RRD[[32mupdate /opt/observium/rrd/MyHost/c6kxbar-1-0.rrd N:3:2:0:0:0[0m] /opt/observium/rrd/MyHost/c6kxbar-1-1.rrd OK u:0.00 s:0.00 r:3.46

RRD[[32mupdate /opt/observium/rrd/MyHost/c6kxbar-1-1.rrd N:2:3:0:0:0[0m] /opt/observium/rrd/MyHost/c6kxbar-2-0.rrd OK u:0.00 s:0.00 r:3.46

RRD[[32mupdate /opt/observium/rrd/MyHost/c6kxbar-2-0.rrd N:0:0:0:0:0[0m] /opt/observium/rrd/MyHost/c6kxbar-3-0.rrd OK u:0.00 s:0.00 r:3.46

RRD[[32mupdate /opt/observium/rrd/MyHost/c6kxbar-3-0.rrd N:0:0:11:0:0[0m] /opt/observium/rrd/MyHost/c6kxbar-5-0.rrd OK u:0.00 s:0.00 r:3.46

RRD[[32mupdate /opt/observium/rrd/MyHost/c6kxbar-5-0.rrd N:0:0:0:0:0[0m]

SQL[SELECT * FROM `entPhysical_state` WHERE `device_id` = '32'] no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!no match!

including: includes/polling/applications.inc.php

SELECT * FROM `applications` WHERE `device_id`  = '32'

 

Is that of any use?

 

This device is currently showing zero for all 10 fabric items (5 ingress / 5 egress) on the bars, but has healthy values in the area graphs.

 

Cheers!

 

 


Robert Williams

Custodian DataCentre

email: Robert@CustodianDC.com


From: observium-bounces@observium.org [mailto:observium-bounces@observium.org] On Behalf Of Tom Laermans
Sent: 10 November 2012 14:24
To: observium@observium.org
Subject: Re: [Observium] 6500 Fabric Ingress/Egress scale

 

Hi,

Another possibility is that the database is not updated correctly.

The graph reads from the RRD file, which is filled by the poller after getting the value through SNMP.
Poller then also updates a MySQL table, which is used by the bar on the right.

Maybe the update query is failing? Try running the poller with -d and study/ send in the results. Be careful of snmp comms and the like in the output before emailing though.

Tom

On 10/11/2012 15:20, Robert Williams wrote:

Hi John,

 

Thanks for that, I can confirm that all chassis have either 720-3B or 720-3BXL sups in them. They are all in 65xx–E chassis also if that helps.

 

I’m pretty sure the area graph is showing the data correctly but the bar to the right is just under-reading I think? It’s that which made me wonder if the bar uses a different SNMP value to the graph? Or if it’s applying some sort of scaling factor to the data before populating the bar?

 

Cheers!

 

 

Robert Williams

Custodian DataCentre

email: Robert@CustodianDC.com

 

From: observium-bounces@observium.org [mailto:observium-bounces@observium.org] On Behalf Of John Macleod
Sent: 10 November 2012 14:13
To: Observium Network Observation System
Subject: Re: [Observium] 6500 Fabric Ingress/Egress scale

 

Robert,

 

Are all of your Cats running the same supervisor model?

 

I haven't looked into this, but the same physical cross bar bus speed increments as the Sup revision increases, now to 720Gbps.  The original spec on 6500s put this at 256Gbps and it was noted in docs that while being 256Gbps in capacity there wasn't a Sup capable at launch of using the bus at this capacity.

 

I recall a sales meeting with Cisco on this very point where their presentation had 256Gbps all over it but the Sups available couldn't use it.  Back then it was also quoted at duplex capacity that's probably still the case.

 

The MIB could be basing it on max-capacity even though the Sup's capacity to the bus is lower.  I would need to check how the MIB reports this.

On 10 Nov 2012, at 14:45, "Robert Williams" <Robert@CustodianDC.com> wrote:

Hi Guys,

 

Firstly, apologies for the screen-shots / attachments, but they are required to demonstrate the oddness…

 

I think there is a scaling issue on (or I’m not understanding) the Fabric load bars for the Catalyst 6k.

 

In short, the load bars (to the right of the mini-graph) always seem to show zero, or near zero, even though load is not zero. Example below or attached (or missing, depending on how this list handles images J)

 

<image003.png>

 

All bars are showing 2% Ingress and 1% Egress.

 

Below is a zoomed in version of the graphic for Slot 1 Fabric 0:

 

<image002.png>

 

 

This shows ingress is 4% and egress is 2% right now.

 

Load is quite low at the moment so it’s not an excellent example I agree - but I can honestly say that even when it’s high the most I see on those bars is 2%.

 

So, am I being stupid (quite possible) and these bars mean something else or is there some sort of issue with them or their maths?

 

We have 11 of these chassis, and I’ve checked them all. They all either show zero or are reading 1 or 2% despite having much higher real loads.

 

Such as this one:

 

<image001.png>

 

Maybe if anyone else can check their bars and let me know if it’s just me?

 

Cheers!

 

Robert Williams

Custodian DataCentre

email: Robert@CustodianDC.com

 

<ATT00001.c>




_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium

 



_______________________________________________
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium