Say hello to NetFlow-Lite (NFLite)

As you all know, NetFlow has been initially designed for routers (or L3 switches if you wish), contrary to sFlow that instead has been deployed mostly on switches. In this view, people use NetFlow just for monitoring internet traffic, as NetFlow is not supported across the product portfolio due to dedicated ASIC required. NetFlow-lite (first introduced with Catalyst 4948E) bridges the gap by providing a lightweight solution that allows capturing of important flow information through packet sampling mechanisms combined with the extensibility of NetFlow version 9 and IPFIX.

What is NetFlow-Lite?

In a nutshell NFLite is a technique that allows the NetFlow cache to be moved outside of the switch into an external entity that contains a NFLite to NetFlow (v5/v9/IPFIX) converter. nProbe (6.1.6 or above) is the first application able to do this conversion, and it has been closely developed by ntop and Cisco to make sure it complies with the protocol specs. This conversion is necessary as NFLite flows generated by the switch are basically encapsulating packet samples, that need to be converted into “legacy” flows that standard collectors can process. Technically speaking NFLite flows are formatted as standard V9 flows with a custom template, that tells the NFLite collector (nProbe in our case) how to decode the enclosed packet that is cut to the configured snaplen.

NetFlow-Lite Advantages

With the help of nProbe, netflow-lite can be analyzed and supported by any netflow collector that understand version5, 9 or IPFIX.

Netflow-lite solution can be designed from a tiered approach for large scale data center: by deploying an nProbe per zone to summarize NetFlow-lite data within the zone, it reduces the amount of bandwidth overhead and allows data from multiple zones to be analyzed and gathered by a centralized netflow collector.

nProbe & NetFlow-lite supports NetFlow version 9 and IPFIX.

nProbe act as a collector to netflow-lite switches and as a probe to end collector. It works seamlessly with existing, already deployed NetFlow collector as well as allowing a wide choice of NetFlow collector for new deployment.

NetFlow-Lite and nProbe

As stated above, nProbe is the first application to support NFLite. You might wonder what are the challenges behind this work. I can list some:

NFLite collector does not simply receives flows and dumps them on a DB (as most collectors do). It must also implement the flow cache, that is a typical activity that a netflow probe does, and that is missing in collectors (they usually filter and aggregate flows, but nothing more than that).

NFLite flows contain packet samples, that are basically packets seen on switch ports, along with some metadata information such as the port on which such packet has been seen. This means that those packets need to be decoded (i.e. packet parsing) and consolidated into the flow cache. Dumping them on disk in raw format (as NetFlow collectors usually do) is useless as you can’t do much with them.

Depending on the number of NFLite-aware switches, traffic and sampling rate, that send traffic towards the same nProbe, the amount of packets can be as high as 1-2 million flows/sec. Most NetFlow collectors can handle a sustained collection speed of a few tenth/hundred flows/sec, that is not adequate for providing accurate network visibility.

Using nProbe as NetFlow-Lite Probe/Collector

In order to use nProbe with NFLite, you don’t have to do much.

Installation

From Source

tar xvfz nProbe-xxx.tgz

cd nProbe-xxx

./autogen.sh

make

sudo make install

From Binary Package

RedHat and Centos

rpm -i nprobe-xxx.rpm

Ubuntu/Debian

dpkg -i nprobe-xxx.deb

Windows
Use the graphical installer that comes with the nProbe package

Usage

As said before, with NFLite nProbe acts as both a collector (i.e. it collects and decodes NFLite flows received by NFLite devices such as Catalyst 4948E) and probe (towards a remote NetFlow collector). Note that if your collector is nProbe itself, you can avoid sending converted flows to yet another nProbe instance, but you can use the same nProbe instance you used for NFLite conversion.

On the 4948E side you have to make sure the NFLite is properly configured. Example

none means that nProbe does not capture packets from a physical device, but it rather receive flows via UDP. Note that you can start nProbe for both collecting NFLite flows and at the same time creating flows capturing packets from a specific interface.

5.5.5.5:2055 is the IP address and port of the NetFlow collector to which NFLite converted flows will be sent.

512000 is the initial size of the NetFlow cache that will be used for aggregating NFLite flows.

Conclusions

NetfFow-Lite is slated to come out on 4948E and 4948E-F in the next software release. As of today, NFLite support is part of nProbe for both Unix and Windows. If you are interested in testing NFLite, you have no excuse as you can download nProbe today.

What I am currently doing these days is the ability to improve collection speed in nProbe. Even if today we can handle more than 500k flows/sec per NFLite device, I am developing a new technique (PF_RING can help) that allows to break these limits. Stay tuned.

Credits

Many thanks again to Cisco and to the Catalyst team for letting ntop to be part of this challenging project!

Upcoming Events

We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies from this website. Privacy PolicyAcceptRead more