Envisioning Network Visibility
Network visibility continues to be a topic of interest to IT decision makers. The reason is simple. Everyone believes (correctly) that their networks have unseen problems. The follow up question though is what to do about the problems and how big are they, i.e. you don’t know what you don’t know, right? This is especially true as the data network has become more and more complex and IT’s mandate now is to deliver the best possible customer experience. IT needs this information to get a clearer view on how to optimize the network and reduce inefficiencies.
Seeing The Blind Spots
So where do you start? The first thing is that you need to be able to see the problem to fix it. This is hard when 85% of typical mean time to repair (MTTR) is spent just trying to identify that there is a problem. Maybe you see indications that things aren’t working as expected in the network, but is there truly a ‘problem’ within the network or was there an error in the architecture design? Maybe it’s nothing?
This is where a visibility architecture really shines. Once you insert the proper visibility components, you get a true picture that helps you get past the issue of is there a problem so you can focus on fixing any problems that arise and eliminating future problems. Faster responses to problems result in a shorter mean time to diagnosis and a corresponding faster MTTR. For the IT department this is critical as MTTR is directly related to costs and is often a KPI metric in some form (whether it’s MTTR directly or maintaining Five 9’s reliability) for their annual department and corporate goals.
A visibility architecture allows you to step back and take a holistic look at your network. What monitoring information do you need? Where should you collect that information within your network? And what’s the best way to consolidate the information you have so that you can deliver the right data to the right monitoring tool at the right time?
Proper system visibility empowers IT with these three pieces of information:
- What’s happening now?
- What happened in the past?
- Where do potential problems lie?
Creating A Visibility Architecture
A well planned visibility architecture will start off by adding taps, network packet brokers (NPBs), and monitoring tools. This can be done for both the physical and virtual infrastructures. Just by adding the taps and NPBs you can reduce your MTTR by up to 80%. The reason is simple. You’re no longer trying to get the right data to determine the problem. You have all the data you need now and it is simply a matter of delivering the right data to the right tool at the right time. When trying to improve your MTTR, most improvements will depend upon how fast you can access the right information. This is where an NPB will help by minimizing confusion, minimizing the processing time to get good information, and maximizing (through deduplication) the reduction of extraneous information. This approach to a visibility architecture allows you to react to problems as quickly as they appear and resolve them.
The next step to take is to implement an inline visibility architecture. Instead of the taps, NPBs, and tools being placed out of band, all three sets of components are placed directly in the path of traffic within the network. This approach allows you to be able to react in real-time to performance issues and security threats. Access to the data is immediate. While some IT staff may see this as riskier than the first approach, the risk is minimized by using hardened, special purpose taps and NPBs that are designed for inline usage. These devices have integrated fail-over scenarios built into them. Once implemented, network uptime can actually be improved with this approach because new fail-over scenarios (like high availability and redundancy) are available. These new scenarios improve network uptime, network security, and network performance.
The third step you can take with a visibility architecture is to implement proactive network monitoring. A proactive approach focuses on implementing preventative measures to eliminate potential problems before they happen. By using agents, simulated traffic and a monitoring interface, you test and observe the network to understand how it is performing. This functionality can validate service level agreements (SLAs) and perform customer experience monitoring for a wide range of applications including voice, video, web services, and critical enterprise applications. The goal is to ensure that the infrastructure is capable of delivering an amazing customer experience 24x7, even when there is no user traffic on the network to monitor.
The intent of all three of these approaches is to increase system visibility because what you don’t know—can and will hurt you at some point. The exact approach you should pursue for your business naturally depends upon the experience of your staff, the quantity of staff you have, and the priorities of your business.