Frequently Asked Questions

netLD is delivered as a virtual appliance. You can deploy it on VMware OVA, Hyper-V VHDX, and OpenStack/KVM QCOW2.

netLD is also available for AWS and Azure through the public cloud marketplaces.

If you are planning a new deployment and want to validate sizing, networking, or platform fit, visit our Technical Support page.

netLD supports a broad range of network infrastructure, including routers, Layer 2 and Layer 3 switches, firewalls, wireless controllers, load balancers, and wireless access points.

Supported features vary by vendor, platform, OS version, and adapter. Use the Supported Devices page to check current device support and the adapter feature matrix to review which adapter features are available.

If a device is not currently listed, LogicVein may be able to develop a custom adapter. In general, devices that expose a manageable CLI are good candidates for adapter development. Contact us through Technical Support to discuss feasibility.

Start with the installation videos and the product documentation. The videos show the basic appliance setup flow, and the manuals provide the details you need for production planning.

• Watch the setup walkthroughs on the Videos page.
• Use the netLD documentation or ThirdEye documentation for installation and configuration details.
• Review System Requirements before sizing a production deployment.

The ports and protocols netLD needs depend on the workflows you enable: web access, discovery, configuration backup, configuration change, terminal access, authentication, monitoring, traps, and file transfer.

Common ports include:

• Web access: HTTPS 443/TCP, HTTP 80/TCP
• Device discovery: ICMP and SNMP 161/UDP
• Device access: SSH 22/TCP, Telnet 23/TCP, HTTPS/HTTP where supported by the adapter
• Configuration transfer: TFTP 69/UDP, FTP 20-21/TCP, SCP/SFTP where supported
• SNMP traps: 162/UDP
• External authentication: LDAP 389/TCP, RADIUS 1812/UDP, or the ports used by your identity provider

Protocol use is controlled by the device, adapter, and Network Group policy. Each Network Group can allow, deny, or constrain protocols, which lets operators support legacy devices without forcing legacy protocols across the entire environment.

The exact firewall rule set depends on device vendors, adapters, protocols, and deployment architecture. For production planning, validate the port list against the netLD documentation and your own security policy.

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 are controlled automation workflows for network operations. Use them when a task needs multiple steps, validation between steps, branching logic, or a safer execution path than a one-shot command.

Operators build Playbooks visually by connecting blocks for device selection, command execution, parsing, checks, and follow-up actions. Advanced users can still add command logic where needed.

Good Playbook candidates include:

• Planned reloads or maintenance workflows
• Multi-stage configuration changes
• Pre-check / change / post-check processes
• Reusable operational runbooks
• Coordinated changes across many devices

For examples, see the Videos page or the Playbooks white papers.

Use SmartBridge when the netLD core server should not, or cannot, connect directly to every managed device.

SmartBridges are usually deployed close to the devices they manage: remote sites, segmented networks, customer environments, or areas with overlapping IP space. The SmartBridge relays management activity back to the assigned netLD core server.

This reduces WAN traffic, improves locality, and lets larger environments scale without flattening the network just for management access.

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.

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.

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.

SmartBridge is designed to maintain a secure connection back to its assigned netLD core server. This lets the core server manage devices in remote, segmented, or overlapping networks without requiring direct access to every managed device.

For detailed connection behavior and setup steps, see Knowledge Base Article 13000012970.

If you are designing a SmartBridge deployment and need help validating the traffic path, visit our Technical Support page.

No. A SmartBridge connects to one netLD core server.

The supported model is one netLD server to many SmartBridges. A SmartBridge should not be shared across multiple netLD servers, because that would create unclear ownership and unpredictable state 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 commands directly to the device in the order provided. It does not interpret the command sequence or handle interactive prompts.

If you include a command such as reload, the device may reboot immediately, or the job may time out while waiting for a confirmation prompt.

• Commands after the reboot command usually will not run.
• The job may finish with a timeout or error state.
• Command Runner is not the right tool for workflows that need confirmations, waiting, branching, or validation.

For controlled reboot workflows, use Playbooks. Playbooks are designed for multi-step operational workflows with conditional logic and validation.

Plug and Play provisioning works best when the device arrives in a factory-default state and can reach the provisioning services during first boot.

• The device platform and IOS version support Cisco CNS AutoInstall or Plug and Play.
• The device has no valid startup configuration when it boots.
• The device can obtain an IP address by DHCP.
• The DHCP path can point the device to the netLD system, usually through DHCP Option 150 or an appropriate relay design.

If hardware is staged by a partner or warehouse team, make sure no customer-specific startup configuration is applied before shipment. A preconfigured device will not behave like a factory-default Plug and Play target.

Yes. netLD can send SNMP traps to the destinations configured under Settings → SNMP Traps.

Common trap events include:

• A configuration change is detected during backup.
• A device is added to inventory.
• A device is deleted from inventory.
• A configuration backup fails.
• A device violates an attached compliance policy.

