101 posts categorized "Deep Packet Inspection" Feed

Palo Alto Packet Latency Case Study Using Workbench and Wireshark (by Paul Offord)

Analyzing packets at two points provides an accurate way to determine the delays across a network.  The team at Advance7 used this technique to find the cause of performance and stability problems with a web application.  The system topology was complex, but very common in today's enterprise environments; users accessing systems using a Windows terminal and ESX VDI-delivered desktops.


Users reported slow response times and intermittent disconnects.  The path through the network from VDI host to application server was 10 GbE all the way, and so link overload was unlikely.  There were various theories about the cause of the problem but solid evidence was needed.

In this video ...

Continue reading "Palo Alto Packet Latency Case Study Using Workbench and Wireshark (by Paul Offord)" »

TCP Checksum Error Case Study (by Paul Offord)

When I see TCP Retransmissions and Dup ACKs in a trace I naturally think about packet loss, but that's not the only cause.  The TCP Checksum mechanism is used to check the integrity of the TCP payload (or segment) and, although it's rare to see genuine checksum errors in a trace, it's another cause of retransmissions.

  Network topology

For Wireshark users there's good and bad news.  The good news is that Wireshark can check each packet for TCP Checksum errors.  The bad news is that they are not always genuine errors.  So how can we tell the difference?

In this video ...

Continue reading "TCP Checksum Error Case Study (by Paul Offord)" »

Give Me Packets!!! Case Study: Slow Oracle DB (by Mike Canney)

There are a number of tools on the market that claim to allow you to analyze Data Bases.  I have many customers that own these tools and sometimes they work great.  Especially if it's what I call a "Low Hanging Fruit" problem, such as a slow SQL call like a SELECT or INSERT etc.  

What happens when it's not so obvious?  This is where deep packet analysis is needed.  In the following case study we will look at a chronic problem that far too many of my customers experience and how to quickly resolve that issue.  This particular problem was lasting for months.  More memory was added, servers upgraded, content switches added/upgraded yet the problem still persisted.  

 Let's take a look:



Continue reading "Give Me Packets!!! Case Study: Slow Oracle DB (by Mike Canney)" »

Give me PACKETS!! Case Study: "The Slow Internet" (by Mike Canney)

Like many Network Engineers, I have also heard all to often that "The Network is Slow".  This is the mantra repeated across the World by end users, server admins and application developers.  

Luckily, we are armed with a tool set to not only exonerate the network (in most cases) but also pinpoint exactly where the problem occurred.  

Being a Packet Fetcher, the first thing I typically turn to in these situations is handy dandy PCAP(s).  In this first case study, we will see how to quickly solve this performance issue given the correct trace files from, more importantly, the correct areas of the network.   See the following diagram of the capture points as well as the video at the end of the post.





Continue reading "Give me PACKETS!! Case Study: "The Slow Internet" (by Mike Canney)" »

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?


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