NetFlow vs Metadata vs Packet Inspection - Which is right for you?

 

Isolating and rooting out network problems all comes down to having good visibility into the network. Without it, engineers just end up finger pointing and chasing problems around the enterprise.

At this stage of the network game, there are three major methods of getting insight into the network infrastructure and the traffic that traverses it: NetFlow, Metadata, and Packet Capture.

All three have their strengths in providing engineers with the right data in the right place at the right time - however they all have their weaknesses too. As you consider your visibility method in your environment, which one is right for you, and when?

With the security intrusions and pesky performance issues that are clearly here to stay, network engineers should have a solid answer to that question. NetFlow is easy to store, but can be limited in detail. Metadata shows pain points in a mountain of data, but can lead us in the wrong direction at times. Packets are the gold analysis standard on networks, but digging through them can be very confusing.

This whitepaper by ProfiTap discusses the strengths of each of these analysis methods and how and when each should be used.

https://www.profitap.com/wp-content/uploads/NetFlow-vs-Metadata-vs-Packet-Inspection.pdf

Check it out to get better insight into these three visibility methods and how to use them to troubleshoot and secure your network.

Free Command Line timer

Command line or batch files are incredibly important to me as an analyst. I cannot count the number of times creating a simple script has saved me countless hours. Some examples that come mind;

• Performing testing when I’m working alone

• Running tests unattended

• Having other people perform your testing

• Running a task as part of a notification system

In this article I use a simple example of recording the start/stop or elapsed time when copying a file. This can be easily modified for a wget, iperf, iperf3 copy, etc.

Troubleshooting HTTP 503 Issues

 I have mentioned in the past that you should really look ‘under the hood’ as far as application communication goes.

I have seen many web applications that ‘work’ but not ‘work well’. if you dig in, you may find error messages or logs. Errors can caused many different ways;

• Application - Messages are entirely application based and are addressed by the application team or vendor.
• Sending commands with no authentication, wait for the error message, then resend the same command but this time with authentication
• Using small packet or data payload sizes
• Inefficient multi-tiered server architecture
• Login processes that constantly download application files without checking if you have them already 
• References to servers that are de-commissioned or only used for testing/development
• Network – Messages generated by the network devices that can affect application performance and are addressed by the networking team, like ICMP redirects
• MTU issues caused by different network topologies, firewalls, routers or load balancers
• Blocked ICMP error messages that the application needs to make proper adjustments, like MTU and routing

The Meaning of Old

Most of us grasp the meaning of “old” but putting it into words can be challenging. When it comes to people who might be old, there are plenty of euphemisms to choose from. Senior, elderly and senior citizen come to mind, while terms like curmudgeon or geezer are available when appropriate. According to Webster’s, old is something that dates from the distant past, is distinctly different from something similar of an earlier date, has existed for a specified period of time, is advanced in years or shows characteristics of age. Old, it seems, is relative.

Rotary dial telephones are old technology, but at what point will smart phones be consigned to the “old” bin? The same can be said for CRT displays, computer punch cards, vacuum tube radios, phonograph records, Video Cassette Recorders and so on – the replacements for all of these are also living on borrowed time. New will always be fleeting, while old is permanent.

Baselining, No Problem

Not a week goes by without an email from someone asking me to how to create a baseline or worse, requests to review their baseline. I will explain both points before moving on.

Asking how to create a baseline

Spoiler alert, there is no real baseline ‘standard’ or ‘template’ that will meet all your needs. Of course there are typical things that you always document, but after that, it gets very specific. Everyone will use the same software differently.

A great example is Microsoft Outlook, a sales person will use the contacts like a CRM with conversation notes and follow up dates, where an IT person will use the same contacts feature to simply record contact info.

This is precisely why I usually ask the I.T. specialist to spend a little bit of time with the user to determine how they use the software, basic tasks, etc before capturing packets.

Requests to review a baseline