93 posts categorized "Deep Packet Inspection" Feed

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.

Internet_pic

 

 

 

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?

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