Frequently Asked Questions

netLD is accessed through a modern web browser using HTTPS. No browser plugins, Flash, or Java are required.

Supported browsers (current and previous major versions):

• Google Chrome
• Mozilla Firefox
• Microsoft Edge (Chromium-based)
• Apple Safari

For best results, we recommend using the latest stable version of your browser and enabling JavaScript and cookies.

Client operating systems are not restricted, provided the OS and browser are still supported by their respective vendors. Operating systems that have reached end-of-life are not supported.

netLD uses a defined set of network ports depending on which features are enabled (discovery, backups, configuration changes, terminal access, authentication, and monitoring).

At a high level, the common ports include:

• Web access (GUI / Web Terminal): HTTPS 443/TCP
• Device discovery and management: SSH 22/TCP, Telnet 23/TCP, SNMP 161/UDP, ICMP (ping)
• Configuration backup and restore (device-dependent): SSH 22/TCP, Telnet 23/TCP, TFTP 69/UDP, FTP 20–21/TCP
• Zero-Touch / Plug and Play: DHCP 67–68/UDP, HTTP 80/TCP, TFTP 69/UDP
• Terminal Proxy: 2222/TCP (SSH proxy) or 443/TCP (HTTPS)
• SNMP traps and monitoring: SNMP 161/UDP, Traps 162/UDP
• External authentication (optional): LDAP 389/TCP, RADIUS 1812/UDP

The exact ports required depend on your device types and which netLD features you use. For a complete, authoritative list (including communication direction), refer to the List of Ports Used section in the netLD User's Manual for more details.

If you need help validating firewall rules or planning network access, please visit our Technical Support page.

Yes. netLD supports bulk import of managed devices from other systems using a CSV file.

To import devices in bulk:

• From the Inventory screen, select Save inventory import Excel template and download the template file.
• Open the template and enter or select the required fields, such as IP address, Network, and Adapter.
• Save the completed file.
• From the Inventory screen, select Import / Update inventory from Excel file and upload the completed file.

The import function can also be used to update existing inventory records, allowing you to make changes to multiple devices in a single operation.

Playbooks in netLD are structured automation workflows used to safely execute multi-step operations across one or more devices. They are designed for tasks that require ordered execution, validation between steps, or actions that would be unsafe to run as a single blind command.

Playbooks are built using a visual, low-code workflow editor. Most automation tasks can be created by connecting pre-built blocks that handle device selection, command execution, data parsing, and follow-up actions. For example, a playbook can visually select devices, run operational CLI commands, convert command output into structured data, and store results — all without writing scripts.

When needed, Playbooks also support inline command execution or logic blocks for advanced use cases, allowing experienced users to add precision without forcing complexity on everyday workflows.

Typical use cases for Playbooks include:

• Planned device reboots or reloads
• Multi-stage configuration changes
• Conditional workflows that depend on command results
• Coordinated changes across multiple devices
• Operational runbooks that need to be repeatable and auditable

Video walkthroughs and examples are available on our Videos page. If you need guidance designing safe operational workflows, please visit our Technical Support page.

Yes. netLD supports external authentication so you can unify login with your organization’s identity stack (SSO) instead of managing local passwords.

Supported authentication methods include:

• SAML 2.0 (SSO) — works with common IdPs such as Microsoft Entra ID (Azure AD), Okta, Ping Identity, and others
• RADIUS — integrates with systems such as Cisco ISE, Aruba ClearPass, and standard RADIUS servers
• LDAP / Active Directory

You can also map external groups to internal netLD Roles and to specific Networks (Network Groups). This lets you enforce both what users can do and which device groups they can see using your existing IdP/RADIUS group membership.

A netLD SmartBridge is a lightweight proxy component that allows netLD to manage devices across large, distributed, or segmented networks. SmartBridges are typically deployed closer to the devices they manage—such as in remote sites or separate network zones—and securely relay management traffic back to the netLD core server.

SmartBridges help reduce WAN traffic, improve performance, and enable netLD to scale to very large environments without requiring direct connectivity from the core server to every device.

