Powered by Squarespace
Popular Categories
Blog Posts
Discussion Activity
Cisco Live 365
« Cisco ACE Module HTTP-to-HTTPS (SSL) Redirection | Main | S4 - Super Simple Storage Service: One-ups Amazon's AWS S3 »

NetFlow -- The who/what/when/where of packet flows

Every network engineer reaches a point in their packet life where they need to gain a much better understanding of the type of traffic and patterns that traverse their network.  From corporate users streaming Pandora and YouTube over your Direct Internet Access (DIA) circuits to Data Center spikes putting stress on uplinks, network engineers need to understand who is on the network, what is being done with it, where the packets are flowing, and when this all happens.

For most Cisco routers and higher-end enterprise switches or firewalls, NetFlow, the proprietary Cisco flow metering protocol, and the sFlow open-standard (based on Cisco’s original proprietary protocol like so many others [and many people forget]), give insight into the network traffic and patterns.

In a nutshell, your network equipment can capture details about a flow and export that information to a collector.  Not every single packet needs to be sent to a collector, just the details after the flow is complete or at specific intervals during the life of a flow.  In case you’re not clear on what constitutes a flow, it’s the 5-tuple (destination ip, destination port, source ip, source port, and [ip] protocol) along with other details and metrics about that flow like total number of bytes or octets, start/end timestamps, and potential ingress/egress [in/out] interfaces.

An example of the details of a captured NetFlow that will be exported to a collector follows:

dip, dport, sip, sport, proto, bytes, start, end [, ingress interface]

Note that flows imply and obviously require ingress on one interface and egress on another.  For this reason, you usually enable just ingress Netflow on your interfaces, not both ingress and egress unless you like double-counting and blurred vision.  Packets will be seen in a flow in one direction when coming into interface A, then the other direction when the packets return on interface B.  NetFlow is usually able to record on the ingress side which output interface will be used before it gets there — the router isn’t psychic, it already processed the packet far enough along to know the egress interface by the time NetFlow gets updated.  If you perform ingress/egress NetFlow, packets are essentially seen twice: once on the ingress (input) interface, then again before leaving the egress (output) interface.  Unless it’s absolutely required to capture egress, this should not be enabled, especially if the NetFlow collector (discussed below) is unable to contend with the double-counting which causes over reporting.

Now not all equipment is capable of performing NetFlow, so you need to check with your specific hardware and software version.  Before enabling NetFlow anywhere, be aware of the potential to take down your network if NetFlow overwhelms your CPU, because NetFlow requires CPU or process-level handling of flows.  With higher-end equipment, much of the NetFlow instrumentation is handled in hardware ASICs like the 6500, but the export to one or more collectors requires the CPU.  One other caveat is to make sure you have CEF (Cisco Express Forwarding) enabled — ip cef.  Enabling NetFlow without CEF could cause process-level switching for all packets which would considerably slow down your switching capacity.

On a Cisco 3725 router, after confirming CEF is enabled with show ip cef, enable NetFlow in an interface by ip route-cache flow to capture ingress traffic.  Next, an export collector is enabled with ip flow-export w.x.y.z

Beware of NAT on hiding true source (or destination) IP addresses.  It’s best to have NetFlow running on gear that sees real source addresses.  In cases where ideal deployment of NetFlow is not possible, and NAT (actually PAT) will not give your the granularity desired, you could group users into specifc Dynamic NAT pools so at least you can identify traffic sources to groups of users or physical locations.

A popular NetFlow tool is Scrutinizer.  Very impressive, installs quickly and easily, and just seems to run with little tweaking.  The unlicensed, limited-feature version can be used for quick and dirty diagnostics, but all data captured is wiped clean at midnight. 

With a most NetFlow reporting tools, you’ll soon be learning who’s spending all their time on Facebook or YouTube.


Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Textile formatting is allowed.