When it comes to network monitoring, you'll no doubt have some kind of configuration or firewall to guarantee the security of your network from outsiders. When a network becomes too tightly secure, it can produce unintended side effects that may go unnoticed for a long time. These side effects may look like broken communication between an RTU and a master station, broken communication between your computer and an RTU, and not being able to upgrade the firmware using FTP

Not everyone may understand the lingo of networking, but whether you're a field technician or a networking technician you need to know what's going on with your network. As experienced remote monitoring experts, it's our role to help you to understand what may be blocking essential traffic through your network and how to alleviate the blockage.

In this article, we'll cover 3 common scenarios of networking and communication issues and how to solve each one. While an issue may arise due to damaged or faulty equipment, we'll assume that all units are in good working order, and what isn't working is network communication. So, let's dive in.

Scenario #1: T/Mon No Longer Polling NetGuardian

Problem

You log in to your T/Mon one morning only to find that your NetGuardian isn't being polled and has been shown as offline for hours. You're unsure of whether some network maintenance occurred overnight, so you want to be sure that the site is still up and running. You navigate to your NetGuardian's IP address in a web browser and see that not only is it online, but there are no alarms reporting. What gives?

Solution

Your first thought might be to send someone out to the remote site, or even decide the unit is faulty or misconfigured. But a few steps can be taken to ensure proper connectivity, and if you own a T/Mon, verifying network connectivity becomes easier than ever! We will test a series of ports to find our which ones are open and which ones are closed.

