cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

The Role of Packet Analysis in Network Monitoring

Level 12

The Rolling Stones once wrote a song about how time waits for no one, but the inverse is also true today. These days, no one waits for time; certainly not government personnel who depend on speedy networks to deliver mission-critical applications and data.

Fortunately, agency administrators can employ deep packet-level analysis to ensure the efficiency of their networks and applications. Packet-level analysis involves capturing and inspecting packets that flow between client and server devices. This inspection can provide useful information about overall network performance, including traffic and application response times, while fortifying network security.

Before we get into how this works, let’s take a minute to go back to the concept of time – specifically, network response time (NRT), also known as network path latency. NRT measures the amount of time required for a packet to travel across a network path from sender to receiver. When latencies occur, application performance can be adversely impacted.

Some applications are more prone to latency issues, and even lower bandwidth applications aren’t completely immune. End-users commonly think that these problems are the result of a “slow network,” but it could be the application itself, the network, or a combination of both.

Packet analysis can help identify whether the application or network is at fault. Managers can make this determination by calculating and analyzing both application and network response time. This allows them to attack the root of the problem.

They can also use analysis to calculate how much traffic is using their networks at any given time. This is critically important for two reasons: first, it allows administrators to better plan for spikes in traffic, and second, it can help them identify abnormal traffic and data usage patterns that may indicate potential security threats.

Additionally, administrators can identify which applications are generating the most traffic. Packets can be captured and analyzed to determine data volume and transactions, among other things. This can help managers identify applications and data usage that may be putting a strain on their networks.

The challenge is that, traditionally, packet-level analysis has typically been either too difficult or expensive to manage. There’s a free powerful open source tool called Wireshark, but it’s also a bit difficult to wrangle for those who may not be familiar with it. Many proprietary tools are full-featured and easier to use, but expensive.

The good news is that some standard network monitoring tools now include packet analysis as another key feature. That makes sense, because packet analysis can play an important – and very precise – role in making sure that networks continue to run efficiently. As a result, federal IT administrators now have more options to reach deep into their packets and honor the words that Mick Jagger once sang: “Hours are like diamonds. Don’t let them waste.”

Find the full article on our partner DLT’s blog, TechnicallySpeaking.

10 Comments

I saw this:  pastedImage_0.png

And I started wondering--how does one "calculate" network response time?  My tools measure it, but if one needed to calculate network response time, how would one proceed?  Measuring physical distance and media types?  "A particular packets travels 350 miles round trip via fiber and two miles via copper.  It passes through six BGP hops, four edge routers, two firewalls, and four core and distribution and edge switches.  The expected latency is  . . .?"

Is "calculating" the right concept and term here?

I'm probably picking nits . . .

Level 20

NPM netpath will help with this along with QOS time to first packet.

Level 12

We had a situation where packet inspection helped us prove to the vendor that it was in fact "not the network" that was causing the issue. The problem was intermittent, but it always happened at the same time, 5 min after the hour, but not every hour. Problem is their error logs on the clients kept stating "slow network" in the errors, so they just wrote it off as that and pretty much wouldn't help us. On the surface their explanation makes sense. When the packet is sent out, if the reply is not received in a certain time frame, it generates the slow network error. So we tracked the packets through the network, and they were moving right along from the client to the server. Then we would wait and wait and wait for it to come back out of the server, but it would not show up in a timely matter when this problem as happening. After waiting quite a while, the packets would start coming back out of the server and make their way back home to the client, who had given up waiting for the response and sent out another request to the server. We did some digging into the server and it discovered an issue with some of the VM network settings, which were set exactly as the vendor recommended they be set to for the virtual server. We turned off the Large Send Offload settings on the NIC and the VM and everything else we could find in there, and suddenly things worked fine again. We went back to the vendor with this and they said "See we told you it was the network!!!". While it may have been a network setting, it was on the server itself that was causing the issue. The weird part is when it was happening, randomly during hourly backup jobs. For some reason once in a while the backup job would cause the network system to freak out and not properly break the packets down to the 1500 size coming out of the vm to the physical network like it was supposed to be doing. We saw that packets much bigger then 1500 were hitting the switch, and the switch just kind of looks at it like "wtf you doing here, you cant fit on this ride go home," and tossing the packets out.

Level 16

There are several good tools out there that utilize packet capture as their base.

Level 21

The biggest problem we have with Packet Analysis is that much of our infrastructure is 10Gb which is not supported by many tools and the ones that do are very expensive.

We're moving to Gigamon tapping / sharing infrastructure for that very reason--big ports.  10 Gig ports in 4-port port-channels, 40 Gig ports doing the same.  Not inexpensive.

Level 16

At my previous gig we had all of our 10G Network Core, DMZ and WAN tapped with Gigamon. You are right, it was very expensive! It took about eight months to coordinate all of the downtimes needed to tap all of those links

I was pretty happy with the Gigamon. It fed all of the other tools for Security, Web Analytics, and Packet Capture.

MVP
MVP

Not sure how you are accurately calculating NRT. 

Even a ping is an average based on a round trip. 

Different protocols have different QoS. 

Packets may travel faster one way than the return thus an average may not tell you much.

Level 16

@ Jfrasier

Calculating network response time from a packet capture is easy and very accurate and can be done in many different ways.

First the most basic and easiest way to calculate NRT would be to measure the time of the Syn/syn/ack that sets up a tcp conversation. Since you are only measuring the 'agreement to communicate' portion then its a pretty good indicator of the round trip time between two machines. If you are trying to measure something like the response time of a web page, chances are there will be a lot of TCP sessions set up and tore down during the load of the page. In that case you can average out the time for multiple stream setups and get a pretty good idea of what the Network Round Trip time is.

You can make filters for each QOS value you are using on your network and then you would have it for all of them.

Level 8

Hi rschroeder,

A simple example would be to watch the packet time column in Wireshark during, say, TCP connection setup. Then, you can watch the deltas (the "calculation") between the time the client makes its request and the server responds (response time). Generally, you'd see the TCP 3-way handshake happen in a millisecond or two, but if you saw an HTTP server respond to a GET/POST in hundreds of milliseconds or even seconds, then you'd have a direction in which to check.

Happy packet sleuthing!

About the Author
Joseph is a software executive with a track record of successfully running strategic and execution-focused organizations with multi-million dollar budgets and globally distributed teams. He has demonstrated the ability to bring together disparate organizations through his leadership, vision and technical expertise to deliver on common business objectives. As an expert in process and technology standards and various industry verticals, Joseph brings a unique 360-degree perspective to help the business create successful strategies and connect the “Big Picture” to execution. Currently, Joseph services as the EVP, Engineering and Global CTO for SolarWinds and is responsible for the technology strategy, direction and execution for SolarWinds products and systems. Working directly for the CEO and partnering across the executive staff in product strategy, marketing and sales, he and his team is tasked to provide overall technology strategy, product architecture, platform advancement and engineering execution for Core IT, Cloud and MSP business units. Joseph is also responsible for leading the internal business application and information technology activities to ensure that all SolarWinds functions, such as HR, Marketing, Finance, Sales, Product, Support, Renewals, etc. are aligned from a systems perspective; and that we use the company's products to continuously improve their functionality and performance, which ensures success and expansion for both SolarWinds and customers.