[AusNOG] vyatta netflow and AS export

Tue Jun 9 11:24:30 EST 2015

I remember pmacct! Thanks Scot.

On 9 Jun 2015, at 9:21 am, Scott O'Brien <scott at scottyob.com<mailto:scott at scottyob.com>> wrote:

I believe some in the Juniper world are using SCU/DCU for billing purposes https://www.juniper.net/documentation/en_US/junos14.2/topics/usage-guidelines/interfaces-enabling-source-class-and-destination-class-usage.html.  Not sure what similar tech exists on other platforms though??

I know I’ve mentioned this on the list before, but whenever collecting flow data (NetFlow, sFlow, IPFIX) I think it’s really worth checking out the pmacct project http://www.pmacct.net<http://www.pmacct.net/>.  This has a BGP daemon built in so if you’re collecting flow data from a source that doesn’t have a BGP view of the world you’re after, or doesn’t support it, you can modify the data to include BGP from wherever.  I’ve used Pmacct before for generating stats based on BGP communities where netflow was collected from a router inside the campus (with only a default route) and BGP community stats were taken from a border router with more useful communities.

Hope that’s another option!
~ Scott

On 9 Jun 2015, at 10:36 am, David Lambert <sobmalss at gmail.com<mailto:sobmalss at gmail.com>> wrote:

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<mailto: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<tel:%2B61.412.869.959>
www.brocade.com<http://www.brocade.com/>

On 9 Jun 2015, at 9:21 am, Paul Koch <paul.koch137 at gmail.com<mailto:paul.koch137 at gmail.com>> wrote:

On Fri, 5 Jun 2015 12:07:42 +1000
Ivan Jukic <ijukic13 at gmail.com<mailto: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<http://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<http://akips.com/>
Brisbane, Australia
Cell: +61 (0)458 803 740<tel:%2B61%20%280%29458%20803%20740>
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto: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/737bb4be/attachment.html>