Some Easy Tips To Improve Network Troubleshooting
According to the Enterprise Management Associates report, Network Management Megatrends 2016, IT teams already spend around 36% of their daily efforts on reactive troubleshooting efforts. This is for good reason. Network and application troubleshooting can be one of the most high-profile and aggravating activities for IT personnel. Pressure increases exponentially on IT personnel as problem resolution time increases, since it directly correlates to network and application slowness and downtime.
We have created a podcast and an ebook that provide suggestions on easy ways to improve your troubleshooting activities. Check out these two free resources and the short summary below to get some valuable tips to help you.
When looking at troubleshooting, this can be a large and complicated subject. For instance, what are you troubleshooting (the network, applications, damage from a breach, etc.) and what resources do you need (network statistics, log data, packet data, flow data, etc.)? Using a simplistic model, you can essentially separate troubleshooting efforts into four categories. The first set of problems (let’s say about 30% of all of your problems) can be solved by using SNMP to capture network data and statistics. The next 30% of problems can typically be solved by looking at flow data and by using packet capture information. The third set of problem, which is also typically 30%, may require flow data along with network and user rich metadata (device type, browser type, geolocation, application type and bandwidth, etc.). The remaining 10% will typically require time consuming deep packet inspection for detailed problem analysis.
The first thing you will want to do to reduce your troubleshooting time is to implement a visibility architecture. A visibility architecture is an end-to-end infrastructure which enables physical and virtual network, application, and security. Improved visibility is what truly allows you to optimize your network data capture and analysis techniques.
No matter what set of troubleshooting problems (or your exact split), you should consider inserting taps into the network between the network traffic flow and your monitoring tools (or network packet broker) to improve the quality of monitoring data and time to data acquisition. Once the tap is installed into the network, it is a permanent and passive device that gives you data access. This means you don’t have to ask your Change Board for permission to touch the network again. You touch it once to install the tap and then you are done.
A second activity to consider is the deployment of network packet brokers (NPBs) between those taps and the security and monitoring tools to optimize the data sent to the tools. This is where you can perform data filtering, deduplication, packet slicing, header stripping, and many other functions to optimize the data before it is sent to your tools. Just by implementing taps and NPBs, it is possible to reduce your mean time to repair (MTTR) by up to 80%. This is because a significant portion of that time reduction comes by the reduction (and probable elimination) of Change Board approvals.
The NPB (depending upon vendor) also enables a quick and easy way to perform application intelligence. This allows you to capture application level information, flow data, and rich meta data that can be used for troubleshooting.
The final benefit of the packet broker is data aggregation, filtering, and distribution to the right monitoring tools. The NPB makes it easy to funnel the right data to the right monitoring as soon as its available to make troubleshooting efforts as short as possible.
Network visibility solutions allow you to get a clearer picture (in a faster way) as to what is happening on your network. This allows you to reduce MTTR performance times. View the podcast on troubleshooting or read the book to get more information on troubleshooting activities. You can also click here to see a list of resources that also might help you, especially if you want more details of the various use cases described in the book.