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:
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.
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.
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:
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.
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.
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.
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.