The days of siloed IT infrastructures are quickly ending as services, applications and network components become more interdependent. IT infrastructures are becoming more complex and it’s falling on your shoulders to keep mean time to resolution (MTTR) metrics at a reasonable level.
Research shows that the average MTTR in medium-density desktop support centers is nearly 10 hours—but this doesn’t paint a complete picture of the problem.
Application performance and network uptime are essential to keeping a business afloat and network engineers must bring MTTR as low as possible—the only question is “how?”
There are four key components that every network engineer must walk through on the path to incident resolution:
Solving the problem isn’t often the point of contention. You know how to fix any number of networking issues—but you have to find them first. Awareness and root-cause analysis are the biggest hurdles you must overcome to reduce MTTR.
When employees are experiencing application outages or network downtime, the issue is pretty easy to spot. However, poor application performance often flies under the radar, which is why AppNeta calls slow application performance the new downtime. Reducing MTTR for even the most complicated performance issues requires a more efficient network design.
Out-of-band network monitoring solutions are more important than ever before. Every network should be equipped with strategically placed deep packet capture systems, network forensics and more. However, not all networks set these systems up for success. If you’re still relying on SPAN/Mirror ports to ensure these systems see all of your network traffic, your MTTR is sure to skyrocket.
We’ve discussed why SPAN ports pail in comparison to network TAPs in the past, but when it comes to MTTR the biggest problem is that SPAN ports run the risk of dropped packets. If out-of-band monitoring appliances can’t see every bit, byte and packet® of network traffic, you’ll have a tough time identifying the root cause of any network issues. With network TAPs as the primary means of connectivity, you can reduce MTTR by increasing your visibility into the network.
Network TAPs make copies of network traffic to ensure your critical monitoring appliances have 100% visibility. Placing these network TAP-connective monitoring appliances in critical areas of the network (for instance, on both the WAN and LAN sides of a critical application) gives you an easy access point for troubleshooting.
Rather than sifting through reams of data, network TAPs help you create checkpoints throughout the network for quicker issue awareness and root-cause analysis—leading to much lower MTTR metrics.
We can’t stress this enough—if you can’t see 100% of your network traffic, you’re going to have a difficult time keeping MTTR to a minimum. Connecting out-of-band monitoring appliances in today’s complex network infrastructures requires the reliability of purpose-built network TAPs.
Looking to add a visibility solution to your next deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do!
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.