Network Diagnostic Tools

Nautobot Tools includes a suite of network diagnostic tools that help you test connectivity, resolve DNS names, trace network paths, and more — all without leaving Nautobot.

Running a Tool

Network diagnostic tools are available as Nautobot Jobs. You can launch them in two ways:

From a Detail View

The quickest way to run a tool is directly from a Device or IP Address detail page. Click the tool button to open a dialog pre-filled with the relevant target.

Device detail view showing the network tools button.

ICMP tool job modal on device detail view.

From the Jobs Page

All tools are also available under Jobs in the Nautobot navigation. This is useful when you want to target a host that isn't in your Nautobot inventory.

Network Tools on job list view.

Tools

Ping (ICMP)

Sends ICMP echo requests to verify that a host is reachable over the network. Returns whether the host responded, the average round-trip latency, and packet loss percentage.

If the primary method is unavailable in your environment, the tool automatically tries an alternative method.

Parameters:

• Target — IP address or hostname to ping
• Count — Number of echo requests to send (default: 4)
• Interval — Seconds between each request (default: 1)

Ping (ICMP) job result showing successful ping output.

Ping from Device

Runs ping over SSH on managed network devices. The selected devices originate the probes; the Nautobot worker provides the SSH connection. An administrator must enable Ping from Device under Jobs before use. The Job declares read_only = True and does not change device configuration.

Each device needs a primary IP address, a supported platform network_driver, and credentials configured through Nautobot Plugin Nornir. Selected devices must have non-empty, unique names for the Nornir inventory. Invalid inputs and unsupported platform commands are rejected before any SSH connection.

This Job always sends a live ping over SSH, including for devices whose offline_commands setting is enabled for other workflows. Device netmiko_kwargs are merged with the Job's command options; the validated command, raw-text output, and 60-second read timeout take precedence. Nornir inventory connection options and NORNIR_NAUTOBOT_NETMIKO_ENABLE_DEFAULT still apply.

Inputs:

Input	Behavior
Target	Literal IPv4 address. Supply either this or an override, never both.
Devices	Required explicit devices to originate the probes.
Dynamic Groups	Optional device groups that narrow the explicit selection to its intersection with group members. Group-only and empty selections are rejected.
Count	1–10 probes, default 5. Ignored for an override and for platforms that use their configured count.
Ping Command Override	Restricted full ping command for VRF, source, or IPv6 use. See below.
Fail job on task failure	Default false. When true, FAIL or UNKNOWN on any device also marks the Nautobot Job Result as failed.

Built-in IPv4 commands:

Platform network drivers	Command
cisco_ios, cisco_xe, arista_eos	ping TARGET repeat COUNT
hp_procurve, aruba_aoscx	ping TARGET repetitions COUNT
cisco_nxos, cisco_xr, juniper_junos, juniper, nokia_sros, vyos, ubiquiti_edgerouter, ruckus_fastiron, brocade_netiron	ping TARGET count COUNT
linux, huawei, huawei_vrp, hp_comware, dell_os10	ping -c COUNT TARGET
paloalto_panos	ping count COUNT host TARGET
mikrotik_routeros	ping TARGET count=COUNT
extreme_exos	ping count COUNT TARGET
cisco_asa	ping TARGET; uses the device's configured count
fortinet	execute ping TARGET; uses the device's configured count

Command availability depends on the device's software version and permissions. An unrecognized platform is rejected, including when an override is supplied. The SSH read timeout is 60 seconds; it does not guarantee cancellation of a command already running on a device.

Override rules:

The override starts with ping, contains exactly one literal IPv4 or IPv6 destination, and includes a platform-specific packet count between 1 and 10. It supports only the following options. Options taking values require a single literal token; repeated options are rejected. Use the ordering required by the device CLI.

Drivers	Allowed options
cisco_ios, cisco_xe, arista_eos	repeat COUNT, source ADDRESS_OR_INTERFACE, vrf NAME, ipv6
cisco_nxos	count COUNT, source ADDRESS_OR_INTERFACE, vrf NAME
juniper_junos, juniper	count COUNT, source ADDRESS, routing-instance NAME, inet6
linux	-c COUNT, -I ADDRESS_OR_INTERFACE, -4, -6
huawei, huawei_vrp	-c COUNT, -a ADDRESS, -vpn-instance NAME, ipv6

