Device Types

Overview

Every device in NetStacks has a device_type string. The Controller uses it to pick a CLI driver that knows which command disables paging, which command captures the running configuration, and which prompt suffix to wait for. Picking the right device_type matters — a Juniper Junos box configured as cisco_ios will be sent show running-config instead of show configuration | display set and the capture will fail or return an error string instead of config.

The device_type strings follow Netmiko-style naming (cisco_ios, arista_eos, juniper_junos, and so on), so the same identifiers you use in Netmiko, NAPALM, or Nornir map cleanly onto NetStacks.

Supported Device Types

The table below lists the CLI drivers built into the Controller's config collector. Each row shows the recommended device_type string, the command used to disable paging, and the command used to capture the running configuration. Matching is case-insensitive and treats hyphens and underscores the same (so cisco-ios and cisco_ios resolve to the same driver).

Several aliases resolve to these same drivers. For example router, switch, and cisco resolve to the cisco_ios driver; nexus resolves to cisco_nxos; nxos, junos, eos, panos, fortigate, and bigip resolve to their obvious platforms. A device_type of network_device or other falls back to a generic Cisco-style driver (terminal length 0 + show running-config).

How Drivers Work

When the Controller collects a configuration over SSH, the selected driver defines four things:

• Disable-paging command — sent first so the device streams the whole config without "--More--" prompts. For example terminal length 0 on Cisco IOS, set cli screen-length 0 on Junos, or set cli pager off on PAN-OS.
• Show-config command — the command that returns the running configuration, such as show running-config or, on Junos, show configuration | display set.
• Prompt suffix — the character the collector waits for to know a command has finished. Most CLIs end an exec prompt with #; Junos and PAN-OS operational mode use >; Linux shells use $.
• Post-login delay — a short pause after login before commands are sent, tuned per platform (for example PAN-OS waits longer than Arista EOS) so slow-initializing CLIs are ready.

The same driver table also backs SSH health checks, where each platform maps to its own uptime, CPU, memory, and interface-status commands (for example show interfaces terse on Junos vs. show ip interface brief on Cisco IOS).

device_type vs platform

A device has two distinct, independent fields:

device_type (required)

The CLI driver selector described on this page (for example cisco_ios, arista_eos, juniper_junos). It controls screen-scraped CLI collection and health checks over SSH.

platform (optional)

A structured-config catalog entry used for model-driven transports. These are seeded in the Controller's platform catalog and include eos-gnmi (Arista EOS over gNMI), junos-netconf (Juniper over NETCONF), iosxr-netconf (IOS-XR over NETCONF), eos-eapi (Arista eAPI), and panos-rest (PAN-OS REST). You can list them with the platforms endpoint shown below.

When a device has a platform set, drivers honor a small set of platform aliases (such as ios-xr, nxos, eos, junos, panos) before falling back to the device_type match. For pure CLI capture you only need device_type; set platform when you intend to use gNMI/NETCONF/REST config management.

# List the structured-config platform catalog
curl -s http://localhost:3000/api/config/platforms \
  -H "Authorization: Bearer ${TOKEN}" | jq '.[] | {name, display_name, transport, default_port}'

Setting the Device Type

Choosing the right string

1. Identify the vendor and OS. If unsure, SSH in and run show version (Cisco/Arista), show system information (Junos / PAN-OS), or check the login banner.
2. Match the result to the table above. A Catalyst 9300 running IOS-XE uses cisco_ios; a Nexus 9000 running NX-OS uses cisco_nxos; an ASR 9000 running IOS-XR uses cisco_ios_xr.
3. Set that string as the device_type when you add the device in the admin UI, import a CSV/JSON inventory, or sync from NetBox.

Changing it later

1. Open the device in the admin UI and edit it (or call the update API).
2. Change the device_type to the correct string and save.
3. The new driver applies on the next collection. Existing stored configs are not rewritten.

Code Examples

Per-platform capture sequence (what the collector sends)

# Cisco IOS / IOS-XE  (device_type: cisco_ios)
terminal length 0
show running-config

# Cisco NX-OS  (device_type: cisco_nxos)
terminal length 0
show running-config

# Cisco IOS-XR  (device_type: cisco_ios_xr)
terminal length 0
show running-config

# Cisco ASA  (device_type: cisco_asa)
terminal pager 0
show running-config

# Arista EOS  (device_type: arista_eos)
terminal length 0
show running-config

# Juniper Junos  (device_type: juniper_junos)
set cli screen-length 0
show configuration | display set