When it comes to polling a NetGuardian with a T/Mon, we first want to ensure that DCP traffic is allowed on your network. Since you can access your NetGuardian's web interface, it's safe to assume that port 80 (or port 443 if you're using HTTPS) is open and traffic is allowed.

The default DCP port is 2001, although this is configurable within the NetGuardian. When polling a NetGuardian, let's first determine that the DCP port of the NetGuardian is, in fact, the port the T/Mon is using to try to talk to the RTU.

To do this, login to your T/Mon's "Edit Mode" in the browser of your choice. Then using the left-hand navigation menu, click on "Devices". From here, it's recommended that you use the Quick Search at the top of the tree view if you know the name of your unit. Otherwise, click the "+" button to the left of the tree list item to drill down to your specific device.

Note: The device's name is shown in Monitor Mode under the "Site" column. If you cannot see this column, right-click on the table header and make sure "Site" is enabled.

Once you've located your device in the device tree, double-click the device. This will take you to the configuration of the selected device. On this page, there are 4 critical components to verify: the IP address, the DCP port and Unit ID, and the "Disable Polling" checkbox.

Note: seeing "IP Failed Ping Test!" next to the IP Address' field indicates that something may be blocking ICMP traffic. Alternatively, seeing "DCP Failed Poll Test!" underneath DCP Protocol indicates that te Unit ID or Ports don't match the NetGuardian, or that DCP traffic is blocked on the network.

Once you've confirmed that the Unit ID and the DCP Port match the settings of your NetGuardian, you can use the button underneath the settings labeled "Test DCP/IP" to test your settings.

There are a few scenarios that you may encounter at this point:

• 1. IP OK! and DCP Failed Poll Test!
• 1. IP Failed Ping Test! and DCP Poll OK!
• 1. IP Failed Ping Test! and DCP Failed Poll Test!

This issue can be very common for devices that don't use the default DCP Port. The reason being your network technician is prepared to open port 2001, but that's not actually the port the devices are set up to use on your network, causing complications.

The final step on this page is to verify taht the checkbox at the bottom of the "System" tab is unchecked. When this checkbox is checked, polling is completely disabled for your device.

If you're still unable to poll your NetGuardian from your T/Mon, communicate to your network technician that there is potentially a restriction that's keeping your devices from communicating, causing blind spots throughout the network.

Scenario #2: Upgrading Firmware via FTP

Problem

After a few years of owning your RTUs, you want to check if you're still on the latest firmware. You go to our firmwrae downloads page and notice that you're behind by a couple of releases. You then download the latest firmware for your devices and want to install it right away. You don't want to dispatch techs to multiple remote sites knowing this will cost your company time and money. So you attempt to upgrade your devices using FTP.

Some kind of error shows up saying FTP can't connect, so you verify the device is still online by logging into your RTU in a browser. You then attempt to ping the unit, yet find that you're receiving responses back from the unit. This can sound like good network connectivity, but what actually happens are few ports are blocked, keeping your suspicion low about your own network.

Solution

At this point, being able to both ping your RTU and access the web interface in the browser is a positive sign. It not only confirms that you have visibility to your remote site, but also verifies communication between your host computer and your RTU.

Now, having never used FTP on your network, a technician may have thought to block FTP traffic entirely since it's not being used. In companies of 100+ employees, it can be difficult to communicate this change with everyone.

If you have a computer with the Windows operating system, you can open the Start Menu and search for "cmd.exe". This opens the Command Prompt application. In the window that opens, run the following command:

ftp <ip_address>

If you do not get a 220 status code, FTP is blocked either by your computer's firewall, or by your network entirely. At this point, you will need to contact an administrator to gain access to changing these rules to allow FTP traffic on the network. After doing this and enabling FTP on your network, go ahead and attempt to upgrade your firmware again.

For a step-by-step tutorial on upgrading RTU firmware via FTP, you can follow this guide.

Note: Newer devices do not have a companion NGEdit application. Upgrading firmware is done in the browser by navigating to your NetGuardian's IP address, and then clicking "Upload" in the top-right corner of the page.

Scenario #3: SNMP Notification Not Sent

Problem

When pairing our RTUs with a T/Mon, it's not likely you're using SNMP to communicate, but rather a protocol called DCP. However, if you use our RTUs with devices from other companies, you'll likely need to set up SNMP notifications on your RTU in order to log events coming from your remote sites.

Note: If you're using SolarWinds, be sure that the Trap Summary widget is visible on the Dashboard. Alternatively, you can navigate to "Alerts & Activities", then "Traps"

Imagine that one hot summer day, you sent a technician out to one of your sites to install a new piece of gear and they are setting up SNMP to communicate with your master station. Conveniently, you receive a high environmental temperature alarm and expext to see that alarm from your master station, but after many page refreshes and time spent troubleshooting, you discover that the notification was never sent.

Solution

The first things you'll want to check when experiencing issues sending or receiving SNMP traps are the SNMP version you're using (v1, v2c, or v3), and whether your community strings match. You can think of the community string as a passphrase—both your RTU and master station must use the same passphrase when communicating with each other.

Alternatively, your RTU might be sending SNMP v2c notifications, but your master station is expecting to receive an SNMP v3 notification. If that's happening, you will likely encounter an inability to receive that notification and process it normally.

Whether or not you're using DPS RTUs, it's always important to refer to your device's user manual for setting up SNMP. After you've verified that these settings are correct on both your RTU and your master station, you can test configurations effortlessly. The quickest and easiest way to test the sending and receiving of SNMP notifications on your network are by using a PC and a MIB browser.

Note: It is preferable that your PC and RTU are on the same network when testing SNMP. This not only verifies that your RTU can send SNMP notifications to begin with, but greatly simplifies the complexity of the network between your PC and the RTU.

All you need to do for this test is to set your SNMP manager's IP address in your RTU to point to the address of your PC, and set the Trap Port number to 162. From there, you can pick any alarm point and reverse the polarity, causing a notification to send immediately.

If you still cannot see the notfication on your PC, your device may report that the notification hasn't been sent. The combination of these circumstances may be a clear indication that port 162 is blocked on your network, disallowing SNMP traffic.

The Bottom Line

As remote monitoring experts, our goal is to share in the knowledge we've accumulated over the 30+ years to help you get better visibility over your system. So, in this article, we covered three common scenarios where a network may cause communication issues due to tightened security and firewall rules, and how to safely allow traffic without compromising the security of your network.

As always, if you have any further questions, feel free to reach out to us or you can also schedule a time where one of our team of engineers can visit you and do on-site setup and training. We'd be happy to provide you with a perfect-fit monitoring solution.