Graphs not working over 400MB of traffic

[ptera]

Can some one point me in the direction to fix graphs that struggle to display traffic above 500MB - Seems when traffic is below 400MB it works fine - between 400MB and 500MB the graph shows missing data points - over 500MB and graph displays the difference after subtracting 500MB from the total traffic.

Thanks

[ptera]

Here is the graph displayed

[ptera]

Another related problem

Not only does this mess up the graphs but it generates not a few events for each port on each device.
Example...
2014-10-31 14:31:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion Warning 26m 26s Yes (1) -
2014-10-31 14:31:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion High 26m 26s Yes (1) -
2014-10-31 14:28:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion Warning 29m 26s Yes (1) -
2014-10-31 14:28:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion High 29m 26s Yes (1) -
2014-10-31 14:25:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion OK Warning 3m Yes (1) -
2014-10-31 14:25:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion OK High 3m Yes (1) -
2014-10-31 14:25:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion OK Warning 6m Yes (1) -
2014-10-31 14:24:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion OK High 7m Yes (1) -
2014-10-31 14:23:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion PROBLEM Warning 2m Yes (1) -
2014-10-31 14:23:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion PROBLEM High 2m Yes (1) -
2014-10-31 14:23:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion PROBLEM Warning 2m Yes (1) -
2014-10-31 14:23:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion PROBLEM High 1m Yes (1) -
2014-10-31 14:22:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion OK Warning 1m Yes (1) -
2014-10-31 14:22:08 .CET-BGP.ptera.net Interface GigabitEthernet0/2 Outbound Congestion OK High 1m Yes (1) -
2014-10-31 14:22:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion OK Warning 1m Yes (1) -
2014-10-31 14:22:08 .CET-BGP.ptera.net Interface GigabitEthernet0/1 Inbound Congestion OK High 1m Yes (1) -

[ptera]

Really?

No one using this software has links over 500MB?

[kloczek]

Can some one point me in the direction to fix graphs that struggle to display traffic above 500MB - Seems when traffic is below 400MB it works fine - between 400MB and 500MB the graph shows missing data points - over 500MB and graph displays the difference after subtracting 500MB from the total traffic.

Thanks

Are these counters used to calculate speed using delta per sec are read over SNMP? If yes. Are you using 32bit counters from ifInOctets/ifOutOctets OIDs from IF MIB or from the same MIB ifHCInOctets/ifHCOutOctets OIDs (64bit counters) ? Are you using SNMPv1 or SNMPv2?

I have a hundredths even 10GB interfaces and I see on a lot of them much higher speed.

You need to tell a little more what and how you are monitoring.

[ptera]

So I am not sure I can answer all your questions since these were created from the Template SNMP Network Device Interfaces.
The Application Item of the Template says SNMPv2 agent
I looked around and could not find any place telling me about which counters are being used or how to change them.

[kloczek]

So I am not sure I can answer all your questions since these were created from the Template SNMP Network Device Interfaces.
The Application Item of the Template says SNMPv2 agent
I looked around and could not find any place telling me about which counters are being used or how to change them.

snmpget/snmpwalk output shows type of OID data.

[ptera]

SNMPwalk

Ok so I checked and the cisco is returning 32bit counters.
So this is a no go?
Funny how PRTG and Dude seem to work properly with these numbers.

[ptera]

That is a shame

I had hoped that this could replace our PRTG - bummer

[ptera]

Money?

So is this one of things that we need to pay money to get fixed?

[aib]

So is this one of things that we need to pay money to get fixed?

Nope.
It means that you have to do something manually

1) Read the article from CISCO with explanation about 64bit counters.

http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/26007-faq-snmpcounter.html

2) Clone "Template SNMP Network Device Interfaces." to "Template SNMP Network Device 64bit Interfaces."
3) In new template go to Discovery Rules -> Network Interfaces -> Item Prototypes and change Keys for "Incoming traffic" and "Outgoing traffic"

old key: IF-MIB::ifInOctets.{#SNMPINDEX}
NEW KEY: IF-MIB::ifHCInOctets.{#SNMPINDEX}

4) Link new "Template SNMP Network Device 64bit Interfaces." to your Network device and let him create freshly discovered interfaces.
5) Keep an eye on new graphs for a couple of day and report back to the forum how it works.

Clear?

[ptera]

Clear

Everything was there to work with except I did have to look up how to disable version one snmp. Will report back after a couple of days for the long term results of the fix.

Thanks for the updated MIBs to use - I did not pay attention to In vs Out on the keys but figured that one out when my in and outs tracked together.

[ptera]

In/Out Bound Congestion

These may be related to this same issue - I get Interface Congestion warnings for gig interfaces with only 200-300 M of traffic. Even using the Cloned template that now properly graphs the bandwidth usage.

Do I need to make a similar MIB change like we needed for the in/out keys?

[ptera]

Money?

So is "this" one of things that we need to pay money to get fixed?

[ptera]

In/Out Bound Congestion trigger

8*{Template SNMP Network Device 64bit Interfaces:ifInOctets[{#SNMPVALUE}].last()}/{Template SNMP Network Device 64bit Interfaces:ifSpeed[{#SNMPVALUE}].last()}>0.8

This triggers warning and high on every interface even when it is not over 80%.
200M on a gig interface is not 80%

Is there anything that can be added to the Name of the trigger to get it to show the {Template SNMP Network Device 64bit Interfaces:ifInOctets[{#SNMPVALUE}].last()} in the name similar to how {HOST.NAME} displays the name of the host?

This would help in figuring out why the math for these interfaces does not work.