If discovery completes but devices are not added, start by checking reachability and SNMP. Discovery needs the right network path, credentials, and adapter match before netLD can add a device to inventory.

• SNMP is enabled on the target device.
• The SNMP community or credential in netLD matches the device configuration.
• ICMP and SNMP are not blocked by a firewall or endpoint security tool.
• SSH or Telnet is reachable when the adapter requires CLI access.
• The device is supported by a matching netLD adapter.

The discovery result usually tells you where to look next. For example, “no SNMP response” points to SNMP reachability or credentials, while “no adapter matches” means netLD heard from the device but could not match it to a supported adapter.

Use the Update History page to review recent netLD release notes, fixes, and feature changes.

A switch stack is registered as a single managed device. Stack members can still be inspected from device details or by running operational commands against the stack master.

For Cisco-style stacks, commands such as show switch show member role, MAC address, priority, version, and state.

The exact inventory detail depends on the platform and adapter support.

Online license activation requires Internet access from the netLD system. If the system is in a restricted or air-gapped environment, online activation may fail even when the license itself is valid.

In that case, LogicVein can issue an offline license file tied to the server MAC address. If the system has multiple NICs, one MAC address is enough for the request.

Visit our Technical Support page to request offline activation help.

netLD can restore a previously backed-up startup configuration, provided a suitable backup exists for that device.

That is not the same as automatically undoing every command in a failed job. For risky changes, take a backup first and use a controlled workflow such as SmartChange or Playbooks so the recovery path is clear before you run the change.

netLD collects hardware inventory by running supported show commands through the device adapter and parsing the returned output.

On Cisco devices, this may include commands such as show version, show module, and show tech. Other vendors use the equivalent commands supported by their adapter.

Yes. If you do not want netLD to scan a production network, you can add devices manually or import them from a file.

• To add one device, go to Inventory and select Add new device.
• To add many devices, use the inventory import workflow with a CSV or Excel template.

This lets you onboard known devices without running discovery across an IP range.

Discovery needs basic network reachability plus the protocols required to identify and manage the device.

• netLD can reach the target IP address or address range.
• SNMP is enabled on the device when discovery depends on SNMP identification.
• SNMP credentials in netLD match the device configuration.
• SSH or Telnet is reachable when the adapter requires CLI access.
• Firewalls and ACLs allow the required traffic between netLD and the device.

Yes. netLD supports custom device fields so you can track site, owner, role, asset information, or other operational metadata alongside the device inventory.

You can also control visibility for custom fields by user, which is useful when different teams share one netLD system.

• Go to Settings and open Custom Device Fields.
• Create the fields you want to track.
• Use user settings to control which custom fields each user can see.

After installation, configure the basic items netLD needs before it can discover devices, back up configurations, or run tools.

• Add credentials for the devices you want to manage, including login credentials and SNMP communities where required.
• Configure the protocols netLD should use for discovery, backup, and configuration changes.
• Add devices manually, import them from a file, or run discovery against an IP range.
• Run an initial configuration backup to confirm that credentials, protocols, and device access are working.

Once those steps are complete, you can begin using tools, jobs, reports, and other operational workflows.

Tags let you group devices in ways that are useful to operators: site, function, project, maintenance window, owner, or any other label that helps you target work.

Once tags are assigned, you can filter inventory views and apply jobs or workflows to a tagged group instead of selecting devices one by one.

• Create tags from Inventory → Device Tags.
• Select devices in the inventory.
• Use Device → Associate tags to apply the tags.

Yes. For troubleshooting, you can enable adapter logging for a target IP address or CIDR range. This records adapter operations for a short time while you reproduce the issue.

• Go to Help → About → Adapter Logging.
• Enter the target IP address or CIDR range.
• Enable adapter operation recording.
• Run the device operation you want to inspect.

Adapter logging is intended for focused troubleshooting and is time-limited. Collected logs are stored under the netLD scratch logs directory.

SmartChange variables are designed for single-line substitution. If you need to vary multiple lines, split the template into separate replacement values and reuse those values where needed.

For example, instead of one multi-line ACL variable, create separate replacement fields for each ACL line. Export the template, fill in the values, and import it for the target devices.

For complex branching or multi-step logic, Playbooks are usually a better fit than a single SmartChange template.

Most netLD schedules do not need any special leap-year handling.

The edge case is a monthly schedule that targets February 29. In a non-leap year, that date may be interpreted as March 1, which can make the schedule behave differently than expected.

For monthly jobs, choose a day that exists every month when the timing needs to be predictable.

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 does not set an arbitrary application limit on most stored operational data. Practical retention is governed by the storage available to the appliance and by your data-retention settings.

For production systems, size storage based on device count, backup frequency, configuration size, log retention, and whether you keep history forever or prune it after a defined period.

netLD can be activated online or with an offline license file.

• Online activation: enter the license key during setup and netLD authenticates it over the Internet.
• Offline activation: LogicVein issues a license file tied to the server MAC address. You apply that file locally on the netLD system.

