Just to get this straight, you are seeing the traffic drop off when it is supposed to be peaking?
If this is the case, it is likely because you are using the standard 32 bit counters (ifInOctets=1.3.6.1.2.1.2.2.1.10,ifOutOctets=1.3.6.1.2.1.2.2.1.16) The problem you are seeing is likely due to the 32 bit counters "wrapping" more than once during the polling interval. This means the counters reset and start at zero. When the counter Delta is calculated, it is incorrect. This is what you see this during high bandwidth periods. The solution to this is usually to use 64bit counters instead (ifHCInOctets=1.3.6.1.2.1.31.1.1.1.6, ifHCOUTOctets=1.3.6.1.2.1.31.1.1.1.10). These only generally available via SNMPv2. I don't know how you can easily change WhatsUp to use this with your existing graphs in whatsup. Regards, Mike Krygeris Plixer International, Inc, [EMAIL PROTECTED] 207-324-8805 _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roy Grubb Sent: Wednesday, September 19, 2007 9:56 AM To: [email protected] Subject: [WhatsUp Forum] SNMP issue with gathering bandwidth I'm aware of how SNMP calculates bandwidth using the In and Out Octet Oids; however, over the last few months my graphs have developed a problem as shown in the following link. http://cacti.conwaycorp.net/cacti/graph_image.php?local_graph_id=130 <http://cacti.conwaycorp.net/cacti/graph_image.php?local_graph_id=130&rra_id =0&view_type=tree&graph_start=1190123495&graph_end=1190209895> &rra_id=0&view_type=tree&graph_start=1190123495&graph_end=1190209895. At first I thought maybe SNMP performance or mis-reporting was happening because I verified everything in Cacti, but in the meantime, I've used a different SNMP graphing package to calculate bandwidth the same way and it works fine. Is there anyone that might have a fresh set of eyes for me?
<<image001.jpg>>
