On May 7, 2014, at 10:45 PM, Paolo Lucente <pl+l...@pmacct.net> wrote:
> This model is supported on the export side by Cisco with their NetFlow/NBAR > integration and on the collection side by some > collector. As you'll note in reading that report, NBAR didn't seem to work very well for them; I haven't run across its use in any ISP network, on ISP-grade hardware (i.e., not a small software-based router like a 7200), or even in a large-scale enterprise environment. Again, I haven't yet run across anyone actually using this on a production network. It would be very interesting to hear from someone with first-hand experience with NBAR exported over Flexible NetFlow in a production environment. Also, it's important to note that this sort of thing doesn't scale across networks of any real size/speed. There's a great deal of potential utility in the security, troubleshooting, and traffic engineering arenas for on-demand triggered packet sampling of this nature, but so far, the control-plane hooks aren't really there to do this in a programmatic manner (one presumes that SDN of one flavor or another might provide these capabilities). That was my biggest gripe about Flexible NetFlow when I was at Cisco, and one which I felt ensured the technology wouldn't make it into production networks - no organic control-plane interface. So, perhaps now we can de-conflate flow telemetry and 'DPI', since the real-life export, collection, and analysis of anything other than layer-4 information via flow telemetry isn't at all commonplace (if it in fact exists at all) on production networks), at this juncture. 'DPI' generally alludes boxes positioned at points of ingress/egress symmetry (either natural or purposely engineered) within a network. Flow telemetry per se is not really within the rubric of 'DPI'. ----------------------------------------------------------------------- Roland Dobbins <rdobb...@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
