You might be a network junkie or a Cisco pro that has spent tons of time configuring range of network hardware to create complex interconnected networks. And you may have spent an equally extensive time troubleshooting myriad of problems in your organisation’s network infrastructure. But there is a strong possibility that your network troubleshooting is incomplete. Read on to find out how.

Network engineers are tuned to address issues related to configuration, congestion, and outages. Talk about a performance issue (the grey between the black and white) with them and they start to raise eyebrows. All that matters to them is the state of their network: hardware configurations, routing tables, node status, etc. Anything beyond these fundamentals does not seem to be in their checklist. And that is why they go bonkers whenever an IT user complains of slowness and blames the network. For the network administrators, the network state is stable and everything seems to be fine. So they point towards the system administrator for a possible issue in the database, application or the server hardware. On the other hand the system administrator claims everything to be fine at his end too. He uses the fact that other IT users are able to use the services as a proof that the issue must be in the network. The usual blame game thus starts.

Here is where both of them are wrong: they need to come out of their functional silos. Data communications is not composed of one layer only. The OSI communication stack is comprised of 7 layers. And this is why it is important to think of the data communications happening over your network in the perspective of all 7 layers. This means you need to have visibility beyond your network layer (Layer-3), into the Transport layer (Layer-4), and up into the Application layer (Layer-7) as well. Network engineers need to step up their mindset from their current network-usage level to network-performance level. They need to think beyond the fact of what traffic is flowing on their network to how that traffic is flowing and what is being experienced by that traffic.

Traditional NMS platforms are fine when it comes to monitor the network state. But they fall short when you need to evaluate the network performance with respect to applications. Rather than relying on just the SNMP polled node statuses, network engineers should develop ‘packet analysis’ skills which are highly valuable at time of hard-to-diagnose performance issues. Packet analysis requires the ability to inspect the raw protocol data inside the packets that are part of the data traffic flowing over your network. You would need a packet analyser (also known as packet sniffer), which is a tool (a software or hardware) that can log, parse, and analyse traffic passing over a network. As data flows over the network, the packet analyser receives the captured data packets and decodes the packet’s raw data revealing the values of various fields in the packet (e.g. TCP header, Session details, etc). You can then analyse these values according to the appropriate RFC specifications to deduce whether the packet underwent any abnormal behaviour during its transportation between the network points. A popular, and free, packet analysis tool available is WireShark, an open-source packet analyzer used for network troubleshooting and analysis.

You could also consider investing in a deeper monitoring solution, e.g. an NAPM platform. An NAPM (Network & Application Performance Monitoring) platform goes beyond the analysis of raw packet data and performs advanced analysis based on algorithms and shows performance trends in graphs. It also stores the analysed data for a longer period of time, e.g. up to 1 year. Attend this free webinar to understand how an NAPM platform can help you identify network + application performance issues in real time. Register now.