91 posts categorized "Deep Packet Inspection" Feed

Got NetFlow and Metadata – Why do I need packets? (by Chris Greer)

It’s all about time.


When it comes to network monitoring, NetFlow and Metadata-based tools allow engineers to get a handle on traffic usage, statistics, capacity, and even security attacks. They quickly help us visualize the conversations and applications involved in congestion, as well as hone in on strange traffic behavior. It would be difficult (and overkill at times) to use packet data to show the same traffic statistics.

So then, why are packets necessary for analysis and monitoring?

In most cases, NetFlow and Metadata do not show us packet timing, which is critical when isolating the root cause of performance issues, and some security issues. To better understand why, let’s look at how NetFlow works.

NetFlow 101

Continue reading "Got NetFlow and Metadata – Why do I need packets? (by Chris Greer)" »

Network Troubleshooting Tip - Focus on a Single Symptom (by Paul Offord)

When we get to the point in an investigation where we are about to break out Wireshark, the complexity of the packet analysis can seem quite daunting. And yet by covering a few key points can dramatically cut the time needed to analyze any diagnostic data.

In my previous post I covered the need to thoroughly understand a symptom. In this blog we'll look at the dangers looking for a common cause for multiple symptoms.

Imagine you are faced with a situation where users are complaining about three issues:

  • Word documents should open in less than 5 seconds, but intermittently take more than 30 seconds.
  • Excel workbooks should save in less than 15 seconds, but intermittently take more than 60 seconds.
  • Opening an Outlook Inbox should take less than 20 seconds, but sometimes takes more than 3 minutes.

All problems are reported as having started at the same time, and there’s a widespread belief that they are being caused by a network issue. This is the point where alarm bells should start to ring.



Maybe some of the symptoms are down to the same root cause, but maybe they are not, and starting by assuming they are is likely to lead to a very frustrating time. The choice of a single symptom and ...

Continue reading "Network Troubleshooting Tip - Focus on a Single Symptom (by Paul Offord)" »

LMTV LIVE | Taps vs SPAN Ports (with Keith Bromley and Jonathan Petkevich of IXIA)

YouTube Live Event starts at 9:30AM PST, Wednesday, March 8, 2017

Yx_X0tC2This week we will be speaking with Keith Bromley and Jonathan Petkevich, Senior Manager of Solutions Marketing and Product Manager of IXIA, respectively.

When it comes to monitoring your network, data collection is an extremely important subject. You need to know the type and quality of your data. For instance, is it an exact copy of the network data or has your monitoring data been modified (time stamps, checksums, etc.). The source of the data is important as it effects troubleshooting activities and network security. Join us for a discussion of how to capture the right type of monitoring data and a comparison of Tap-based vs. SPAN-based data.

Continue reading "LMTV LIVE | Taps vs SPAN Ports (with Keith Bromley and Jonathan Petkevich of IXIA) " »

TCP Fundamentals: Analyzing TCP Resets (RST) (by Chris Greer)

Are TCP resets bad?

TCP RST reset bad or good

Wireshark can sure make them look that way. After all, bold red lines rarely highlight something positive. But like many things TCP, the good-or-bad factor of resets just depends on when they happen and how they are affecting end users.

There are a two common ways that a TCP connection can be torn down. I like to call these the polite way (FIN) and the talk-to-the-hand way (Reset). Tearing down TCP connections is a good thing as long as it is not actively in use, or won’t be needed in the very near future. We want each side of the conversation to open up the resources for other connections rather than maintaining idle ones in an active state.

In most cases, we want to see FINs tear down a connection rather than resets. However there are some examples of normal behavior where a reset is sent rather than a FIN.

Here are a few questions to answer about resets when they appear in a trace file. 

Continue reading "TCP Fundamentals: Analyzing TCP Resets (RST) (by Chris Greer)" »

Analyzing TCP Segmentation Offload (TSO) with Wireshark (by Paul Offord)

Most modern PCs and servers have powerful network interface chip sets that can provides TCP/IP functionality that cuts the load on the host machine.  The most common of these functions is TCP Segmentation Offload (TSO).  In this short article we use Wireshark to discover how TSO affects our interpretation of network traces.




A program running in a PC or server may make a single call to the TCP/IP stack to send, say, 5 KB of data.  The TCP/IP stack, which is a software driver within the operating system, must repackage the 5 KB so that it can be sent in multiple packets.  This operation is called segmentation and it consumes CPU cycles.  Additionally, the TCP/IP stack must handle issues such as retransmissions.

A network interface chip set that provides TSO allows the host TCP/IP stack to send a single 5 KB segment.  The network interface chip set then re-segments the data into, say, three packets with a TCP Length of 1,460 bytes and one of 798 bytes, making 5 KB in total.  This can all appear to be very confusing in a network trace, especially as the packets received may not be aggregated in a similar manner.

In the following short video ...

Continue reading "Analyzing TCP Segmentation Offload (TSO) with Wireshark (by Paul Offord)" »

DNS Traffic is always worth watching very closely (by John Brosnan )

DNS Traffic is always worth watching very closely

But it is not a good excuse to forget your anniversary!

While visiting a large ISP type customer here in the Bay area, we started to discuss the value he could get from network traffic analysis. The volumes of traffic on his network are at a scale that he even struggles with summary information like Netflow; he has so much of it, it is almost impossible to get a handle on it and see anything useful – a real big data problem. 

Network Globe_WEB

During our conversation, I mentioned that we have a number of dissectors (or application decoders as we call them) for protocols like SMB, NFS, SQL, web, DNS – ’STOP, what can you tell me about my DNS traffic, as my logs are limited’.  To be honest, I would have thought LANGuardian provided too much detail for his organization, but I guess DNS is a bit different.

Anyhow, I led on to explain that LANGuardian can:

  • Monitor DNS traffic, decode DNS replies
  • Inventory of responding DNS servers
  • Alert on rogue DNS servers
  • Review what resolutions clients receiving
  • Monitor client requests, validate DNS traffic (piggybacking)

To quote a good friend, Tim of #lovemytool ‘John, show me, don’t tell me’

Continue reading "DNS Traffic is always worth watching very closely (by John Brosnan )" »