As described in our Changing default timeouts article, some drivers use a multiplier for their relevant CLI data retrieval timeout. This article lists all drivers using such multipliers.
Why are multipliers used?
We use timeout multipliers in cases where we know that a device behaves in a very inconsistent way, or we know that the device by default takes extremely long to output it's backups. Please note these multipliers only apply to Backups jobs, NOT to Mass Config Push. If you wish to change timeouts for Config Push, either change the default settings, or use Advanced Settings for Config Push. Here are 2 examples why multipliers need to be used for backups:
1) MikroTik RouterOS and inconsistent paging
MikroTik ROS normally uses paging for output (for example, try running "/interface print" on a router with multiple interfaces when the terminal vertical size is low). This means our ROS driver must support paging, or Mass Config Push would not work as expected. However, the backup command on ROS ("/export") is NOT paged. On MikroTiks with very long config, high CPU load, or if many items in the config database on the device exist (such as full BGP route tables), the output of "/export" will take a long time. Since the default per-page timeout is 20 seconds, backups would routinely fail on such routers. This is why we introduced a multiplier to the timeout value.
2) Ruckus SmartOS and extremely long backups
Ruckus devices running SmartOS - such as Ruckus Unleashed and Ruckus ZoneDirector, can take over 15 minutes to output their full backups. You can test this by yourself by logging into one of these devices using your usual SSH client, and running "show config". Since we know these devices output their config extremely slow, we use a timeout modifier to make sure these devices work properly with Unimus.
Full documentation
Device type / family | Supports paging | Used timeout type | Default timeout | Multiplier | Actual timeout (using defaults) |
---|---|---|---|---|---|
Cisco WLC | Yes | unimus.core.cli-expect-timeout | 20 seconds | 3 | 60 seconds |
Datacom switches | Yes | unimus.core.cli-expect-timeout | 20 seconds | 3 | 60 seconds |
Ericsson IPOS | Yes | unimus.core.cli-expect-timeout | 20 seconds | 3 | 60 seconds |
Ericsson SGSN | Yes | unimus.core.cli-expect-timeout | 20 seconds | 3 | 60 seconds |
Exinda | Yes | unimus.core.cli-expect-timeout | 20 seconds | 15 | 300 seconds (5 minutes) |
Extreme WLC | No | unimus.core.max-backup-timeout | 75 seconds | 5 | 375 seconds |
Fortinet FortiOS (FortiGate, FortiWeb, etc.) | Yes | unimus.core.cli-expect-timeout | 20 seconds | 5 | 100 seconds |
MikroTik RouterOS | Yes | unimus.core.cli-expect-timeout | 20 seconds | 5 | 100 seconds |
Perle IOLAN | Yes | unimus.core.cli-expect-timeout | 20 seconds | 2 | 40 seconds |
RedCarrierSwitch | Yes | unimus.core.cli-expect-timeout | 20 seconds | 3 | 60 seconds |
Ruckus SmartOS (Unleashed / ZoneDirector) | No | unimus.core.max-backup-timeout | 75 seconds | 15 | 1125 seconds (18 minutes 45 seconds) |
Ruckus vSZ (vSZ-E, vSZ-H) | Yes | unimus.core.cli-expect-timeout | 20 seconds | 45 | 900 seconds (15 minutes) |
Watchguard Fireware | No | unimus.core.max-backup-timeout | 75 seconds | 5 | 375 seconds (6 minutes 15 seconds) |
Zhone | Yes | unimus.core.cli-expect-timeout | 20 seconds | 30 | 600 seconds (10 minutes) |