Network monitoring: Tools of the trade

Everyone is talking about the cloud. The Wiki definition of the cloud is: “the delivery of computing as a service rather than a product, whereby shared resources, software and information are provided to computers and other devices as a utility (like the electricity grid) over a network (typically the Internet).”

The key here is “over a network, typically the Internet.” Okay boys and girls, how many times has the Internet failed you at the very moment you needed it most? This has likely happened more than once.

Despite this major challenge, the cloud is being pushed because of varying advantages, such as lower cost of ownership and streamlined management. But in our world of industrial software and control, our networks are mainly local, or at least in the same city.

Various issues with our networks, as well as devices on that network, can create many sleepless nights for us geeks. But there are some technologies, companies and products that can help us deal with the influx of IT into our space, so that we can better understand and manage our sandbox.

Ethernet is an old technology. Bob Metcalfe was the architect behind it, and I’m sure he never envisioned the pervasiveness of this networked technology. However, it is not without its trials and tribulations, and that’s why we need to know some basics and have access to tools.

Internet Control Message Protocol (ICMP) is a collection of commands that are used by the network and the devices to locate and to prove some level of communication. The most common component of the ICMP command set is ‘PING,’ but I can tell you that the response needs to be understood.

Imagine going into a network and not knowing what devices are attached, and what addresses are used. Pinging an IP address at a DOS prompt (C:ping 10.11.0.241) will give you some indication if a device is responding to the “echo request.” Beware that some devices have the echo reply turned off. Also, the computer you are using may have the firewall ICMP requests turned off, so the request may not even go out onto the network. Imagine what fun that could cause.

PingPlotter (pingplotter.com) is a very cool, free tool that traces and maps the devices that the ping requests go through before reaching the destination. The graph it provides tells you where the slow spots are. With wireless networks, there can be many reasons why something goes awry!

You can trace devices using a web address or a network IP address. The response can tell you if the IP setup is correct, and if the delays from source to destination are tolerable. This is especially important in a wireless environment.

A very cool feature is that you can set up an alert system to monitor multiple IP addresses for excessive ping responses. This can be very useful when trying to track down a time-based event, such as a broadcast storm, which occurs each morning, but the timing is unknown.

Solarwinds has a free product that allows you to test a full subnet, and the results can tell you not only who is out there, but the typical response times received from the device. While both products provide the DNS name of the device, Solarwinds matches the IP address with the DNS for you for the whole subnet.

There are other tools that can dovetail into the IP tracker. Some of these may come at a cost, but could still be very useful.

You can also add subnets and have the IP address tracker scan all subnets and display the results. This makes efficient use of your time. If there is one address that seems to be slow in responding, you can then use PingPlotter to investigate further.

IP address tracker uses SNMP (Simple Network Management Protocol) to interrogate devices. This protocol supports data fields that are set up on the devices themselves, which can include such things as thin clients, PLC routers, switches and SCADA computers. If the device can respond to a SNMP message, then it has the ability to have all of the information listed in the device and thus displayed in the tracker table.

Primitive, perhaps, but ping and the associated information can be most helpful.

Be aware, however, that it isn’t the answer to all. Ping proves the setup and connectivity of the network, and the routing tables of any traffic cops (routers/switches) on your network. It does not suggest that the connected devices can, in fact, respond to any protocol requests.

There are many reasons why you would be able to ping a device, but not be able to talk to it. My next column will dig deeper into this and other aspects of network monitoring. Stay tuned.

This column originally appeared in the January/February 2012 issue of Manufacturing AUTOMATION.