...
The discovery mechanism works in stages:
Detect available connector
All available ports for all enabled connectors are checked. More info in Connectors and ports.
Secure connectors are always preferred to insecure connectors.
For example, if a device is available over both Telnet and SSH, SSH will be used.
Detect credentials
Credential discovery works differently depending if the device is set to "Discover" credentials, or has "Bound" credentials.
...
Whichever credentials work on the device first will be used for any future operations (Backup, Mass config push) with this device.
When credentials bound to device:
Only bound credentials are tested against the device
If bound credentials do not work, the job fails
Detect device vendor and model
After correct connector and credentials are known, Unimus discovers the device.
The Vendor, Type and Model of the device is discovered.
Detect available CLI modes on the device
After Unimus knows exactly which device it's working with, it discovers available CLI modes (enable / configure mode - for example "privileged exec" and "configure" on Cisco).
Device connections during discovery
Unimus can open multiple connections to a device during discovery. How many sessions are opened depends on how many credentials are available for a device.
If a single credential is available for a device
If only a single credential is available for a device (when using Credential Binding, or Discovery with only a single credential added in the "Credentials" screen), Unimus will only open a single CLI session to the device after finding an available connector. Unimus will open connections to multiple devices at the same time (this can be configured as per the Changing maximum job concurrency article), but there will only be a single connection to each of these devices.
Assuming only a single connector is defined, and a single credential is available for a device, Unimus will open:
- 1x TCP session to the device to check if SSH/Telnet is available (a TCP 3-way handshake will be performed and then the TCP session will be closed)
- 1x full CLI session will be negotiated (SSH/Telnet as configured by Connectors) and will be used to detect device vendor, model CLI modes, etc.
Please note this behavior applies to versions 2.2.0 and newer. Older Unimus versions will behave as described in the section below, even when only a single credential is available.
If multiple credentials are available for a device
If a device is set for credential discovery and multiple credentials are available, it is normal (and expected) for Unimus to open multiple successive SSH (or Telnet) sessions to a single device during Discovery. Please note multiple concurrent sessions will never be opened to a single device, only a single session will be opened at one time to any particular device. Unimus will open connections to multiple devices at the same time, this can be configured as per the Changing maximum job concurrency article.
Unimus will open 2 + [number of available credentials] SSH (and/or Telnet) sessions to each device during Discovery:
- 1x session to check if the connector is available (during Connector detection)
- 1x session per available credential (during Credential detection)
- 1 final session which will be used to detect device vendor, model CLI modes, etc.
To minimize the number of SSH/Telnet sessions made to devices during Discovery, please use credential binding, as described in the above section of this article.
Adjusting Discovery performance
As per the previous section, you can adjust the maximum number of Discovery jobs in the job concurrency settings to throttle down the maximum number of concurrently running jobs. This will generate less peak outbound SSH/Telnet sessions from Unimus, and spread them over a longer period. You can also adjust the "unimus.core.inter-connection-delay" setting in timeouts configuration to slow down the rate of logins to individual devices, in effect lessening the speed of outbound SSH/Telnet sessions to each individual device.
When is Discovery performed?
Device addition into the system
The discovery mechanism is what makes only the address of the device required when adding a new device into Unimus.
Unimus will automatically discovered discover everything else about the device.
Import
When 400 devices are imported into Unimus, Unimus will automatically discover all the necessary details about each of the devices, and start backing them up automatically.
If proper connectors and credentials are configured, no additional steps other than importing the devices are needed.
This saves time for the administrators, and automates the work-flow.
Scheduled backups
Unimus performs a discovery before each scheduled backup.
This is to make sure Unimus knows current information about the device (connector, credentials, vendor, model, etc.).
The discovery before backup is necessary to make sure Unimus doesn't user use wrong commands on the device.
In certain situations (ex. when a device is changed for another device) it's possible commands to generate backups on some vendors can actually cause configuration changes for other vendors.
Due to this (and other edge-cases) Unimus does a discovery before every backup.
Credential changes
Discovery mechanism will also be used if any device operation fails.
For example, if credentials which were previously used on a device are no longer valid on that device, Unimus will re-run discovery.
This means that if credentials used on 400 devices need to be changed, the only change needed in Unimus is to reconfigure the credentials in 'Credentials' settings.
Discovery mechanism will take care of the rest.
Device hardware changes
Discovery will automatically be re-run when device hardware change is detected.
For example, when a Cisco device is replaced with a MikroTik, or a HP device with an UBNT device, Unimus will handle this automatically.
...