Re: paper needed on specific differences in NetFlow vs. sFlow..

From: Neil McKee (
Date: 02/08/02

  • Next message: Sean O'Neill: "Anything similar to ARGUS for sFlow ?"

    Chance Whaley wrote:

    >Customers are asking for some information that specifically shows the
    >differences in sFlow vs. NetFlow. When, where, and why sFlow should be used, in
    >comparison with NetFlow.
    In many situations NetFlow is OK. It provides a stream of aggregated IP
    flow records. As long as the router can generate this data comfortably
    (and the collector can consume it comfortably), then there is no reason
    to avoid it.

    At higher speeds, however, we have seen that some routers are not so
    comfortable generating detailed records (NetFlow version 5). With
    NetFlow version 8,9 the router can be configured to aggregate more
    heavily. This might be acceptable for a specific billing solution, but
    then you lose the granularity of detail that you need for operational
    tasks like congestion management, troubleshooting and security monitoring.

    Others prefer sFlow because they need visibility at layer-2 (MAC
    addresses, VLAN ids) or detailed BGP AS-Path data (or IPX, or IPv6...).

    Being able to enable monitoring on all ports at no extra cost has
    advantages too. It's much easier to trace problems to their source if
    every link in the network is giving you application-layer flows and
    interface counters all the time. With sFlow a network-wide, end-end
    view of L2-L7 traffic can be built by a single collector.

    For a more detailed comparison, see InMon Corp.'s white paper:

    >People are also bringing up the fact that cflowd is free and in mass deployment
    >in a large number of SP networks. Do we know if the cflowd people are looking at
    >adding sFlow to their "to do" list? What are the specific reasons why moving to
    >sFlow will justify the migration to software that actually costs money?
    We have heard from a number of users who are considering moving to sFlow
    because of the greater visibility into network traffic patterns that it
    provides. There are also a number of free tools that currently support
    sFlow, for example ntop, sflowtool, snort, tcpdump. It would also be
    possible for cflowd to supports sFlow too, but I am not sure if there
    are any plans to do that.


    >Customers love the concept, but are asking good questions. I would think that
    >the sFlow org, would be the people to answer these types of queries.

    Neil McKee, InMon Corp.
    tel: +1 (415) 661-6343

    This archive was generated by hypermail 2b29 : 02/08/02 EST