[AusNOG] vyatta netflow and AS export

Tue Jun 9 10:36:20 EST 2015

Just to add to this.. Not all Netflow/Jflow/IPFIX is 1:1, some routers only
support sampled Netflow, this is performed on hardware forwarding platforms
that never used flow based forwarding and thus do not keep flow tables. To
get around this they mirror traffic to the control plane for processing or
if scale is required then its dedicated CPU to process mirrored traffic
into Netflow data; this can get expensive.

Service providers have been using sampled netflow on hardware routers for
many years for effective (well.. effective enough to do what they want with
it) analysis of traffic.

Using Netflow for billing can (and has been for some) become a scaling
liability.

Openflow based billing app anyone?

dave

On Tue, Jun 9, 2015 at 9:50 AM, Russell Brenner <rbrenner at brocade.com>
wrote:

>  Hi Paul,
>
>  I don’t want to launch into a religious argument since I’m not a network
> operator myself, but most (all?) of our customers and my personal
> colleagues in the business are quite happy with sFlow billing and security
> (unless they’re harbouring resentment and haven’t told me :)).
>
>  Sflow is accurate for security purposes because it is simple enough to
> be performed in hardware. The sFlow is designed so that the accuracy of any
> measurement can be determined. Netflow tends to drop under heavy load,
> unless I’m mistaken.
>
>  So, on to the billing bit.
>
>  You don’t need to sample every single packet to get meaningful billing
> data, there’s not a great deal of benefit in doing so since the extra few
> percentage points don’t equate to serious gains, but quite large
> performance penalty (depending on the platform and media speed).
>
>  With sFlow you optimise the sample rate in order to meet the
> desired level of accuracy and this is done by varying the number of samples
> collected.
>
>  The accuracy is a function of the number of samples collected and
> the duration of the monitoring period.
>
>  Further improvements in accuracy can be made by calculating the
> “confidence level” which is the width of the error window. In order to
> ensure that customers are not overcharged then the data point at the lower
> end of the confidence level should be used and this is a direct function of
> the number of samples collected and this can be calculated thus:
>
> Percentage Error ≤ 196 x √(1/c) where c is the number of samples.
>
> For example, if the number of samples is 10,000 then the error will be
> approximately ±2% so the amount charged for should be 98% of the
> total number of packets counted.
>
>  It is important to note that the accuracy of measurement does not depend
> on the total number of frames, but simply on the number of samples used
> to make the measurement. As the speed of the interface increases, the
> percentage of the total number of frames sampled can be reduced.
>
>  This is reflected in the default sampling rates we use on our devices
> (512/1024/2048 and 8192 for 100M/1G/10G/100G). Furthermore, accuracy can be
> improved by simply increasing the duration of the sample period until the
> required number of samples has been collected.
>
>  The sampling rate is the average ratio of the number of packets incoming
> on an sFlow-enabled port, to the number of flow samples taken from those
> packets. The sampling rate is a fraction in the form 1/N, meaning that, on
> average, one out of every N packets will be sampled.
>
> Because the accuracy of the sFlow measurement is dependent only on the
> number of samples then increasing the accuracy is fairly simple simple, and
> any errors will be negligible.
>
>  Russell Brenner
> Systems Engineer
> Brocade
> Suite 524, 1 Queens Road, Melbourne
> M. +61.412.869.959
> www.brocade.com
>
>  On 9 Jun 2015, at 9:21 am, Paul Koch <paul.koch137 at gmail.com> wrote:
>
> On Fri, 5 Jun 2015 12:07:42 +1000
> Ivan Jukic <ijukic13 at gmail.com> wrote:
>
> Netflow or the currant "standard" is now called IPFIX. This is certainly
> support by Cisco as well as many other vendor.
>
> In relation to sflow not being a useful technology. I disagree. They
> essential both do the same, analyse traffic flows. However, sflow does so
> by packet sampling, 1 packet out of X sent to the collector. Where as
> IPFIX/Netflow send every packet to the collector. They both very useful,
> however there is a lot of design considering when rolling them out.
>
> Cheers,
> Ivan
>
>
>
> sFlow is not useful.  It typically uses a 1 in N sample, where N is a
> "very big number".   Once you go over N=5 or N=10, it becomes statistically
> useless... or actually misleading and deceptive.  Ask any statistician
> and they laugh at the 1 in 1000 sample.
>
> I even watch a presentation from one of the sFlow.org guys who reckon
> that N 1,000,000 sample was even useful.  Not sure what planet...
>
> For security guys, a N=1 is pretty much mandatory.
>
> sFlow should have been called something different as it just causes
> confusion.  A lot of people seem to think it is 'switch flow' and are
> surprised when you explain that its just packet sampling at N=1k or N=16k
> packets.  Switches will never do a N=1 sample because the cost of the
> hardware would be prohibitive.
>
> Plixer have some interesting blogs on Netflow vs sFlow.
>
> Paul.
> --
> Paul Koch | Founder, CEO
> AKIPS Network Monitor | akips.com
> Brisbane, Australia
> Cell: +61 (0)458 803 740
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150609/432e86b5/attachment.html>