For years, network performance monitoring has been limited to the ICMP and SNMP polling of devices. A simple ping of the devices allowed us to gain insight into the availability of the device over time as well as give us some indication as to the responsiveness of the host. If the device didn't respond to a ping, a notification was fired off and people went running or at the very least, started making phone calls.

Overtime, however, we have come to realize that a simple response to an ICMP request is not a tell-all indicator as to the overall health of a device and certainly not terribly insightful as to the responsiveness of the business applications passing through the hardware. Then, along came TCP pings and service checks.

Network Traffic Monitoring

Network performance monitoring took a turn for the better when numerous network traffic monitoring solutions started performing TCP pings to verify availability on specified ports. Other monitoring tools were granted administrative rights to start performing service checks. The days of relying on ICMP taught us that servers can be up and running, responding to ping, but still not be servicing actual application requests. Routine Microsoft services checks and Linux process verifications have certainly been a better indicator of overall critical application availability and responsiveness, but today we can do better.

Most end users of an application have experienced intermittent performance issues and even noticed that their individual experiences with a specific app can be very different from the person in the cube next to them. In other words, what one user is experiencing is not indicative of the whole flock of people interacting with the same business application. In fact, a single user compared to a group of end users could have an entirely different performance experience using the same application for the exact same types of tasks. End system hardware, operating system, network connection, etc. can all play a very significant role in the end user experience with a specific application.

Monitor Bandwidth

Fortunately, network performance monitoring has evolved and it's largely because of metrics exported in flow technologies and the reporting available in NetFlow and IPFIX collectors. Most companies use these flow technologies to monitor bandwidth, but with the introduction of Flexible NetFlow they are capable of much more.

Technologies such as Cisco Application Visibility and Control have dramatically increased our situational awareness enterprise wide. The network performance monitoring capabilities extended by Cisco AVC flow exports provide insight into the connections made by every host on the network, but only the best NetFlow analyzer solutions provide Cisco AVC support and the details include reports on, but are not limited to:

  • TCP response times for the client, server and application
  • TCP retransmit counts as well as metrics on packet size
  • URL and HTTP Host details which can be very useful for cloud applications

With the above metrics available in the latest Cisco IPFIX exports, administrators can leverage their network performance monitoring solution to gain insight into the poorest performing subnets and then drill into identify specific hosts. Once specific hosts are identified as suffering from sluggishness, different reports can be run to determine if the performance problems are caused by packet loss or retransmits - let alone end system issues.

NetFlow and IPFIX technologies have made monitoring a network easier than ever as long as the helpdesk is given the right tools and training on what is possible with these technologies.

Leader in NetFlow

If you have further questions, reach out to Plixer, a leader in NetFlow reporting.