Netflow gives absurd values in bps

563 Views Asked by At

I have been using netflow to collect n/w data and dumped it into my db.

Netflow gives me NoOfBytes transfered as well as Traffic speed (bps). But, there seems to be inconsistency between this.

My formula to calculate bps is :

(NoOfBytes * 8) / (end_time - start_time) sec

But, this doesnt hold for the records which I have received in netflow.

Here are some records from my DB.

*************************** 1. row ***************************
   LinkID: 128
 Protocol: 6
 SourceIP: 10.1.0.236 
 DestinationIP:  10.36.35.190 
 SourcePort: 80
 DestPort: 4930
 NoOfBytes: 783
 insertTime: 2013-08-05 00:03:21
 StartTime: 2013-08-05 00:00:43
 EndTime: 2013-08-05 00:00:44
 Trafficbps: 92117

*********************** 2. row ***********************

 LinkID: 128
 Protocol: 6
 SourceIP:10.1.0.236 
 DestinationIP:10.36.35.190 
 SourcePort: 80
 DestPort: 4916
 NoOfBytes: 783
 insertTime: 2013-08-05 00:00:49
 StartTime: 2013-08-04 23:58:09
 EndTime: 2013-08-04 23:58:10
 Trafficbps: 78300

In the above rows, we can see that the NoOfBytes transferred is very less that what is shown in Trafficbps. Can anyone explain me the concept please ?

EDIT

As per the suggestion from below comment by JMurphy, let me assume the bps values to be correct.

Now my doubt is, suppose a collect data for a span of 5 minuted and collect all the flows. Here, what would be the total bandwidth utilized ?

Would it be the sum of all bps or the max of all bps or the average of them ?

1

There are 1 best solutions below

2
On

Are you dividing by 1 second, by any chance? The records you're showing only have one second precision, but the actual sessions are likely to be much shorter than that. That looks like internal-to-internal traffic to me, so I wouldn't be surprised if the actual times are on the order of a few milliseconds.

Your device may also not be terribly accurate at measuring throughput in such short sessions, especially if those are single-packet communications, just because of the coarseness of its own timing.

Now, that's just going on the two examples you gave. If you're seeing other instances where much longer sessions don't match up to their Traffic bps, then I'd have to rethink things (though in that case I would probably ask whether Tbps is an average or max indicator)