Hello,
We’ve recently encountered issues with the discovery and backup functions in Unimus on several switches from different manufacturers.
We don’t understand the root cause, as these devices share the same configuration, IP range, and access rights as others that are working correctly.
The SSH account is valid on each device, firewall rules are properly configured, and there are no ACLs on the switches that could be causing this issue.
This problem has been occurring for about 1–2 months, but the investigation took some time, which is why we’re now opening a support ticket.
Thanks in advance,
Dina
[Solved] Last Job Status Error : Unimus
Hello,
Are these issues permanent or intermittent?
Are these issues permanent or intermittent?
- For example, did they used to work fine before and now they don’t work at all? If so, do you recall if anything changed around the time they stopped working?
- Or do they work inconsistently — sometimes working, sometimes not? For instance, do scheduled jobs fail while manual triggers still work? Or even manual jobs sometimes fail?
-
[email protected]
- Posts: 3
- Joined: Mon Oct 13, 2025 11:43 am
Hello Jozef,
The devices were working correctly about 3–4 months ago, but suddenly they stopped responding to Unimus connection attempts. However, no configuration or rule changes have been made regarding these devices.
On the firewall side, the rules apply to the entire subnet, and within these subnets there are other devices managed by Unimus that are still working properly.
The account configured in Unimus for backup connections has been tested on each of these devices and is functional. Network flows have been checked end-to-end to ensure there are no blocks or other issues, and nothing appears to be wrong on the network side. In the network logs, we can see “server-rst.”
On the Unimus side, the error is :
"Error: Could not connect to device
Discovery log:
Service check:
SSH: Service available
TELNET: UNAVAILABLE
Service connection:
SSH: CONNECTION_ERROR"
Kind regards, and thank you for your help!
Dina
The devices were working correctly about 3–4 months ago, but suddenly they stopped responding to Unimus connection attempts. However, no configuration or rule changes have been made regarding these devices.
On the firewall side, the rules apply to the entire subnet, and within these subnets there are other devices managed by Unimus that are still working properly.
The account configured in Unimus for backup connections has been tested on each of these devices and is functional. Network flows have been checked end-to-end to ensure there are no blocks or other issues, and nothing appears to be wrong on the network side. In the network logs, we can see “server-rst.”
On the Unimus side, the error is :
"Error: Could not connect to device
Discovery log:
Service check:
SSH: Service available
TELNET: UNAVAILABLE
Service connection:
SSH: CONNECTION_ERROR"
Kind regards, and thank you for your help!
Dina
Hi Dina,
Interesting, those server-rst packets usually indicate that either a firewall or the device itself is abruptly terminating the connection.
Could you please check if there are any logs on the device(s) related to login attempts from Unimus?
From what you described, it seems there’s nothing wrong on the network side and the devices should be reachable from Unimus.
Is there any chance a connection rate limiter or similar mechanism might be implemented in your network?
Interesting, those server-rst packets usually indicate that either a firewall or the device itself is abruptly terminating the connection.
Could you please check if there are any logs on the device(s) related to login attempts from Unimus?
From what you described, it seems there’s nothing wrong on the network side and the devices should be reachable from Unimus.
Is there any chance a connection rate limiter or similar mechanism might be implemented in your network?
-
[email protected]
- Posts: 3
- Joined: Mon Oct 13, 2025 11:43 am
Hello,
We have a double Support request, we can close this one
Thanks for the work.
Dina
We have a double Support request, we can close this one
Thanks for the work.
Dina
I’d like to provide a short summary after the "issue" resolution:
The “issue” was caused by a failed authentication limit being reached on the device itself during the discovery process.
For scheduled backups, Unimus always performs a discovery task before proceeding with the backup to ensure it has the most up-to-date information about the device. During discovery, Unimus opens multiple consecutive connections to the device, depending on the number of credentials in Unimus and whether those credentials are bound to the device or set for discover. This behavior is described in more detail in our Discovery wiki article.
There are several ways to mitigate this issue:
* Increase the failed authentication limit on the device itself
* Bind credentials directly to the device
* Increase the unimus.core.inter-connection-delay parameter, as described in our Changing default timeouts wiki article.
Failed authentication or connection rate limits can also be configured on multiple elements within the network, such as the devices themselves, firewalls, security gateways, or AAA providers like RADIUS or TACACS+.
The “issue” was caused by a failed authentication limit being reached on the device itself during the discovery process.
For scheduled backups, Unimus always performs a discovery task before proceeding with the backup to ensure it has the most up-to-date information about the device. During discovery, Unimus opens multiple consecutive connections to the device, depending on the number of credentials in Unimus and whether those credentials are bound to the device or set for discover. This behavior is described in more detail in our Discovery wiki article.
There are several ways to mitigate this issue:
* Increase the failed authentication limit on the device itself
* Bind credentials directly to the device
* Increase the unimus.core.inter-connection-delay parameter, as described in our Changing default timeouts wiki article.
Failed authentication or connection rate limits can also be configured on multiple elements within the network, such as the devices themselves, firewalls, security gateways, or AAA providers like RADIUS or TACACS+.