Category Archives: Network Troubleshooting

Why Customers Choose WildPackets

Customers come to us for a multitude of reasons. Some aren’t happy with their current network monitoring solutions; others are experiencing network glitches that they cannot solve; and some simply need a cohesive analysis solution. WildPackets offers a suite of products that bring customers to us from far and wide, many of whom need specific capabilities in their monitoring solution. Let’s take a look at just a few of the reasons WildPackets is the leading network analysis solution.

10G Analysis
WildPackets led the way in 10G analysis, being the first to introduce a network recorder to break the 10G barrier. When our TimeLine network recorder was introduced in 2010 it was the only network recorder to capture and store packet-level data, with no data loss whatsoever, at 11.7Gbps. Since then, WildPackets has continued to refine TimeLine, offering even more real-time statistics, increasing our overall data throughput, and adding support to capture directly from 40G network segments.

Network Forensics
Going hand-in-hand with network recording is network forensics. As you’re streaming packets to the network recorder perhaps you see a troubling trend in the real-time dashboard, or maybe a user enters a trouble ticket. Network forensics allows you to analyze a subset of your recorded data while the overall high-speed capture continues uninterrupted.

Often associated with security, network forensics goes well beyond security and also helps solve far more common issues on your network, like spikes in utilization, drops in VoIP call quality, and increased latency in both network and application performance. If a problem does occur, you no longer have to try to recreate the problem, which is typically the most time consuming task in any troubleshooting session. Instead, with TimeLine, you simply go back in time, find the problem on the dashboard, and solve it.

Remote Analysis
The days of using a laptop to perform portable analysis, especially on high-speed wired networks, are now extinct. Corporate networks are highly distributed, even for small to medium sized businesses. Even if your company operates from a single location, odds are you host some services remotely, and use some level of software-as-a-service (SaaS), making it difficult to always be where problems are occurring. WildPackets’ Omni Distributed Analysis Platform provides a wide range of options for remote network analysis, from “lightweight” software solutions like OmniPeek Remote Assistant and OmniEngine software probe, to high performance network recording appliances like TimeLine. With a WildPackets solution, network engineers can monitor and analyze highly distributed network architectures without ever leaving their desks.

Top-Down Approach to Network Monitoring
For an overall, top-down view of any network segment, customers find WildPackets flagship OmniPeek network analyzer most helpful, whether as a portable analyzer or as a console to any of our remote analysis solutions. OmniPeek provides complete visibility into your network – including Ethernet, Gigabit, 10G, 802.11a/b/g/n/ac, and VoIP and video. OmniPeek provides visual context into the network so that even junior IT staff can drill down into performance problems and solve performance issues across multiple network segments. This ensures maximum network uptime and user satisfaction.

The Full Suite of Network Monitoring and Analysis Products
And for a complete view across your entire network, WildPackets offers WatchPoint network monitor. This solution builds on our suite of distributed analysis products and provides a comprehensive graphical interface of overall network performance, including top talkers, top applications, overall utilization, VoIP performance, and detailed reporting of detected network and application problems (Experts). WatchPoint also provides a direct link for detailed, packet-level analysis to determine the root cause of any issue.

What is your favorite WildPackets product? Feel free to leave us a comment and share your thoughts.

Best Practices for Application Performance Monitoring and Troubleshooting

Network professionals do not have the luxury of simply responding to network failures. When problems arise, regardless of their nature, the network gets blamed. And as every network engineer knows it’s typically not the network at fault; it’s usually the application.

As the expression goes, the best defense is a strong offense. That’s why it’s essential to continuously monitor both network and application performance so the root cause of “network” issues can be easily identified.

For this blog, we’ll discuss best practices for ensuring application performance, whether your applications are virtual or hosted in a third-party data center like software-as-a-service (SaaS) or cloud computing.

Staging Application Monitoring
Most applications today are no longer centralized in a single data center. Instead, they are widely distributed, whether it’s due to a distributed data architecture within an enterprise, or usage of SaaS or cloud-based computing.

As you did with centralized applications, you still need to monitor key metrics like latency (both network and transaction), number of turns, overall network bandwidth, and payload sizes, which are particularly handy for application-level troubleshooting. However, with a distributed architecture, this information is no longer available from a single monitoring point. Data for analysis must be collected from multiple points along the data path in the network to provide the best possible data for analysis. In order to get the full picture of your network and applications, you need to monitor all key network links and hops.

Data collection from multiple points, though essential, does make analysis more complicated since you need to know which capture points are the key points for the problem you are analyzing. Multi-segment analysis alleviates this complication. Multi-segment analysis is a post-capture method that automates the process of analyzing network data from multiple network segments and/or multi-tier applications. It compiles and correlates just the data you need in a single view so you can easily pinpoint where anomalies are occurring along the data path, from the client to the server and back.