A single netLD server can support multiple SmartBridges. As a general guideline, we recommend connecting up to 10 SmartBridges to a single netLD core server, depending on workload, device count, and available system resources.

If you are designing a large or distributed deployment and want help determining the optimal SmartBridge layout, please visit our Technical Support page.

A SmartBridge is designed to establish a connection with a single netLD core server.

The supported connection model is one netLD server to multiple SmartBridges (1:n). A SmartBridge cannot be shared across or simultaneously connected to multiple netLD servers.

This design ensures clear ownership, consistent state management, and predictable communication between the SmartBridge and its associated netLD server.

netLD stores configuration history for each device based on your Data Retention settings. You can keep configuration history forever, for 6 months, or for a fixed period of 1–7 years.

The total number of versions retained depends on how often you back up configurations, how often the configurations change, and how large the configuration files are. When the retention period is reached, the oldest versions are automatically removed.

netLD keeps system logs based on your Log Retention settings. You can keep logs forever, for 6 months, or for a fixed period of 1–7 years. When the retention period is reached, the oldest logs are automatically removed.

In addition to time-based retention, netLD also manages log file sizes. When the main log file reaches a predefined size limit, it is rotated and archived to prevent uncontrolled growth.

Log files automatically roll over at 2 MB maximum size, and a backup file is produced as follows:

• netLD.log - current
• netLD.log.1 - most recent backup
• netLD.log.2 - second from latest netLD.log.
• netLD.log.3 - oldest

The maximum size of log and the frequency of backup can be configured by and Administrator in Settings → Syslog. netLD also supports external syslog servers for long-term log retention and centralized log management.

You can view your license details (expiration date, serial number, and licensed device count) in the product UI under Help → About.

netLD also displays an in-product warning banner starting 90 days before the license expires.

netLD supports both online (Internet-connected) and offline (air-gapped) upgrade workflows.

Online (Internet-connected systems)

If the system has outbound Internet access enabled, netLD periodically checks for new releases automatically. When an update is available, a notification banner appears in the UI. Selecting the notification opens Settings → Software Update. Click Install Update to begin the upgrade. The update is applied automatically and required services are restarted. After completion, the system returns to the login screen.

Offline / air-gapped systems

For systems without Internet access, updates are provided as downloadable packages. Download the Full *.ENC file for use in the Admin Dashboard from the support portal and unzip the archive. Log in to the Admin Dashboard at https://<system-ip>/admin, navigate to the Update tab, and upload the extracted .enc file (for example, software_package-lvi-core-YYYY.MM.X-*-full.enc). Once uploaded, the update process runs automatically and required services are restarted.

Before upgrading
As a best practice, we strongly recommend taking a system backup and a virtual machine snapshot before performing any upgrade. This ensures a quick rollback path in the unlikely event an issue is encountered during the update process.

If an import fails (or only some rows are imported), it is almost always caused by formatting issues in the IP Address column or duplicate IP addresses in the file. netLD will typically skip only the invalid rows and import the rest.

Common causes to check:

• Leading/trailing spaces or hidden characters in the IP Address column
• Non-ASCII / double-byte characters in an IP address
• Duplicate IP addresses (two rows with the same IP)

If you are importing static credentials: rows containing any of the issues above are skipped, while other valid rows are still imported.

If you are importing inventory and the import returns an error: confirm the file contains no duplicate IP addresses. Duplicate IPs will cause the inventory import to fail.

If only some lines were imported: re-check the IP Address column for spaces/irregular characters or double-byte characters. Those rows are skipped while the rest are imported.

This is a high-level, end-to-end overview of how a netLD configuration backup is performed.

At a basic level, the backup process follows these steps:

• Establish a CLI connection to the device
• Execute discovery and configuration collection commands
• Retrieve the configuration (via CLI, TFTP, or FTP depending on device support)
• Close the connection to the device
• Store hardware and software information in the database
• Compare the collected configuration with the previous backup and store changes

In more detail:

netLD initiates a backup using the configured protocols and credentials. If a connection attempt fails, netLD automatically retries using the next available protocol or credential combination until it successfully logs in. The last successful combination is cached and reused for subsequent backups.

