Part 2: Network monitoring: More tools of the trade

Just to set the stage: My customer is a water municipality with 15 remote sites running local PLC control for some operations, along with some local control for chlorine and treated water. We are communicating with the mother ship using public network frequency 802.11A, which is high frequency Wi-Fi, but not necessarily private. The communication provider is Motorola.

The system had resident drivers installed that connected between the devices and the application code. It worked well…when it worked.

We found that regardless of the reliability of the wireless network, we had all kinds of issues with gathering data. Nothing we did improved the problem. Then, one day, everything blew up. The system stopped gathering data every five minutes, as it was designed to do. Instead, it was only gathering data once every 45 minutes because the connectivity between the server and the device was constantly being interrupted by “something.” I’ll reveal what we discovered later on in this column.

So what would you do if you found yourself in this situation?  

My previous column (January/February 2012) dealt with some very rudimentary tools to deal with device connectivity — Ping Plotter and SolarWinds IP Address Tracker. These tools provide you with basic features like “Are you there?,” which provides the cable, device power and the ability to communicate. What they don’t do is prove that you actually have true protocol communication with the device.

This month, I want to introduce you to SNMP and the devices that incorporate your network.
Routers, switches (not hubs), cabling and devices (wired and wireless) can all cause communication issues that can interrupt data traffic and cause operational failures, such as losing the connection between a PLC and programming software. Use of these devices brings up many questions: Is it copper cabling or fibre? Are you using plant-to-plant leased lines, the Internet or an Intranet? Is your control network separated from the office/user network?

So many questions!

One of the very primitive contributors to network issues is device accessibility. Is the device accessible? If it is, what is the response of that device? Check your network topology. How many switches, routers, cables and the like are between you and the device?  

If you don’t know the answer, you need a network diagrammer. And, since something may have changed since the last drawing, a real-time diagramming tool is needed.

So how can SNMP help?

It depends on the devices on the end, and the devices used in between. Take Netgear or Linksys switches, for instance. Cisco is the industry standard. Most software products know Cisco by default. Products such as those from Netgear or Linksys may not be known to network tools by default, so additional data for these devices will be needed. More on this below.
Level 1/2/3 switches, managed vs. unmanaged switches and smart switches reveal various levels of information about your network. You can Google each one to determine the range of information for each.

Never have an unmanaged switch anywhere on your network. That’s like having a cell user in a dead zone!

The types of problems that can pop up are as varied as the tools available to monitor and troubleshoot them. In the example in the first paragraph, the network was put into a state of disarray by a set of resident drivers from an older installation of hardware devices. We moved from a serial to Ethernet device server environment to a true Ethernet device. The drivers for the serial devices were removed, or so I thought. It seems they came back, and only at certain times would they interfere with the network traffic.

Where the confusion resided was in the tools we used. The owner of the wireless network had connectivity, but had no packet data trapping. We used Wireshark for that. We evaluated the local computer environment by using SysInternals TCPView. The standard toolset used in a product called IntraVue was ineffective.

Would SNMP have helped in this situation? We did set up the switches with SNMP and had SNMP traps set up, but with this particular problem, the results were not helpful.

We should always be prepared in our network world to use various tools for various problems. In a wired world, some things are easy. In a wireless world, not so much. But when push comes to shove, we should be able to handle 90 percent of the issues ourselves.

SNMP can allow us to map our network, trap errors and determine if we have a bad device, indicate inconsistencies due to bad cabling and/or connections, and find failed devices.

Each network aggregate device will have a MIB (Management Information Base) file associated with it, which allows an SNMP software interface to interrogate and extract status and connectivity information. It also allows the user to change values in the aggregate device, as well, if allowed.

Inside a MIB file are object identifiers. These are the specific variables that the aggregate device supports.

The tools available for monitoring these devices are varied. Next column, we will look at three in particular — SolarWinds, Foglight and Spiceworks.

This column originally appeared in the May 2012 issue of Manufacturing AUTOMATION.