Other drivers do not support overrides. Commands are limited to 512 ASCII characters. Only letters, digits, spaces, dots, colons, slashes, underscores, and hyphens are accepted. Shell expansion, quoting, redirection, command chaining, control characters, and newlines are rejected. Hostnames and arbitrary ping flags are not accepted.

Examples:

ping vrf MGMT 192.0.2.1 source Loopback0 repeat 5
ping 192.0.2.1 count 5 routing-instance MGMT
ping -6 -I eth0 -c 5 2001:db8::1

Results:

Each device has a structured entry in metadata.devices containing device, command, output, error, success, and status. The Job also logs each device's output and writes a .txt artifact when command output is available.

• PASS (success: true): at least one reply, according to a recognized packet-loss, success-rate, or received-count summary. Partial loss is PASS.
• FAIL (success: false): total packet loss, a transport failure, or an error processing or storing the result. Inspect error and output to distinguish these cases.
• UNKNOWN (success: null): no recognized summary, an invalid percentage, or conflicting summary verdicts. This never establishes reachability.

The top-level success is true only when every selected device has a PASS result. Nautobot's Job Result status may still be successful when the job completed with FAIL or UNKNOWN results and Fail job on task failure is false. Agent callers must inspect the structured result, not rely on the Job Result status alone.

For a governed agent catalog, classify the Job as read-only and low risk only after restricting the permitted devices and maximum scope. Ping still generates network traffic. Pass explicit device UUIDs through the governed tool so its device scope checks can evaluate the selection. Dynamic Groups can only remove devices from that approved selection, never add devices.

TCP Ping

Opens a TCP connection to a specific host and port to verify that a service is accepting connections. Returns whether the connection succeeded and how long it took.

This tool works in all environments without any additional configuration.

Parameters:

• Target — IP address or hostname
• Port — TCP port number (1–65535)
• Timeout — Connection timeout in seconds (default: 5)

TCP Ping job result showing connection success.

DNS Lookup

Resolves a hostname to its IP address(es) using DNS. Supports both IPv4 (A) and IPv6 (AAAA) record lookups.

When the full DNS tooling is available, you'll see a detailed response including authority and additional sections. Otherwise, the tool falls back to a simpler resolver that returns the resolved addresses.

Parameters:

• Target — Hostname to look up
• Record Type — A (IPv4) or AAAA (IPv6)

DNS Lookup job result showing dig output.

Traceroute

Traces the network path from the Nautobot worker to a target host, showing each hop along the way with its round-trip time. Useful for diagnosing where connectivity breaks down or where latency is introduced.

If the primary method is unavailable in your environment, the tool automatically tries an alternative method.

Parameters:

• Target — IP address or hostname to trace

Traceroute job result showing hops.

HTTP Request

Sends an HTTP GET request to a URL and returns the status code, response headers, and response body. Useful for verifying that a web service is responding.

Parameters:

• Target URL — Full URL including scheme (e.g., https://example.com)
• Timeout — Request timeout in seconds (default: 30)
• Verify SSL — Whether to validate SSL certificates (default: yes)

HTTP Request job result showing status code and response.

SSH Verification

Tests SSH connectivity to a device by performing a login and retrieving basic device information. This validates that Nautobot can communicate with the device using its configured credentials and network driver.

Prerequisites:

• The device must have a primary IP assigned in Nautobot
• The device's platform must have a network driver configured
• Valid credentials must be set up in the Nornir plugin settings (see Nautobot Plugin Nornir)

Parameters:

• Device — Select a device from Nautobot inventory

SSH Verification job result showing a successful connection.

Troubleshooting

If a tool fails unexpectedly, here are some things to check:

1. Is the tool enabled? — Jobs must be enabled by an administrator before they can run. If a tool doesn't appear in the Jobs list, ask your administrator to enable it.
2. Can the worker reach the target? — The tools run on Nautobot worker processes, not on your local machine. The worker must have network access to the target host.