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

Dear Yanagibashi-san,

Thank you for your comments.

It sounds like you are referring to "Sampled-NetFlow" as implemented in
Juniper and some Cisco routers. This is where the flow-cache is driven
from 1-in-N sampled packets, instead of every packet. Am I right?

The primary reason that sFlow is more scalable than NetFlow is that
sFlow is "stateless". Keeping state (i.e. the NetFlow flow-cache) on
the router limits scalability in a number of ways:

1. The NetFlow agent needs an indeterminate amount of RAM to hold the
flow-cache. CPU is required to walk the flow-cache and flush expired
flows. In a layer-2 switch, extra work is required to decode the
TCP/IPv4 fields from each packet. An sFlow agent has no cache and
requires no decode, so none of this work is needed.

2. If a NetFlow UDP packet is lost in transit (either on outgoing
socket, in transit across network, or at incoming socket on collector)
then you may have lost as little as one DNS lookup flow (1 packet), or
you may have lost several 1GB file transfers. There is no way to know.
  Some people advocate running NetFlow over TCP or SCTP to address this
problem, but that raises further scalability issues. In contrast,
sFlow is tolerant to packet loss. The effect is equivalent to
adjusting the sampling rate from, say, 1-in-256 to 1-in-257. For
sFlow, UDP is preferred.

3. At a NetFlow collector, there is extra work to do if the flows are
to be collected into time-interval bins in order to construct a traffic
matrix for each minute or each hour. This is because the flows may be
delayed for several minutes on the router, and are reported with a
start-time and end-time which may span several minutes. With sFlow the
information is delivered as it happens, reducing complexity in the
collector and making more real-time applications possible.

And for all this extra work, NetFlow still only gives you data for
TCP/IPv4. If you want to know about other protocols that may be
running, NetFlow gives you no information. On the other hand, sFlow
allows the protocol decoding to be done on the collector. This means
you can choose to extract information about, say, TCP/IPv4, IPv6, IPX,
AppleTalk, DecNet, Ethernet, ARP, VLAN and MPLS. You can even look for
RTP (Voice-over-IP) traffic and worm-virus signatures. To monitor a
new protocol, you do not need to change the firmware on the
switch/router.

Finally, if you want to collect all the interface counters, sFlow
will deliver them to you in an efficient, binary format. In a NetFlow
system you have to poll for them with SNMP, which can be a significant
scalability problem in a large network. Sometimes it can also be a
security problem, because some network operators prefer not to enable
SNMP access to their routers.

I agree with you that Sampled-NetFlow has some scalability advantages
over NetFlow, but when you consider the task of monitoring a whole
network of switches and routers, sFlow still has many advantages.

I hope this answers your question?

regards,
neil

On Nov 28, 2004, at 11:28 PM, Tatsuya Yanagibashi wrote:

> Neil,
>
> The whitepaper you introduced below says "SFlow is scalable". Is
> there any implication, in this statement, of which it will be valid
> when it compares to NetFlow? Technically either of NetFlow or SFlow
> doesn't exactly specify how to gather(sample) those information
> in the router/swicth, thus it simply relies on their
> implementation....in other words, most likely similar mechanism
> will be used...I think.
>
> Therefore, I think there shouldn't be so much big difference
> between SFLow and NetFlow in terms of scalability aspect. Correct?
>
> Thanks and regards,
> Tatsuya
>
>>> All,
>>>
>>> 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:
>> http://www.inmon.com/PDF/sFlowOverview.pdf
>
> --
> Tatsuya Yanagibashi <tyanagibashi@mbc.ocn.ne.jp>
>
>

----
Neil McKee
InMon Corp.
http://www.inmon.com