Netflow is stateful stuff, and just to run it on wirespeed, on hardware, you need to utilise significant part of TCAM,
Cisco ASRs and MXs with inline jflow can do hundreds of K flows/second without affecting packet forwarding. Yes, i agree,those are good for netflow, but when they already exist in network. Does it worth to buy ASR, if L3 switch already doing the job (BGP/ACL/rate-limit/routing)?
i am not talking that on some hardware it is just impossible to run it. So everything about netflow are built on assumption that hosting or ISP can run it. And based on some observations, majority of small/middle hosting providers are using minimal,just BGP capable L3 switch as core, and cheapest but reliable L2/L3 on aggregation, and both are capable in best case to run sampled sFlow.
Actually, sFlow from many vendors is pretty good (per your points about flow burstiness and delays), and is good enough for dDoS detection. Not for security forensics, or billing at 99.99% accuracy, but good enough for traffic visibility, peering analytics, and (d)DoS detection. Well, if it is available, except hardware limitations, there is second obstacle, software licensing cost. On latest JunOS, for example on EX2200, you need to purchase license (EFL), and if am not wrong it is $3000 for 48port units. So if only sFlow feature is on stake, it worth to think, to purchase
On 2014-11-21 06:45, freedman@freedman.net wrote: license, or to purchase server. Prices for JFlow license on MX, just for 5/10G is way above cost of very decent server.
<snip>
So for a small hosting(up to 10G), i believe, FastNetMon is best solution. Faster, and no significant investments to equipment. Bigger hosting providers might reuse their existing servers, segment the network, and implement inexpensive monitoring on aggregation switches without any additional cost again.
It can be useful to have a 10G network monitoring box of course...
And with the right setup you can run FastNetMon or other tools in addition to generating flow that can be of use for other purposes as well...
Technically there is ipt_NETFLOW, that can generate netflow on same box, for statistical/telemetry purposes. But i am not sure it is possible to run them together.
Ah, and there is one more huge problem with netflow vs FastNetMon - netflow just by design cannot be adapted to run pattern matching, while it is trivial to patch FastNetMon for that, turning it to mini-IDS for free.
It's true, having a network tap can be useful for doing PCAP-y stuff.
But taps can be difficult or at least time consuming for people to put in at scale. Even, we've seen, for folks with 10G networks. Often because they can get 90% of what they need for 4 different business purposes from just flow :)
About scaling, i guess it depends on proper deployment strategy and sysadmins/developers capabilities. For example to deploy new ruleset for my pcap-based "homemade" analyser to 150 probes across the country - is just one click. --- Best regards, Denys