6500 Fabric Ingress/Egress scale
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 :))
[cid:image003.png@01CDBF49.C8C03550]
All bars are showing 2% Ingress and 1% Egress.
Below is a zoomed in version of the graphic for Slot 1 Fabric 0:
[cid:image002.png@01CDBF48.A37B26C0]
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:
[cid:image001.png@01CDBF49.E3BFD450]
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
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>
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.commailto: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 ☺)
<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.commailto:Robert@CustodianDC.com
<ATT00001.c>
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 mailto: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 <mailto:Robert@CustodianDC.com> <ATT00001.c>
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
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.commailto:Robert@CustodianDC.com
From: observium-bounces@observium.orgmailto: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.commailto: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 :))
<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.commailto:Robert@CustodianDC.com
<ATT00001.c>
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
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 <mailto:Robert@CustodianDC.com> *From:*observium-bounces@observium.org <mailto: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 <mailto: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 <mailto:Robert@CustodianDC.com> <ATT00001.c> _______________________________________________ observium mailing list observium@observium.org <mailto: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
Well, you'll never guess what...
The code inserts the value into the database, and removes the value from the database when the module no longer exists.
But it never *updates* the value. Odd. I never noticed it before! I even know other people who *use* those counters and never noticed!
mea culpa, fix incoming. :)
adam.
On 10/11/2012 08: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 mailto: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 <mailto:Robert@CustodianDC.com> <ATT00001.c>
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
tada.wav ;-)
As I suspected \o/
On 10/11/2012 17:46, Adam Armstrong wrote:
Well, you'll never guess what...
The code inserts the value into the database, and removes the value from the database when the module no longer exists.
But it never *updates* the value. Odd. I never noticed it before! I even know other people who *use* those counters and never noticed!
mea culpa, fix incoming. :)
adam.
On 10/11/2012 08: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 mailto: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 <mailto: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
I almost always write code like this, to test that it works quickly before I finish it off.
This must have been written late in the evening and I forgot to finish it the next day :DDDDD
adam.
On 10/11/2012 10:47, Tom Laermans wrote:
tada.wav ;-)
As I suspected \o/
On 10/11/2012 17:46, Adam Armstrong wrote:
Well, you'll never guess what...
The code inserts the value into the database, and removes the value from the database when the module no longer exists.
But it never *updates* the value. Odd. I never noticed it before! I even know other people who *use* those counters and never noticed!
mea culpa, fix incoming. :)
adam.
On 10/11/2012 08: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 mailto: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 <mailto: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
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Hi,
Excellent thanks for that, glad you found it :)
Cheers guys!
Robert Williams
Custodian DataCentre
email: Robert@CustodianDC.com
From: observium-bounces@observium.org [mailto:observium-bounces@observium.org] On Behalf Of Adam Armstrong Sent: 10 November 2012 16:54 To: Observium Network Observation System Subject: Re: [Observium] 6500 Fabric Ingress/Egress scale
I almost always write code like this, to test that it works quickly before I finish it off.
This must have been written late in the evening and I forgot to finish it the next day :DDDDD
adam.
On 10/11/2012 10:47, Tom Laermans wrote: tada.wav ;-)
As I suspected \o/
On 10/11/2012 17:46, Adam Armstrong wrote: Well, you'll never guess what...
The code inserts the value into the database, and removes the value from the database when the module no longer exists.
But it never *updates* the value. Odd. I never noticed it before! I even know other people who *use* those counters and never noticed!
mea culpa, fix incoming. :)
adam.
On 10/11/2012 08: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.commailto:Robert@CustodianDC.com
From: observium-bounces@observium.orgmailto: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.commailto: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 :))
<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.commailto:Robert@CustodianDC.com
<ATT00001.c>
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (4)
-
Adam Armstrong -
John Macleod -
Robert Williams -
Tom Laermans