I'm trying to use the latest (stable) version of Cacti on our bigiron 8000. We have 3 gigabit ethernet interfaces that are being polled by Cacti for bandwidth (they are our uplinks.. )
However, The figures I am getting do -not- match the amount of data that is actively on the interfaces.
Example:
console on the 8000 shows around 600mbit/s (out) per gig-e port. Cacti reports a much, much lower number, around 50mbit (out). I've tried setting different polling options, but the number is always lower.
Any help would be very welcomed.
Using Cacti with a Foundry BigIron 8000
Moderators: Developers, Moderators
2 Things
1) Are you using the "Bits/sec" graphs not "bytes/sec" ?
2) Are you using the 64 Bit Counter option (Further down in the drop-down list of available graphs). Standard 32 Bit Interface Counters in SNMP V1 will only give a max of approx 114 mbit/s before the counter wraps round more than once inside a 5 min poll interval.
Deano
1) Are you using the "Bits/sec" graphs not "bytes/sec" ?
2) Are you using the 64 Bit Counter option (Further down in the drop-down list of available graphs). Standard 32 Bit Interface Counters in SNMP V1 will only give a max of approx 114 mbit/s before the counter wraps round more than once inside a 5 min poll interval.
Deano
-
gstanley
Yes, I'm using bits/sec. As for the other, no. Does it matter which SNMP version I'm using? (ie, I'm using v1 now, should I try v1+64bit counters or v2 with standard bits/sec)Deano wrote:2 Things
1) Are you using the "Bits/sec" graphs not "bytes/sec" ?
2) Are you using the 64 Bit Counter option (Further down in the drop-down list of available graphs). Standard 32 Bit Interface Counters in SNMP V1 will only give a max of approx 114 mbit/s before the counter wraps round more than once inside a 5 min poll interval.
Deano
Yes the version matters. the SNMP V1 standard only had 32-bit counters. V2 introduced 64 Bit counters but to avoid conflicts with the original standard they're different OIDs for interfaces. So you need to be using V2 and specify 64-bit counters.
The problem is caused by the fact the MIB actually reports not the Data rate but the actual number of bytes transferred. Cacti then does the rate calculation from that using the time between polls. with a 32 bit counter - the maximum number of recorded bytes is 2^32 or 429496729 which makes 34359738368 bits. Over 5 minutes that makes 114532461 bits/sec = 114 mbits/sec.
The first time the counter gets to max and resets to zero between polls it can be detected (new polled value < last polled value) and we assume its got to the maximum so compensate accordingly. If the rate of actuall traffic is therefore about 150 Mbits/sec we'll only see 36 mb/s as that is the apparent difference in the counters between 5 min polls.
With > 600 mbits/s of traffic the 32 bit counter has probably rolled over at least 5 times between polls - which is completely missed by Cacti (and any other s/w using the v1 interface counters)
Deano
The problem is caused by the fact the MIB actually reports not the Data rate but the actual number of bytes transferred. Cacti then does the rate calculation from that using the time between polls. with a 32 bit counter - the maximum number of recorded bytes is 2^32 or 429496729 which makes 34359738368 bits. Over 5 minutes that makes 114532461 bits/sec = 114 mbits/sec.
The first time the counter gets to max and resets to zero between polls it can be detected (new polled value < last polled value) and we assume its got to the maximum so compensate accordingly. If the rate of actuall traffic is therefore about 150 Mbits/sec we'll only see 36 mb/s as that is the apparent difference in the counters between 5 min polls.
With > 600 mbits/s of traffic the 32 bit counter has probably rolled over at least 5 times between polls - which is completely missed by Cacti (and any other s/w using the v1 interface counters)
Deano
-
gstanley
Great. I'm reconfiguring everything to see my real bandwidth stats. Thank you very much.Deano wrote:Yes - with a standard 5 min poll interval the V1 32 bit counters can only correctly handle traffic up to about 114 mbits/sec. For traffic levels above you need to use the V2 64 bit counters.
The problem is caused by the fact the MIB actually reports not the Data rate but the actual number of bytes transferred. Cacti then does the rate calculation from that. with a 32 bit counter - the maximum number of recorded bytes is 2^32 or 429496729 which makes 34359738368 bits. Over 5 minutes that makes 114532461 bits/sec = 114 mbits/sec.
The first time the counter gets to max and resets to zero between polls it can be detected (new polled value < last polled value) and we assume its got to the maximum so compensate accordingly. If the rate of actuall traffic is therefore about 150 Mbits/sec we'll only see 36 mb/s as that is the apparent difference in the counters between 5 min polls.
With > 600 mbits/s of traffic the 32 bit counter has probably rolled over at least 5 times between polls - which is completely missed by Cacti (and any other s/w using the v1 interface counters)
Deano
Cacti is a really wonderful tool. Thanks for putting all the effort into it.
*wonders if cacti can poll how much money I will spend for xmas*
-
Corbellari
- Posts: 1
- Joined: Fri Mar 17, 2006 2:36 pm
Re: Using Cacti with a Foundry BigIron 8000
Hi, I cant found the template for BigIron 8000.gstanley wrote:I'm trying to use the latest (stable) version of Cacti on our bigiron 8000. We have 3 gigabit ethernet interfaces that are being polled by Cacti for bandwidth (they are our uplinks.. )
However, The figures I am getting do -not- match the amount of data that is actively on the interfaces.
Example:
console on the 8000 shows around 600mbit/s (out) per gig-e port. Cacti reports a much, much lower number, around 50mbit (out). I've tried setting different polling options, but the number is always lower.
Any help would be very welcomed.
Someone help-me?
Who is online
Users browsing this forum: No registered users and 3 guests