You need to see DPS gear in action. Get a live demo with our engineers.
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.Reserve Your Seat Today
There are a variety of reasons the NetGuardian can fail to communicate with the T/Mon. Changes to your network firewall, and incorrect set-up on unit can prevent you from being able to successfully poll your NetGuardian from your T/Mon.
At the top of the screen it actually says "Device Polling Enabled" which means the T/Mon is trying to talk to the NetGuardian, but we know T/Mon isn't successfully communicating with NetGuardian because we're receiving a "device failure" alarm notification in the T/Mon.
If you're able to ping the IP address of the NetGuardian but the DCP poll tests fails, we recommend repeating the "Test DCP IP" test again, to rule out a possible poll failure due to heavy traffic going across your network.
This is going to bring up debug filters. For the "DCP Poll Test Fail" issue we're currently troubleshooting, we're going to be using the DCP debug feature. DCP is the DPS internal proprietary protocol that our devices use to communicate with each other. When the T/Mon polls your NetGuardian, the T/Mon sends a request and expects a response back from the NetGuardian. When you turn on DCP debug you should see the requests come in from the T/Mon and then the response go out from the NetGuardian.
If you notice no traffic coming into the NetGuardian,there's one of three possible reasons why this could be happening:
If you're in front of the NetGuardian, you'll notice the LEDs on the front of the unit while it's rebooting. The LED's will blink red/green while rebooting, then solid green, and red when the reboot is complete. This is beneficial when you have multiple NetGuaridans in a rack, you'll know exactly which NetGuardian is rebooting.