Burton,
a solution for my problem is as follows (which lead to the question why there
were values <> 0 in the netflow rrd graphs for upToxxx, index sometimes
wrong or are the values filled in but not in netflowPlugin.c?):
--- netflowPlugin.c.old 2004-02-29 16:23:19.235650363 +0100
+++ netflowPlugin.c 2004-02-29 16:26:01.000000000 +0100
@@ -558,20 +558,35 @@
}
myGlobals.device[actualDeviceId].receivedPkts.value += numPkts;
myGlobals.device[actualDeviceId].ethernetPkts.value += numPkts;
myGlobals.device[actualDeviceId].ipPkts.value += numPkts;
updateDevicePacketStats((u_int)len, actualDeviceId);
myGlobals.device[actualDeviceId].ethernetBytes.value += len;
myGlobals.device[actualDeviceId].ipBytes.value += len;
+ if (numPkts > 0) {
+ if (len/numPkts <= 64)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo64.value += numPkts;
+ else if (len/numPkts <= 128)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo128.value += numPkts;
+ else if (len/numPkts <= 256)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo256.value += numPkts;
+ else if (len/numPkts <= 512)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo512.value += numPkts;
+ else if (len/numPkts <= 1024)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo1024.value += numPkts;
+ else if (len/numPkts <= 1518)
+ myGlobals.device[actualDeviceId].rcvdPktStats.upTo1518.value += numPkts;
+ }
+
#ifdef CFG_MULTITHREADED
/* accessMutex(&myGlobals.hostsHashMutex, "processNetFlowPacket"); */
#endif
if(!skipSRC) {
switch((skipSRC = isOKtoSave(ntohl(record->srcaddr),
whiteNetworks, blackNetworks,
numWhiteNets, numBlackNets)) ) {
case 1:
_______________________________________
On Sunday 29 February 2004 15:12, Burton M. Strauss III wrote:
> I don't think so.
>
> First off, the rrd's themselves are 'averaged' - they're stored as rates
> (per second) on long (5 minute) intervals.
>
> Second, netFlows increment counters, but the counters are accumulated until
> the various intervals expire for calculating 2nd order items such as
> throughput.
>
> Read through handleV5Flow() in plugins/netFlowPlugin.c - follow the calls
> to updateTrafficMatrix() and updatePacketCount() - ultimately all that's
> done with netFlow input is calls to incrementTrafficCounter(). The two key
> items, numPkts = ntohl(record->dPkts); and len
> =(Counter)ntohl(record->dOctets); are pulled out of the flow.
>
> So - unless your netFlow collector is averaging over very long periods -
> minutes or hours - whether you report 10 flows of 1 packet or 1 flow of 10
> packets it's the same.
>
> (Internally, netFlow and sFlow are different - netFlow directly counts
> things, sFlow builds a fake packet and injects it into processPacket()).
>
> -----Burton
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> > Of Markus Rehbach
> > Sent: Saturday, February 28, 2004 10:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Ntop-dev] values in upToXYZPkts RRD graphs are too low
> > (about factor 10) (QDA9WTB?)
> >
> >
> > The frequency matters. Consider the case where a Netflow Emitter
> > is sending a
> > Netflow packet for every 'raw' packet it received. The value of
> > the packet
> > field in the netflow packet equals the packet size and is 100% correct.
> > Making the sampling time longer you will alway get the packet
> > size (packets/
> > bytes) averaged.
>
> _______________________________________________
> Ntop-dev mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