The Virtual and Cloud Factor
Virtualization introduces new challenges both in monitoring the physical network, and application performance. Even with this complexity, the fundamental analysis techniques are still valid: a capture only has to be in the packet path between the client and the server to diagnose the problems, even if this path is virtual.

We just covered this topic in detail in our last blog post. Click here to read.

If you are working with fully hosted cloud-based applications, your flexibility for monitoring data on the Cloud side of the application is very limited, and most likely non-existent. The key here in terms of application performance is focusing on end user experience. If there are complaints about application performance, capture on a client machine and at the WAN ingress/egress point to see round-trip application performance as well as the performance of the specific client.

Reactive Analysis
If you are continually monitoring and assessing your network, you can quickly and easily spot issues before anyone complains. That said, most folks do not proactively monitor and instead wait for the complaint to happen – reactive analysis.

If this sounds like you, then the first step in discovering if it is a network or application problem is to turn to your favorite packet-based network analysis solution (we hope it is OmniPeek).

The next step is finding the best place to monitor the offending application. Remember, multiple analysis points along the path will make troubleshooting much easier with multi-segment analysis, but this may be impractical when in a reactive mode. It’s important to keep in mind where users are located, and whether it is a single user that is having problems or a broad range of users. If it is a single user, try isolating the network traffic for just that user to reduce the amount of data to be analyzed. If it is broad range, monitor closer to the application server and isolate your analysis to just the users of that application.

When the monitoring points are established, you can start collecting network data (packets). If you are sure that this is an isolated application issue, then filter as described above. But if you’re still not sure, widen up the data that you collect to make sure you’re not missing critical data.

If your network analysis system employs expert analysis, this will be an excellent guide for your problem search. Look at the specific types of expert events being logged and in what layers they are being reported. Problems arising in the application or server layer typically mean that the application is at fault. If the transport layer is implicated, then it may be your network.

Expert analysis may not always reveal the issue. In that case you need to go deeper and look into the overall packet bounce diagram for the network conversation in question. If the diagram indicates that user requests are followed by quick network acknowledgements (ACKs), but a delayed data response, then the problem is most probably with the application. Conversely, if the ACK is delayed or missing, then the network may be to blame.

Want to learn more about application troubleshooting? Let us know what you think we missed in this blog and what you would like us to cover next time for application performance monitoring. Also, if you already use our products, we have tons of videos on how to troubleshoot applications. Check out all our video tutorials on our YouTube channel.

Preventing Bandwidth Issues

First, a quiz: In the following scenario, do you think this is a network, device or application problem?

Users are continually experiencing garbled and choppy VoIP calls, Internet connections are slow, and you are receiving complaints of poor video quality.

If you answered network bandwidth issues, you are correct. With video becoming the primary data type on networks of all types, it’s a lot easier for networks to become strained and overused, and often not by mission critical traffic.

If you are consistently experiencing these problems, here are some helpful steps to take to prevent bandwidth issues.

Step 1: Create a baseline
It’s always important to know what your bandwidth needs are based on the number of users and the types of applications that are running on your network. Know who is using what, when, where, and why in regards to network segments. This will help you understand the overall demand on your network and allocate bandwidth appropriately. It will also allow you to quickly determine when network usage is exceeding norms.

If new applications, new users, or new devices are introduced be sure to reevaluate your baseline usage.

Step 2: Prioritize critical business applications and tie baseline protocols and usage to those applications
Each network segment may have different protocol priorities because of the specific applications that traverse those segments. Top applications need to be handled based on business importance for the segment they are individually on.

That said, even if you prioritize your business applications, any protocol that is not performing well could affect overall application performance. In order to determine what application might be causing problems, it is essential to have a network analyzer that can break down and show individual flows and their performance. The network analyzer can provide visibility into the weakest link as well as options to sort application flows with various criteria choices.

Step 3: Use packet shaping technologies
Packet shaping allows you to prioritize certain network traffic, like key applications or real-time data (like VoIP) over other, less critical traffic on your network. For example, if you run an online store that is the backbone of your business, HTTP traffic to and from your web servers is critical. Packet shaping technology can give this traffic priority over everything else, ensuring the best possible user experience for your online customers.

Step 4: Prune your protocols/traffic
Most corporate networks have unnecessary traffic which can consume precious network bandwidth needlessly. Check for protocols that may no longer be necessary on your network, or that could be network hogs, like SNMP, to determine if they still have a purpose or if they are being misused. If they are no longer mission critical, make sure your packet shaping technology treats this traffic with the lowest possible priority.

Along with continuously pruning your network, be sure to constantly monitor your network. The best monitoring solutions will allow you to archive packet data to disk, providing a complete recording of network activity. When your monitoring solution indicates problems, simply “rewind” your network to determine exactly what the issue is. Whether it’s a surge in web-based sales due to your latest promotion, or employees streaming the Stanley Cup playoffs, it’s up to you to know what your network can handle, and up to your network monitoring and analysis solution to let you know when bandwidth issues are about to occur.