# Palo Alto PAN-OS  (device_type: paloalto_panos)
set cli pager off
show config running

# Fortinet FortiOS  (device_type: fortinet_fortios)
config system console
set output standard
end
show full-configuration

# F5 BIG-IP  (device_type: f5_bigip)
tmsh modify cli preference pager disabled
tmsh list /

# Linux  (device_type: linux)
cat /etc/network/interfaces 2>/dev/null || ip addr show

Filter devices by type via the API

# List Cisco IOS devices
curl -s "http://localhost:3000/api/devices?device_type=cisco_ios" \
  -H "Authorization: Bearer ${TOKEN}" | jq '.devices[] | {name, host, site}'

# List Juniper Junos devices
curl -s "http://localhost:3000/api/devices?device_type=juniper_junos" \
  -H "Authorization: Bearer ${TOKEN}" | jq '.devices[] | {name, host}'

# Combine device_type with a site filter
curl -s "http://localhost:3000/api/devices?device_type=arista_eos&site=dc-east" \
  -H "Authorization: Bearer ${TOKEN}" | jq '.devices | length'

Update a device's type via the API

# Correct a device that was added with the wrong driver
curl -X PUT "http://localhost:3000/api/devices/${DEVICE_ID}" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"device_type": "cisco_nxos"}'

Questions & Answers

Q: Which device_type strings does NetStacks support for CLI capture?

A: cisco_ios (IOS/IOS-XE), cisco_nxos (NX-OS), cisco_ios_xr (IOS-XR), cisco_asa (ASA), arista_eos (EOS), juniper_junos (Junos), paloalto_panos (PAN-OS), fortinet_fortios (FortiOS), f5_bigip (BIG-IP), and linux. Aliases like router, switch, nexus, and nxos resolve to the matching driver, and network_device / other fall back to a generic Cisco-style driver.

Q: Does NetStacks auto-detect the platform?

A: No. The Controller does not probe a device to guess its CLI platform. You set the device_type explicitly when adding, importing, or syncing a device. Testing a credential reports only whether the SSH connection succeeded — it does not return a detected platform.

Q: Why was the IOS-XR string changed to cisco_ios_xr?

A: cisco_ios_xr (also accepted as iosxr) is the identifier the Controller's drivers match. Use it for ASR 9000, NCS 5500, and XRv platforms.

Q: What if my exact platform is not listed?

A: Use network_device (generic Cisco-style: terminal length 0 + show running-config) or linux for Linux-like CLIs. Capture works only if those default commands are valid on your device; otherwise the collection will error and you should capture manually through an interactive terminal session.

Q: What is the difference between device_type and platform?

A: device_type selects the screen-scraped SSH CLI driver (capture command, paging, prompt). platform is an optional structured-config catalog entry (such as iosxr-netconf or eos-gnmi) used for model-driven gNMI/NETCONF/REST config management. They are separate fields.

Q: What is the difference between cisco_ios and cisco_ios_xr?

A: Both currently use terminal length 0 and show running-config, but they map to different health-check command sets (for example IOS-XR uses show ipv4 interface brief and show memory summary). Using the correct string keeps health checks and any platform-specific behavior accurate.

Troubleshooting

"Unsupported device type" error

The device_type string does not match any driver or alias. Set it to one of the values in the table above (for example cisco_ios or arista_eos), or use network_device as a generic fallback.

Config capture returns an error string or partial output

The driver is sending the wrong command for the real platform. SSH in manually, confirm the platform with show version (or show system information on Junos/PAN-OS), then correct the device_type so the right capture and paging commands are used.

Capture stalls or times out

If paging was not disabled, the device may be waiting at a "--More--" prompt. Verify the device_type matches the platform so the correct disable-paging command (for example set cli screen-length 0 on Junos) is sent before the show command.

Vendors without a dedicated driver

For platforms such as Ubiquiti EdgeOS, MikroTik RouterOS, or HPE/Aruba switches, there is no purpose-built driver. Use network_device or linux and verify the default capture command works, or capture configuration manually through an interactive terminal session.

Related Features

• Adding Devices — add devices and assign a device_type (UI, CSV/JSON, or NetBox)
• Config Snapshots — platform-aware config capture driven by the device_type
• NetBox Integration — NetBox platform slugs map to NetStacks device_type and platform
• Connecting to Devices — interactive SSH access, used for manual capture on unsupported platforms
• Config Diff & History — compare captured configurations across snapshots