Using NetFlow & Other Flow Data to Solve Network Problems

Featured article by Jim Frey, Independent Technology Author

Ever wonder why your client’s network is “slow”? Or if the network is at fault in the first place?

It’s not uncommon for IT-enabled workers to experience web, application, or session delays. Most end users gripe a little to colleagues or at their screen, then wait for things to start up again. Or maybe they go coffee up in hopes that all will be well when they get back.

It’s an inconvenience for sure, but it can also be a drag on productivity. In the worst cases, it can bring business to a halt entirely.

Temporary spike or chronic issue?

There will always be cases where a temporary spike in network activity will cause these types of disruptions. There’s not much to be done about it, unless you seriously overprovision your IT infrastructure, including your Internet connection, to a huge (and expensive) degree. Few can afford that, and will have to work with systems and networks that are limited, but ideally are designed to handle load gracefully most of the time.

More troubling are the recurring, chronic performance issues, which indicate a significant resource shortage or malfunction somewhere in the infrastructure. The network usually takes the blame.

While the network isn’t always the core reason (my own research as an industry analyst found the network was a fault of performance issues at most around 40% of the time), it’s a great place to start looking for root causes, because it connects everything together.

Much like the transit system in a major metro area, congestion and breakdowns can cause noticeable delays.Watching traffic flow patterns is a great way to quickly recognize where issues are occurring so you can trace them back to the most likely root cause—network or not.

Uncovering answers with flow data

To get definitive insights into what comprises network traffic, flow-based network instrumentation is the key. The two primary approaches for doing so are:

1. Capture and inspect packets as they stream across network links, usually requiring costly network probe appliances, or

2. Have network devices generate flow record snapshots, using formats such as NetFlow, sFlow, or IPFIX, as packets stream through them.

The latter approach is much simpler and less costly to deploy.

Using flow records, we can get a number of very important insights into what makes up the traffic that consumes network bandwidth.

First off, we can see source and destination IP addresses, so we know who’s active. Next, we can also see port and protocol info, so we can determine what class of applications are being used (web, email, file transfer, etc.). Finally, and perhaps most importantly, we can see how much of the total network capacity is consumed by each flow.

You can conduct this analysis against any point in the network where flow records are being produced, but most common is the point where your network leaves the comfy confines of your LAN and connects to the wider outside world: your edge router. External links, whether WAN or Internet, are commonly lower bandwidth than LAN and thus more likely to be a point of congestion that interferes with normal traffic flow, a.k.a. “network slowness.”

With analyzed flow in hand, you can see at a glance:

1. Is my Internet link clogged up?

2. Who are the biggest users?

3. What application are they using or website are they browsing?

4. Or… should I look elsewhere?

Pinpointing culprits

You might indeed find congestion, as might be caused by big file transfers (think patch downloads, presentation files, or backups) or streaming media. Those could be legitimate business activities, though sometimes they aren’t. In my many years working and researching network visibility tools, I’ve seen a lot of interesting problems of this type.

In one case, a software developer decided to download a new operating system version for a lab trial during normal business hours, clogging a 12Mb Internet link with a 12GB file transfer.

In another, an engineering employee was pulling pirated multi-gigabit digital movies from filesharing servers based in China.

And then there was the accounting employee who set up and was running their own Internet-based business from their desktop.

But there are also cases where a file backup to offsite storage was set up using the wrong timezone, and suddenly fired off in the middle of the business day. And the (frankly glorious) case of a marketing campaign that went viral and brought a small shop to its knees with business demand.

You might also find no congestion problem, in which case the issue may lie with the way the network is configured, resource issues on the end user’s system, or degradations of servers or service somewhere out across the Internet.

Examples I’ve run across abound here too, such as a circuit misconfiguration causing excessive packet drops/retransmits, a bad NIC on a server that wouldn’t autonegotiate properly, an antivirus scan kicking off unexpectedly (due to misconfiguration), or a degraded DNS provider.

Going with the flow

There are so many possible reasons why “the network is slow” that it would be impractical to go through them all here. But the important takeaway is this: With clear visibility into the uses and users of network traffic, you can accurately determine if the network is indeed the problem, what the root causes are most likely to be, and where to focus actions to set things right. Best of all, it’s fast!

So relax, take a deep breath, and go with the flow. It’ll make your day-to-day a lot simpler and less stressful. You’ll be in a position to understand and answer questions about network use and misuse that you haven’t been able to before, and also in a position to get ahead of problems by making better-informed decisions around usage policy and capacity planning.