×

UNMS - Troubleshooting

Overview

This article addresses the most common issues related to UNMS and provides instructions on how to solve them. To contact the UNMS support team, and to send them your UNMS support info please create a support request with the following details:

  • Kind of help: technical support for my Ubiquiti device or software
  • Product line: ISP / UNMS > UNMS & CRM > UNMS (your particular hosting instance, either option will put you in touch with the UNMS team).
  • The rest of the fields you will fill out according to the issue you're seeing
  • Attach your support info to the request (if applicable)
NOTE:  If you already have an open ticket about your issue, you can just reply to the last email you received from our support team and send the support info or any other additional information and requested files.

Table of Contents

My UNMS doesn't start

Back to Top

UNMS is run in docker containers. For that reason, the first step should always be to check on those containers by running the sudo docker ps command. If the Redis container is restarting then it is worth trying to use the appendonly.aof file fix. In case, another container is failing, please go to the /home/unms/data/logs, download all files and attach them to a support request as described in the Overview above (or send them as a reply if you already have open ticket).

My device cannot connect to UNMS

Back to Top

Check if there is a clear route from the device to UNMS. Use SSH to get into the device, and try to ping the hostname of the UNMS server. If the ping cannot go through, there is a network issue either in the device's configuration or on the route from the device.

Here are some commands that can be used to get more information about the network issue. Please note that some of those commands may be inaccessible on some devices. Replace the <UNMS hostname> with the actual hostname of your UNMS server:

Traceroute from the device to the UNMS server:

traceroute -n <UNMS hostname>

Check if the connection is upgraded to WebSocket:

curl --insecure --include --no-buffer --header "Connection: Upgrade" --header "Upgrade: websocket" --header "Host: example.com:80" --header "Origin: http://example.com:80" --header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" --header "Sec-WebSocket-Version: 13" https://<UNMS hostname>/

The output should look like this:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: qGHgK3En71di5rrssAZTmtRTyFk=

db332780afad264425162cb11d19ffd1ac9ad3658f63cb56968a8a2592054a39aac950bcdae301e39eea75f28c7d3e7dd32a568f0fcf67f25b692434c825ffc7d13b7f8bcec1fb649919d784723f039ef50deb939eeb2b1bd602f56339ac20b65b3

My devices' connections are flapping

Back to Top

NOTE:  A flapping connection occurs when the device is repeatedly switching status from "Active" to "Disconnected", often within a narrow time frame.

As a first step, it is necessary to find out if the flapping is being experienced by the customers as well. If they are getting outages of internet service, then UNMS is reporting the actual status just as it should. If customers report stable connection then the flapping is most likely caused by devices having issues connecting to the UNMS server correctly. The two most common reasons for that are network issues and overload.

  • How to verify if it's a network issue: SSH into one of the flapping devices and run at least one hour long ping pointed to the hostname of the UNMS server. Save the ping's outcome and check if there is any packet loss and/or latency over 400ms. If there is any packet loss or high latency then the flapping is caused by the network instability. For the UNMS Cloud instances, please contact us as described in the Overview of this article, and in the Description let us know where the flapping devices are located (the country is sufficient).
  • How to verify if it's an overload issue: Check both the UNMS server and the device for CPU and RAM load. For the UNMS Cloud instances, please contact us as described in the Overview of this article, and in the Description let us know we need to check the load on the server. The device can be checked with the top command. 

Suspension / Traffic shaping is not working

Back to Top

For all advanced network features, UNMS needs to know which IP address should be suspended/shaped. It is possible to check if the UNMS knows that IP by opening the Client Sites view and making sure the IP address column is visible. If there is an IP address value for a specific Client site, then suspend/shaping should work for that IP. In case the desired IP address is not present in that screen then:

  • Make sure that the desired IP address is not also the management IP address of the device. This is mostly relevant for devices in the bridge mode since those devices often have only one IP and it is the management one. To solve this situation it is necessary to either connect a Ubiquiti device downstream from the CPE, add that device to UNSM and then Suspend/Shape its IP address, or create a 3rd party device in UNMS with the static IP address of the Client's downstream device. Please note that this will not work for 3rd party devices with dynamic IP.
  • Check the Settings > Network > Monitored IP subnets. The desired IP has to be in the range of this setting. 

NetFlow is not working

Back to Top

Please note that there are two places where NetFlow is displayed. In the CRM module within the Client dashboard, and on the dashboard of a Client Site (at the top left corner of the traffic graph). For NetFlow, there are the same rules as for the other advanced network features (suspend, shaping). UNMS has to know which IP to measure and that IP needs to be assigned to a specific Client Site and has to be within Settings > Network > Monitored IP subnets range. Also, it is necessary to configure at least one router to provide NetFlow data to UNMS. The ideal device for this is the main gateway since in most networks all the data is going through it. In case of issues with NetFlow, it is necessary to make sure that the router is sending Netflow data to the correct IP address and port. In our NetFlow article, there is a generic troubleshooting guide on how to perform that check.

Was this article helpful?
6 out of 7 found this helpful
Can't find what you're looking for?
Visit our worldwide community of Ubiquiti experts for more answers
Visit the Ubiquiti Community