Once connected, netLD executes a defined set of commands to collect hardware and software information, as well as the device configuration itself.

Depending on device capabilities, configuration retrieval may occur entirely over the CLI (SSH or Telnet), or netLD may instruct the device to transfer its configuration back to the server using TFTP or FTP.

After configuration retrieval, the connection to the device is closed and the parsed hardware and software data is updated in the netLD database.

netLD then compares the newly collected configuration against the previous backup. If differences are detected, the configuration changes are stored using a reverse-delta model, meaning only the changes themselves are saved rather than a full copy of the configuration each time.

When a SmartBridge is used, an additional optimization step occurs. The SmartBridge compares a CRC hash of the current configuration with the previously stored hash. If no change is detected, it reports this to the core server, avoiding unnecessary data transfer and reducing WAN bandwidth usage.

Command Runner sends the commands you enter directly to the device, in the order provided. It does not interpret, validate, or guard against disruptive commands.

If a command such as reload is included:

• The device may immediately begin a reboot, or
• The job may time out while waiting for interactive confirmation (for example, a confirm prompt).

In either case:

• Any commands listed after the reload command will not be executed.
• The job result will typically end in a timeout or error state.
• Command Runner does not support interactive prompts or confirmations.

Because of this, Command Runner is not suitable for workflows that require reboots, confirmations, or multi-stage logic.

For controlled reboot scenarios or workflows that require conditional execution, use Playbooks, which are designed to safely orchestrate multi-step operations.

The following conditions must be met to use Plug and Play (formerly referred to as Zero-Touch provisioning):

• Supported IOS version: Cisco IOS must support CNS AutoInstall or Plug and Play. In general, this requires IOS 15.2(2) or later. Earlier Zero-Touch functionality was introduced in some platforms as early as IOS 12.3.
• No existing startup configuration: The device must not have a valid startup configuration present when it boots.
• DHCP availability: The device must be able to obtain an IP address via DHCP.

You can use the Cisco Feature Navigator to confirm whether a specific IOS version and platform supports the required Plug and Play features.

When ordering hardware from Cisco or a Cisco partner, ensure that no staging, pre-configuration, or customer-specific startup configuration is applied before shipment. Devices should arrive in a factory-default state. If configuration must be cleared manually, remove the startup configuration using the appropriate platform commands (for example, write erase or erase startup-config on IOS-based systems), and verify that no startup configuration is present before rebooting the device.

netLD provides a built-in DHCP service to support Plug and Play workflows. If you prefer to use an external DHCP server, configure DHCP Option 150 to point to the IP address of the netLD system, which acts as the TFTP server during provisioning. If there is no router capable of handling Plug and Play in the same broadcast domain as the device, configure a staging router as a DHCP relay to forward DHCP requests to netLD.

Yes, netLD sends SNMP Traps to the destination configured in Settings → SNMP Traps when these conditions are detected:

• Device configuration changed detected on backup.
• New device is added to the network.
• Device is deleted.
• Backing up configuration of device has failed.
• Compliance policy attached to the device is violated.

Please check the following:

• SNMP must be enabled on the devices.
• The SNMP community configured on the devices must match the community set in netLD credentials.
• ICMP ping and SNMP must not be blocked by a firewall or antivirus software.
• Multiple Network Groups should not exist under the credential/protocol configuration.

netLD displays the discovery result and related errors. Common statuses include:

• Device added. The device was successfully discovered and added to the inventory list.
• There was no SNMP response. The device responded to Telnet, SSH, or ICMP ping, but not to SNMP. Confirm SNMP is enabled and reachable.
• No adapter matches. The device responded to SNMP, but no adapter matched. Confirm the device is supported by netLD.
• Server protocol settings for SNMP for this device are disabled. SNMP is disabled for the Network Group under Inventory → Protocols. Enable SNMP in the protocol settings.
• There was no ICMP ping response. The device did not respond to ICMP ping (this status is only available when discovering a single IP address). Confirm ping/SNMP is not blocked by a firewall or antivirus software.
• Unable to establish TCP connection on port 22 (SSH) or 23 (Telnet). netLD cannot connect to the device on SSH/Telnet (this status is only available when discovering a single IP address). Confirm these ports are reachable.

