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.
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. <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...
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 :)
Best regards, Denys
Avi Freedman | Your flow has something to show you; can you see it? | CEO, CloudHelix | (avi at cloudhelix dot com) | my name one word on skype |
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
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 license, or to purchase server.
Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2): http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-c... I am not aware of any vendor requiring an additional license to enable sFlow. sFlow (packet sampling) works extremely well for the DDoS flood detection / mitigation use case. The measurements are build into low cost commodity switch hardware and can be enabled operationally without adversely impacting switch performance. A flood attack generates high packet rates and sampling a 10G port at 1-in-10,000 will reliably detect flood attacks within seconds. For most use cases, it is much less expensive to use switches to perform measurement than to attach taps / mirror port probes. If your switches don't already support sFlow, you can buy a 10G capable white box switch for a few thousand dollars that will let you monitor 1.2 Terabits/sec. If you go with an open platform such as Cumulus Linux, you could even run your DDoS mitigation software on the switch and dispense with the external server. Embedded instrumentation is simple to deploy and reduces operational complexity and cost when compared to add on probe solutions. Peter Phaal InMon Corp.
On 2014-11-21 18:41, Peter Phaal wrote:
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 license, or to purchase server.
Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2):
http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-c...
I am not aware of any vendor requiring an additional license to enable sFlow.
sFlow (packet sampling) works extremely well for the DDoS flood detection / mitigation use case. The measurements are build into low cost commodity switch hardware and can be enabled operationally without adversely impacting switch performance. A flood attack generates high packet rates and sampling a 10G port at 1-in-10,000 will reliably detect flood attacks within seconds.
For most use cases, it is much less expensive to use switches to perform measurement than to attach taps / mirror port probes. If your switches don't already support sFlow, you can buy a 10G capable white box switch for a few thousand dollars that will let you monitor 1.2 Terabits/sec. If you go with an open platform such as Cumulus Linux, you could even run your DDoS mitigation software on the switch and dispense with the external server. Embedded instrumentation is simple to deploy and reduces operational complexity and cost when compared to add on probe solutions.
Peter Phaal InMon Corp. Wow, that's great news then, i'm using mostly Cisco gear now, but seems will have to take a look to Juniper, thanks for information. If it is free, then if EX2200 available, it is much easier to run sFlow and write custom collector for it, than installing custom probe(in most common cases).
--- Best regards, Denys
pmacct includes sfacctd which is an sflow collector.. Accessible via the same methods as it's nfacctd collector or pcap based collector.. -- Tim On Fri, Nov 21, 2014 at 9:06 AM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
On 2014-11-21 18:41, Peter Phaal wrote:
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 license, or to purchase server.
Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2):
http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-c...
I am not aware of any vendor requiring an additional license to enable sFlow.
sFlow (packet sampling) works extremely well for the DDoS flood detection / mitigation use case. The measurements are build into low cost commodity switch hardware and can be enabled operationally without adversely impacting switch performance. A flood attack generates high packet rates and sampling a 10G port at 1-in-10,000 will reliably detect flood attacks within seconds.
For most use cases, it is much less expensive to use switches to perform measurement than to attach taps / mirror port probes. If your switches don't already support sFlow, you can buy a 10G capable white box switch for a few thousand dollars that will let you monitor 1.2 Terabits/sec. If you go with an open platform such as Cumulus Linux, you could even run your DDoS mitigation software on the switch and dispense with the external server. Embedded instrumentation is simple to deploy and reduces operational complexity and cost when compared to add on probe solutions.
Peter Phaal InMon Corp.
Wow, that's great news then, i'm using mostly Cisco gear now, but seems will have to take a look to Juniper, thanks for information. If it is free, then if EX2200 available, it is much easier to run sFlow and write custom collector for it, than installing custom probe(in most common cases).
--- Best regards, Denys
Thanks! Most important there is plugin API,so it is easy to write custom code to do some analysis and on events - actions. On 2014-11-21 20:32, Tim Jackson wrote:
pmacct includes sfacctd which is an sflow collector.. Accessible via the same methods as it's nfacctd collector or pcap based collector..
-- Tim
On Fri, Nov 21, 2014 at 9:06 AM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
On 2014-11-21 18:41, Peter Phaal wrote:
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 license, or to purchase server.
Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2):
http://www.juniper.net/techpubs/en_US/junos11.2/information-products/topic-c...
I am not aware of any vendor requiring an additional license to enable sFlow.
sFlow (packet sampling) works extremely well for the DDoS flood detection / mitigation use case. The measurements are build into low cost commodity switch hardware and can be enabled operationally without adversely impacting switch performance. A flood attack generates high packet rates and sampling a 10G port at 1-in-10,000 will reliably detect flood attacks within seconds.
For most use cases, it is much less expensive to use switches to perform measurement than to attach taps / mirror port probes. If your switches don't already support sFlow, you can buy a 10G capable white box switch for a few thousand dollars that will let you monitor 1.2 Terabits/sec. If you go with an open platform such as Cumulus Linux, you could even run your DDoS mitigation software on the switch and dispense with the external server. Embedded instrumentation is simple to deploy and reduces operational complexity and cost when compared to add on probe solutions.
Peter Phaal InMon Corp.
Wow, that's great news then, i'm using mostly Cisco gear now, but seems will have to take a look to Juniper, thanks for information. If it is free, then if EX2200 available, it is much easier to run sFlow and write custom collector for it, than installing custom probe(in most common cases).
--- Best regards, Denys
--- Best regards, Denys
participants (4)
-
Denys Fedoryshchenko -
freedman＠freedman.net -
Peter Phaal -
Tim Jackson