98 posts categorized "Deep Packet Inspection" Feed

Network Troubleshooting Tip - Using Markers to Cut Trace Analysis Time (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, we can dramatically cut the time needed to analyze any diagnostic data.

In my previous post we looked at the importance of a basic understanding of the topology of the system under investigation. In this blog I'll cover the use of markers; a ridiculously simple, but amazingly powerful, concept.  A marker places a distinctive packet in network packet trace data that we can easily find with Wireshark.

The RPR manual contains six pages of information on markers, covering suggested markers and what to use them for.  If you haven't used markers before you are in for a real treat.  Once you get the hang of them, you'll wonder how you ever did without them.

Let's imagine you've been investigating an intermittent slow response time problem for a bunch of users.  Nobody is quite sure what's causing the problem, although the application and platform teams insist it's not them.  You know the drill; if the cause isn't obvious it must be the network, right?

Billions_of_packets

Luckily, a user experienced the problem this morning, and you had packet traces running.  The bad news is that you have 500 GB of trace data (about 5 billion packets) and the user is vague about the time of the problem.

The first strategy ...

Continue reading "Network Troubleshooting Tip - Using Markers to Cut Trace Analysis Time (by Paul Offord)" »


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

It’s all about time.

Alarm-2165710_640

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.

  Symptoms1

 

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.

 

Tso_with_flows

 

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)" »