For Cisco SNMP configuration examples, see: Cisco SNMP Configuration Examples.

Switches in a stack configuration are registered as a single device. Stack membership can be inspected using the Command Runner.

Run the following command on the stack master:

Stack# show switch
                                              H/W   Current
Switch#  Role    Mac Address       Priority Version  State
----------------------------------------------------------
*1       Master  0018.ba60.de00        15        1     Ready
 2       Member  0018.ba60.ce00        14        1     Ready
 3       Member  0016.9d0c.7500         1        2     Version Mismatch

Alternatively, the stack membership is also shown in the Hardware tab of the Device Details screen.

Yes. netLD supports OS image and firmware distribution for multiple vendors, not just Cisco.

Dedicated Software Distribution menus are available for supported platforms, including:

• Cisco IOS
• Cisco ASA
• Juniper JUNOS
• NEC WA
• Allied Telesis
• Yamaha RT

These vendor-specific menus handle image management, transfer, and execution according to each platform’s requirements.

For devices that do not have a dedicated Software Distribution menu, firmware or OS updates can still be performed using Command Runner or automated Jobs, allowing you to build controlled upgrade workflows using native device commands.

Yes. netLD supports concurrent access for multiple users.

You can also control what each user can see and do by assigning permissions and applying viewing restrictions.

• Create separate user accounts for each team member
• Assign role-based permissions (what actions a user can perform)
• Restrict visibility by Network Group so users only see the devices and networks they are responsible for

This makes it easy to share one netLD system across operations, engineering, and audit/compliance teams while keeping access appropriately scoped.

netLD supports multiple management and transfer protocols, but—critically—you can enable or disable each protocol per Network Group. This allows you to enforce modern security standards where possible while still supporting legacy devices where required.

Protocols are selected automatically at runtime based on the device, its adapter, and the protocol policy defined for the Network Group it belongs to.

Discovery typically uses ICMP and SNMP.

Configuration backup and change may use one or more of the following, depending on device capability and your protocol policy:

• SSH
• Telnet
• HTTPS / HTTP
• SCP
• FTP
• TFTP
• SNMP

Each Network Group can explicitly allow or deny protocols and can also pin protocol versions (for example, SSH or SNMP versions). This makes it easy to isolate legacy devices that require older protocols (such as Telnet or FTP) into a dedicated Network Group, while enforcing SSH/SCP/SFTP-only access for modern infrastructure.

This design lets you balance operational reality with security best practices—without forcing lowest-common-denominator protocols across your entire environment.

Yes. netLD is accessed over HTTPS, and it comes out of the box with HTTPS enabled by default.

By default, netLD uses a self-signed TLS certificate. For production deployments, you can replace this certificate with one issued by your organization’s Enterprise CA (internal PKI) or by a public Certificate Authority.

As with any administrative interface, we recommend restricting access to trusted networks (for example via firewall rules, VPN, or a reverse proxy) and following your organization’s security policies.

This example shows how to build a custom Smart Change that enables NetFlow on selected router interfaces. The key idea is to start with a working command set, then parameterize the interface values so the same Smart Change can be reused safely.

Example workflow:

• Go to the Job Management tab.
• Select New Job → Smart Change.
• Enter a job name and click OK.
• In the job editor, paste your NetFlow configuration boilerplate.
• Parameterize the variable parts: highlight the fragment you want to replace, then click the + button to create a replacement.
• Create a Choice replacement so the user can select an interface (or interface set) at runtime.
• Reuse the same replacement value where needed (for example for both interface ... and flow-export source ...) by dragging the replacement into each target location.
• Save the job and close the editor.
• On the Devices tab, select the target device(s), then choose your new Smart Change from the Smart Change menu.
• Fill in the requested values and execute.

Smart Change also supports mass change workflows, such as exporting an Excel template, populating values for many devices, and importing it to execute a large batch change.