Network Management

UDT CLI polling for Layer 2 and Layer 3

This article explains how to enable CLI Polling for UDT Layer 2/3, what to expect per device type, and how to troubleshoot common issues. Some devices — Cisco Nexus switches (5K/7K/9K), Palo Alto firewalls, and Cisco ASA firewalls — do not expose full Layer 2/3 (IP-to-MAC/ARP) data via SNMP. For these devices, User Device Tracker (UDT) supports polling Layer 3 data over CLI (SSH) instead of, or in addition to, SNMP.

First published date

9/23/2026 1:18 AM

Last published date

9/23/2026 2:26 PM

Overview

UDT normally collects Layer 2 (MAC address) and Layer 3 (IP address / ARP) data via SNMP. Certain device families restrict or do not expose the SNMP MIBs UDT needs for Layer 3 (ipNetToMediaTable / ipNetToPhysicalTable). CLI-based polling may be used as a supported workaround.

CLI polling behavior differs by device type:

  • Cisco Nexus (5K/7K/9K): CLI polling supplies Layer 3 data only. Despite documentation wording suggesting both Layer 2 and Layer 3 are polled via CLI, Layer 2 (MAC address) data for Nexus devices is still collected via SNMP. Only Layer 3 uses CLI.

  • Palo Alto firewalls: CLI polling supplies both Layer 2 and Layer 3 data, since SNMP MIB support on Palo Alto is limited (ARP/MAC tables are not exposed via supported SNMP MIBs).

  • Cisco ASA firewalls: CLI polling is scoped to the ARP table only (show arp), used to fill in Layer 3 data that SNMP cannot provide. ASA devices do not have Layer 2 forwarding data to poll.

CLI polling uses the SolarWinds CLI Client Orion package and communicates over SSH (port 22 by default; unencrypted Telnet on port 23 is supported only if explicitly enabled).

Product section

User Device Tracker

Resolution

Enable CLI Polling for Layer 3

  1. Add the device to UDT as a standard SNMP node first (SNMP credentials remain required as a base).

  2. Open Edit Node Properties (or use the last step of the Add Node wizard) and locate the CLI Polling Settings section.

  3. Select Enable CLI Polling and provide:

    • Username and password for CLI login.

    • Enable password — required to reach privileged EXEC mode on Cisco devices (Nexus, ASA). This field is optional for Palo Alto, since Palo Alto does not support "Enable mode" commands.

    • For Palo Alto devices that present an Authorization Statement prompt at login, set Use Keyboard Interactive Authentication to Yes; otherwise CLI access will be denied.

  4. Click Test to validate the credentials, then Submit.

  5. UDT schedules a Layer 3 CLI job for the node. Data appears in the Port Details resource on the Node Details page once the job completes successfully.

Note: Credential changes are picked up by the collector approximately every 30 seconds via PubSub. Poll Now / Rediscover Now do not speed this up.

Verify the Layer 3 CLI job

  • Go to Settings > All Settings > UDT Settings > View UDT Job Status and confirm a Layer 3 job exists for the node and completes with a Success status.

  • Run the UDT Compatibility Checker against the node using the Layer 3 target to confirm the device returns ARP/IP-to-MAC data over the selected protocol (SNMP or CLI). If the device doesn't support the required SNMP objects at all, CLI is the only way to retrieve Layer 3 data.

  • For Nexus nodes, if Layer 2 data is missing while Layer 3 (via CLI) works, this is expected — Layer 2 for Nexus is polled via SNMP, not CLI. Investigate the SNMP/Layer 2 job separately rather than the CLI configuration.

Troubleshoot CLI polling failures

  • Enable CLI session tracing to capture the raw CLI conversation with the device:

    • Go to Settings > All Settings > CLI Settings, select Enable Session Tracing, and Submit.

    • Reproduce the issue, then collect trace files from C:\ProgramData\SolarWinds\Logs\Orion\CLI\Session-Trace (named using the device's IP address).

    • Disable session tracing and delete trace files afterward to avoid unnecessary log growth.

  • Set UDT Business Layer and UDT Jobs logging to Debug, then rerun the Layer 3 job (Poll Now from the UDT Job Status page) to capture detailed job processing logs.

  • Check for Enable password misconfiguration on Nexus/Cisco devices — a saved Enable password that isn't actually required (or incorrect Enable mode credentials) is a common cause of failed CLI polling on Nexus.

  • Check job timeouts — if the device responds slowly (visible via long durations in the UDT Compatibility Checker), increase the Layer 2/Layer 3 job timeout on the Advanced Settings page. In at least one case, increasing the timeout from 45 to 100 minutes resolved persistent Layer 3 polling failures on slow-responding Nexus nodes.