If the appliance cannot reach the activation service, use the offline license workflow.

Often, yes. netLD support can be extended with a custom adapter when the device exposes a usable management interface, usually a CLI.

Adapter work depends on the device command set, output format, authentication behavior, and the operations you need netLD to perform.

If you need support for an unlisted device, visit our Technical Support page so we can review feasibility.

The practical scale depends on licensing, server resources, topology, and workload.

A properly sized standalone netLD server can manage very large environments. For larger or distributed deployments, SmartBridge can extend scale and reduce the need for direct connectivity from the core server to every device.

Use the System Requirements page as a sizing starting point, and involve LogicVein when planning very large deployments.

Yes. netLD can store system backups inside the appliance or write them to an external NFS or SMB share.

External backup storage is configured from the netLD console under the NFS/SMB backup share settings.

Use external backup storage when you want recovery data outside the appliance itself. Make sure the share is secured and monitored like other infrastructure backup targets.

Start from the Technical Support page so your request reaches the right team with the right context.

LogicVein provides remote support by email, phone, and web session. On-site support is not part of the standard support model.

Support covers product questions, troubleshooting assistance, bug fixes, access to new version installers, and adapter maintenance for supported device operating systems.

Some adapter updates are tied to specific netLD versions, so support may ask you to update netLD before applying an adapter fix.

Yes. You can increase managed-node capacity by purchasing additional license entitlement.

For license changes, contact us through Contact Us.

For virtual-appliance deployments, the most common recovery strategy is regular system backups plus hypervisor snapshots or your platform’s VM protection tooling.

A second appliance can be prepared as a recovery target, but it should be planned carefully so licensing, backups, network identity, and restore procedures are clear before an outage.

For production environments, define and test the restore process before you need it.

Yes. netLD supports OS image and firmware distribution workflows 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

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

For devices without a dedicated Software Distribution menu, operators can use Command Runner, Jobs, SmartChange, or Playbooks to build a controlled upgrade workflow using the device’s native commands.

Always validate image transfer, storage, reload behavior, and rollback steps in a lab or maintenance window before running a large upgrade.

Treat netLD as a sensitive administrative system. It stores operational data, device information, and credential material needed to manage the network.

System backups include the configuration needed to restore the appliance, including stored credential configuration. Protect backup files as sensitive data.

Protect the appliance with strong access controls, HTTPS, restricted administrative access, secure backup handling, and storage-level encryption where your environment requires it.

If you have a specific encryption or compliance requirement, validate it with LogicVein before deployment.

No. netLD keeps configuration history so you can compare versions and review previous states.

How long that history is retained depends on your Data Retention settings. You can configure retention under Settings → Data Retention.

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, restrict access to trusted networks where possible, such as firewall rules, VPN, or a reverse proxy, and align the deployment with your organization’s security policies.

Yes. You can export inventory from the Devices screen using the inventory export option.

This is useful for audits, reporting, external analysis, and preparing bulk updates.

Use the Jobs tab and open Job History to review past job runs.

Job history includes the job name, start time, end time, user, result, and details for supported tool, report, and Terminal Proxy activity.

How long history is retained depends on your retention settings and available storage.

The product software is the same. The difference is the license entitlement.

• Evaluation licenses are time-limited.
• Evaluation licenses are limited to the trial node count.
• Production licenses use the purchased term and managed-node entitlement.

If you are converting an evaluation into a production system, contact LogicVein for the appropriate license update.

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.

netLD does not impose a simple fixed device-count limit for a batch change, mass change, backup run, or IOS distribution job.

Use concurrency controls to limit how many devices are processed at the same time. This helps avoid overloading devices, WAN links, SmartBridges, or the netLD server during large jobs.

Multiple jobs can be scheduled for the same time, but they may not all start at the exact same second. netLD runs the allowed number concurrently and queues the rest.

In practice, batch size should be based on risk, maintenance window, device type, image size, network bandwidth, and rollback plan. For large changes, use smaller staged batches so operators can validate progress before continuing.

For heavy work such as backups, reports, mass changes, and image transfers, stagger jobs where possible so they do not compete for device, server, or network resources.

Use Draft Configuration when you need to prepare configuration text and apply it to a device through netLD.

For repeatable or parameterized changes, SmartChange or Playbooks are usually better choices because they make the workflow easier to reuse and audit.

Yes. netLD supports memo templates so teams can standardize the notes they attach to devices, configurations, or draft configurations.

Use templates for common change notes, operational context, audit comments, or handoff information.

Yes. You can attach memos to devices in inventory. You can also attach notes to configurations and draft configurations.

Memos are useful for operational context that does not belong in the device configuration itself, such as ownership notes, maintenance constraints, or change rationale.

Change Advisor helps generate device commands for supported change workflows, then pushes those commands to the selected devices.

It is intended to reduce manual command construction for common changes while keeping the operation inside netLD’s controlled workflow.