[AusNOG] vyatta netflow and AS export

Tue Jun 9 11:21:40 EST 2015

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 <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> 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 <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 <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/3d88bad3/attachment.html>