The volume of NetFlow traffic?

I would like to know approximately what volume percentage gives NetFlow to the main flow and does it make sense to leave a separate physical cable from the switch to the second network card collector traffic (aka billing). Reading popular literature on these questions of answers did not bring. Probably somewhere in the depths of the docks zyskowski the answer is, but I have not found it yet. Please enlighten people in the know.
October 3rd 19 at 02:31

Related questions

More answers about "The volume of NetFlow traffic?"
5 answers
October 3rd 19 at 02:33
Solution
Depends on sampling.
Well, in General, does not depend on the volume of traffic and the number of packets/frames per second. - augustus77 commented on October 3rd 19 at 02:36
This calculators:
www.lancope.com/resource-center/netflow-bandwidth-calculator-stealthwatch-calculator/
www.plixer.com/Scrutinizer-Netflow-Sflow/netflow-bandwidth-calculator.html - augustus77 commented on October 3rd 19 at 02:39
Most importantly the number of threads.
But usually, if the disposal of the interfaces are not equal to 100% of the traffic *flow can be neglected. - chelsie_Emmerich commented on October 3rd 19 at 02:42
traffic Yes, but not loading the CPU. And what is "number of threads" I'm still not clear. - augustus77 commented on October 3rd 19 at 02:45
Switch *flow or Hardway or not.
Well, since netflow reports on mainly L4 connections (those threads), traffic netflow in the case of one session on a thousand pps will be much less than in the case of the ten sessions, a hundred pps. Although seemingly identical to the total pps.
Well, syn flood easily kill even a very powerful piece of metal with the awarding of software netflow :) - chelsie_Emmerich commented on October 3rd 19 at 02:48
so the flow or session? - augustus77 commented on October 3rd 19 at 02:51
And in this context to one another is not equal? - chelsie_Emmerich commented on October 3rd 19 at 02:54
October 3rd 19 at 02:35
A rough estimate from my own experience: 0.5%.
October 3rd 19 at 02:37
The netflow traffic is the main thread: if there are flies even many Gigabit, but flying one thread with a pair of address/port on one pair of src address/port dst, it will be quite a bit, and if there (mother-mother) a dozen mnogolopastnyj of torrentello of Siderov...

The cable throw is the meaning, not by the volume of traffic, and because if the thread on the main link reaches the limit of physics, the netflow to begin suddenly not fit - but rather, yet, will prevent the main thread.

But You see, what you want to get. Sometimes sample (sampling) is enough, especially as netflow in reality with "their moments" linked: for archival purposes it would be better full reports to be stored, but if the flows are large, and the nature of the turbulent traffic (torrents are the same), the store will have many. On the other hand, whether such is good, as the picture of the torrent, to keep very much in detail? Billing can count, and you still aggregatirovanie archive record will go, probably - and if so, maybe sampling on the sensor it will be possible to afford to include?
October 3rd 19 at 02:39
Antonvn says on the right. Was measured at one time on ~50 providers and clients, all about 0.5-1.5% of the traffic (measurement at 1 hour a day).
October 3rd 19 at 02:41
I have 10 Gbit/s of external traffic in CNN ~100Mbps netflow traffic.
Of course depends on how many fields you will export in flexible netflow these parameters can be set and reduce the load. Traditional netflow cisco is now not supported, it is not possible to appeal TAC with the problem.
Not long ago I settled the problem with the netflow traffic graphs began to rest on a shelf, in case of individual link of such a problem easier to diagnose.

Find more questions by tags Computer networksCiscoNetFlow