[154903] in North American Network Operators' Group
RE: Real world sflow vs netflow?
daemon@ATHENA.MIT.EDU (James Braunegg)
Mon Jul 16 18:02:18 2012
From: James Braunegg <james.braunegg@micron21.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Mon, 16 Jul 2012 22:01:14 +0000
In-Reply-To: <50032DA2.9020108@foobar.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Dear All
Around a year ago I had the same debate sflow vs netflow vs snmp port count=
ers. read lots of stories lots of myths lots of good information. My Concl=
usion
In the end I did real life testing comparing each platform
We routed live traffic (about 250mbits) from our Cisco 7200 G2 routers thou=
gh Brocade MLXe routers and exported netflow from the Cisco platform and sF=
low from the Brocade platform.
Each router sent netflow/sflow traffic to two collectors on independent har=
dware (same specifications) running the same collection netflow analyzer so=
ftware.
The end result was after hours of testing, or even days and weeks of testin=
g there was no significant difference between traffic volumes netflow was s=
howing vs slfow. Ie less than 0.5% variance between each environment.
That being said both netflow and sflow both under read by about 3% when com=
pared to snmp port counters, which we put to the conclusion was broadcast t=
raffic etc which the routers didn't see / flow.
Regardless if you're going to bill from netflow or sflow in our test enviro=
nment we saw no significant difference between either platform.
Hope that helps
Kindest Regards
James Braunegg
W:=A0 1300 769 972=A0 |=A0 M:=A0 0488 997 207 |=A0 D:=A0 (03) 9751 7616
E:=A0=A0 james.braunegg@micron21.com=A0 |=A0 ABN:=A0 12 109 977 666=A0=A0=20
This message is intended for the addressee named above. It may contain priv=
ileged or confidential information. If you are not the intended recipient o=
f this message you must not use, copy, distribute or disclose it to anyone =
other than the addressee. If you have received this message in error please=
return the message to the sender by replying to it and then delete the mes=
sage from your computer.
-----Original Message-----
From: Nick Hilliard [mailto:nick@foobar.org]=20
Sent: Monday, July 16, 2012 6:53 AM
To: nanog@nanog.org
Subject: Re: Real world sflow vs netflow?
On 14/07/2012 09:30, =A3ukasz Bromirski wrote:
> And that's the biggest problem with sFlow. Packets are sampled, not=20
> flows. You may miss the big or important flow, you don't have=20
> visibility into every conversation going through the device.
Unless you enable sampling, which is pretty much necessary for non-trivial =
traffic volumes.
> NetFlow supports IPv6. As well as L2 traffic (v9), MPLS, multicast and=20
> so on.
It does, depending on hardware variety, but you need specific platform supp=
ort for each packet variety (v4 / v6 / mpls / etc), and platform support fo=
r this can be very dodgy. You don't need this with sflow - it just punts 1=
in N raw packets out to your collector, and the statistical assumptions wh=
ich were made by the networking device are well documented.
I've never seen documentation on the sampling technique used for each netfl=
ow implementation.
> The measurements provided by sFlow are only approximation of the real=20
> traffic and while it may be acceptable on LAN links where details=20
> don't matter as much, it's hardly good enough to present a real view=20
> on the WAN links.
>=20
> sFlow was built to work on switches and provide "some" accuracy, it's=20
> not good enough (unless you do sampling on a 1:5-1:10 basis) to do=20
> billing or some detailed analysis of traffic:
Depends on how detailed your requirements are. For billing, most people do=
n't classify by packet analysis, but rather by byte count which can be hand=
led by snmp port counters. If you need to do something fancier, non-sample=
d netflow is indeed good enough for billing.
> http://www.inmon.com/pdf/sFlowBilling.pdf
>=20
> You can use it to *estimate* the traffic, detect DDoS, sure. But the=20
> data & scaling used by sFlow (and additionally tricks used by ASIC=20
> vendors implementing it in the hardware) can't change the fundamental=20
> difference - sFlow is really sPacket, as it doesn't deal with flows.
agreed, the name is wrong.
> NetFlow, jFlow, IPFIX deal with flows. You can discuss sampling=20
> accuracy and things like that, but working with flows is more accurate.
Depends on your use case. For large traffic values, you run into the law o=
f large numbers and you can get accurate visibility into what's happening o=
n your network.
Certainly, netflow _can_ offer amazingly precise visibility into your netwo=
rk. But the trade-off is that you need specialised hardware to do this on =
your line cards or your forwarding engine. This drives up both the capex (=
extra hardware) and the opex (tcam is power hungry) of your network.
sflow is much cheaper to implement as you're not maintaining any state on =
your chassis. You're just picking out a packet every so often.
The current generation of high end service provider hardware (juniper mx-3d=
, cisco sup2t / n7k / asr9k) is pretty much the first generation of hardwar=
e which doesn't have crippling netflow limitations, such as poor support fo=
r v6 / mpls, too small cache sizes, etc. This fact alone should provide a =
good indication of how difficult it is to implement it well on fast boxes.
sflow is simpler, cheaper and in many cases is simply a better choice if yo=
u don't need drill-down into every single flow going through your networkin=
g.
Nick
