Sorry but I could not understand what issues you've found in sflow. Could you describe they in details? Recently I had speech at RIPE 71 and show pattern of real attack which achieved 6 gbps in first 30 seconds (just check slide 6 here http://www.slideshare.net/pavel_odintsov/ripe71-fastnetmon-open-source-dos-d...). And sflow device could offer 3-4 seconds detection time from this case. But netflow __could__ delay telemetry up to 30 seconds (in case of huge syn/syn-ack flood for example) and you network will experience downtime. But with sflow you could detect and mitigate this attack in seconds. Is it make sense? On Mon, Feb 29, 2016 at 10:32 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 29 Feb 2016, at 14:26, Pavel Odintsov wrote:
From my own experience sflow should be selected if you are interested in internal packet payload (for dpi / ddos detection) or you need fast reaction time on some actions (ddos is best example).
This does not match my experience. In particular, the implied canard about flow telemetry being inadequate for timely DDoS detection/classification/traceback grows tiresome, as it's used for that purpose every day, and works quite well.
If one is also using an IDMS-type device to mitigate DDoS traffic, the device sees the whole packet, anyways.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>
-- Sincerely yours, Pavel Odintsov