Re: [Nfdump-discuss] pps and bps incorrect on Juniper j-flow | NFDUMP (original) (raw)

From: Andrew J. <aj...@jo...> - 2012-08-12 02:40:53
Hi Peter, Thanks for your response, I understand why what I've asked is not feasible. On page 6 of this document http://www.juniper.net/us/en/local/pdf/app-notes/3500204-en.pdf their active timeout is explained a little further, basically it seems like if a flow continues beyonf the active-timout period, the packet and byte counters are reset for that flow, and the flow is exported, but not removed from the flow table. It seems like Juniper's solution is what you have suggested, using aggregation to combine the flows and then looking at the bps and pps. It's a shame, in my opinion, that junos doesn't let you confgure the behaviour in that regard, because when wanting to look at flows in near real-time, rather than looking back over historical, completed flows, it would be nice to be able to get a snapshot of how much throughput each flow is doing in a given period. Thank you for all your work on nfdump/nfsen, they are great tools! Kind Regards, Andrew On Fri, 10 Aug 2012 22:38:22 +0200, Peter Haag <ph...@us...> wrote: > Hi Andrew, > Hmm .. this seems to be a bit confusing to me. As I understand the v9 spec, > it should be clear, that how to interpret tstart and tend of a flow. Is > there > a spec of Juniper, how to deal properly with these values? Your approach > seams > to be rather heuristic, although I understand the motivation. However, > there > is another problem: 'now' The collector does not save the collected time, > only > the flow reported time. bps and bps are calculated by nfdump at runtime. So > nfdump has no clue about 'now'. I'm afraid, that there is not much I could > do. > > What should help though, is aggregation. If you aggregate all flows of a > connection, the accumulated timestamps should be coeect, and therefore the > bps and pps. > > Regards > > - Peter > > On 10/8/12 9:29 AM, Andrew Jones wrote: >> Hi, >> Due to the way that juniper's jflow v9 implementation keeps the original >> start time of the exported flows, even with the active-timeout set to 60 >> seconds, nfdump's calculated pps and bps are incorrect. Is there a way to >> tell nfdump that all flows are exported every 60 seconds, so that pps and >> bps values are correct? >> >> Eg. if ( now - flow-start-time ) > 60 seconds { flow-life-time = 60 >> seconds } >> >> Any input is appreciated. >> Thanks, >> Andrew >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions >> will include endpoint security, mobile security and the latest in >> malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Nfdump-discuss mailing list >> Nfd...@li... >> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss >>

From: Andrew J. <aj...@jo...> - 2012-08-12 02:40:53

Hi Peter, Thanks for your response, I understand why what I've asked is not feasible. On page 6 of this document http://www.juniper.net/us/en/local/pdf/app-notes/3500204-en.pdf their active timeout is explained a little further, basically it seems like if a flow continues beyonf the active-timout period, the packet and byte counters are reset for that flow, and the flow is exported, but not removed from the flow table. It seems like Juniper's solution is what you have suggested, using aggregation to combine the flows and then looking at the bps and pps. It's a shame, in my opinion, that junos doesn't let you confgure the behaviour in that regard, because when wanting to look at flows in near real-time, rather than looking back over historical, completed flows, it would be nice to be able to get a snapshot of how much throughput each flow is doing in a given period. Thank you for all your work on nfdump/nfsen, they are great tools! Kind Regards, Andrew On Fri, 10 Aug 2012 22:38:22 +0200, Peter Haag <ph...@us...> wrote: > Hi Andrew, > Hmm .. this seems to be a bit confusing to me. As I understand the v9 spec, > it should be clear, that how to interpret tstart and tend of a flow. Is > there > a spec of Juniper, how to deal properly with these values? Your approach > seams > to be rather heuristic, although I understand the motivation. However, > there > is another problem: 'now' The collector does not save the collected time, > only > the flow reported time. bps and bps are calculated by nfdump at runtime. So > nfdump has no clue about 'now'. I'm afraid, that there is not much I could > do. > > What should help though, is aggregation. If you aggregate all flows of a > connection, the accumulated timestamps should be coeect, and therefore the > bps and pps. > > Regards > > - Peter > > On 10/8/12 9:29 AM, Andrew Jones wrote: >> Hi, >> Due to the way that juniper's jflow v9 implementation keeps the original >> start time of the exported flows, even with the active-timeout set to 60 >> seconds, nfdump's calculated pps and bps are incorrect. Is there a way to >> tell nfdump that all flows are exported every 60 seconds, so that pps and >> bps values are correct? >> >> Eg. if ( now - flow-start-time ) > 60 seconds { flow-life-time = 60 >> seconds } >> >> Any input is appreciated. >> Thanks, >> Andrew >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions >> will include endpoint security, mobile security and the latest in >> malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Nfdump-discuss mailing list >> Nfd...@li... >> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss >>

View entire thread

Want the latest updates on software, tech news, and AI?

Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.

Thanks for helping keep SourceForge clean.