-1

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 ?

unbesiegbar
  • 471
  • 2
  • 7
  • 19
  • Btw, what **Trafficbps** Element in http://www.iana.org/assignments/ipfix/ipfix.xhtml ? I can't find this or similar Element. So probably it's derived value, thus may be miscalculated. Can you try to catch actual netflow packet with Wireshark? – catpnosis Aug 10 '14 at 06:07

1 Answers1

0

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)

John Murphy
  • 397
  • 3
  • 14
  • Actually you are right, lets assume the bps values given are corrent as those are exported by a standard protocol. My doubt extends further. I have edited my question. Please suggest me on the Edit section. – unbesiegbar May 19 '14 at 18:42
  • The total bandwidth used is the "No of bytes" field, plus a little overhead. If Traffic bps is an average, then, the total bandwidth is roughly that times the duration of the session -- but they're probably arriving at that by dividing the byte count by the time in the first place. – John Murphy May 20 '14 at 17:22