Network Operations team are always in the line of fire. I’ve been working in this arena since my early years, and I’ve seen how we are center stage for every event and every issue. During a triage or an outage, we’re under pressure to provide a solution and an answer. The trading floor is losing money and they are relying on us to fix it. Naturally, we turn to our network monitoring tools to collect all the critical traffics and data to help isolate the issue and provide the resolution.
My network monitoring tool gives me the top talkers, critical applications and all the critical TCP metrics. My tools tell me a particular host is showing high retransmission, out-of-sequence problems and degradation. However, when I drill further down to the packets, I discover that I’m seeing duplicate traffic and missing packet counts.
Now that’s a wasted effort! This is a very common issue I see again and again across firms and businesses. Often, when deploying a network monitoring solution, there is not enough emphasis on the architecture and design phase. SPAN sessions may be oversubscribed, duplicate traffic missed overlooked or misconfigured on the aggregation tap. Many think that when you have a monitoring solution instrumented, it is up to the tool to figure this out. In reality, the architecture and design phase needs to be executed correctly! Only then should you move to the tuning phase for the tool.
There is nothing more frustrating than relying on a tool that has the wrong information. It produces false positive alerts and red herrings. It defeats the purpose of having a monitoring solution as it creates more confusion than resolution, and leads quickly to the blame game: Is it the SPAN session? Is it the monitoring tool that is broken? And so on.
The architecture and design phase is critical when it comes to a network monitoring solution deployment. Don’t overlook this step of the deployment process, and ensure you are getting the proper ROI on your next purchase.