Challenges arise when the organisation develops a culture of suspicion around the network as a whole meaning it becomes the first port of call when a problem occurs. In an app-centric environment, IT Pros must work to identify problems that are caused by individual applications running on the network. Memory leaks, poor design and large content can all cause an application to fail, yet many are slow to realise this.
There are, of course, occasions where the network is at fault. Perhaps there isn’t enough bandwidth provisioned for the WAN, high latency has thrown up problems, or simply non-business traffic is hogging the bandwidth. The health of network devices, configuration mistakes or route flaps can also lead to problems with application performance; all of which are related to the network.
That said issues with the database, operating system or the hardware itself are commonly overlooked by IT Pros, which can lead to long delays in getting to the root cause of the problem. Last but not least, the application itself is often the main culprit for the unsuspecting IT Pro. Unfortunately, it can prove difficult for the network admin to convince the application developer or systems administrator of these issues, meaning that regularly, network admins can end up locked in a time consuming blame game.
Don Thomas Jacob, Head Geek at SolarWinds has some helpful tips on how to solve the issues which arise as a result of poor application performance. Here a few of the common accusations developers and IT Pros make and how network admins can be prepared to refute them.
“The network is too slow”: As soon as the network is accused of poor application performance, the network admin should start with Simple Network Management Protocol (SNMP). A robust network monitoring tool will check the health and status of your network devices. When monitoring your routers and switches with SNMP you achieve visibility on route flaps, packet loss, an increase in RTT and latency. It also provides lots of other useful information, such as letting you know if the device CPU or memory utilisation is too high.
Questioning QoS priorities: Using a monitoring tool that supports Cisco CBQoS reporting, you can validate the performance of your QoS policies. – It is useful to obtain the pre and post policy statistics, or the amount of traffic is being dropped for each QoS policy and class. If your QoS policies are working, what else could be causing the problem?
Is there enough bandwidth?: NetFlow data from routing and switching devices can report on bandwidth usage to tell you how much of your WAN link is being utilised. In addition to this, you can dig a little deeper and find out which applications are using it, what end-points are involved, and report on the ToS priority of each IP conversation.
Can your WAN link handle my app? Cisco IPSLA can send synthetic packets over a network path and report on the capability or the readiness of the link to handle IP traffic with TCP and UDP protocols. This is especially useful when one needs to analyse how VoIP and video would perform over a link. Using this information, the network admin can ask the question “if the synthetic packets generated by Cisco IPSLA to match the application protocol can be handled, why not the actual application traffic?”
Deep Packet Inspection: For the network admin who likes to go the extra mile, the answer is deep packet inspection (DPI). The visibility that DPI provides is virtually unlimited – throughput information, out of order segment details, handshake details, retransmissions, and all the information you will need to prove the network is the innocent party, and also to find the actual cause for poor app performance.
With the right technology and tools, the network admin can prove that the network is not at fault. But equally important is being proactive and ensuring that the important network nodes are being monitored with a good monitoring tool and that critical applications have priority in the network. Monitoring helps you detect and solve small issues before they become a major problem and prioritisation ensures application data delivery. It also means that the IT Team ‘blame game’ becomes a thing of the past.