Insights

Best network automation tools for your job

Ansible, Nornir, NAPALM and NetBox serve different roles; compare their responsibilities and plan a device-level preview and recovery test.

Illustration of ratcheting wrench with fitted socket.
On this page

Ansible is a strong choice for repeatable network playbooks. Choose Nornir for workflows you write in Python, NAPALM for common device operations on supported drivers, and NetBox for authoritative inventory. These tools serve different jobs and can work together.

In short:

  • Ansible or Nornir. Choose repeatable playbooks or workflows you maintain in Python.
  • NAPALM and NetBox. Use supported device operations and authoritative inventory as separate layers.
  • Keep what works. Add missing capabilities and test preview and recovery before allowing changes.

Choose the tool that matches your job

Choose by the work you need done, your skills and your devices.

Tool and jobWhat you needMain limitChoose or keep
Ansible: repeatable playbooksCompatible devices, collections, network skillsRequired collection coverageExisting playbooks fit the job
Nornir: Python workflowsPython code and task pluginsDevice functions depend on pluginsYou want to maintain Python workflows
NAPALM: device configuration and stateA supported driver and methodsDriver-specific operation supportRequired device methods are supported
NetBox: authoritative inventoryAgreed ownership and validated recordsInventory, not deploymentYou can maintain trusted infrastructure data

Ansible and Nornir coordinate work. NAPALM provides a common interface for device operations, including configuration changes, not just read-only queries. NetBox is a source of truth: the agreed authority for a defined set of infrastructure data. It isn't a deployment engine.

Keep what works and add the missing piece

A proposed workflow starts with agreed inventory, uses Ansible or Nornir to coordinate tasks, and uses supported modules or libraries for device operations. Check the connections between those layers instead of assuming a ready-made integration.

Keep Ansible when your playbooks and collections cover the job. Its first-playbook prerequisites include compatible devices, basic Linux command-line skills and switch or router knowledge. These recommendations concern playbooks and collections, not a subscription-platform buying decision.

Choose Nornir when maintaining Python workflows fits your team. Its documentation imports nornir_napalm and nornir_utils separately, so those plugins' functions aren't core Nornir capabilities. Add NAPALM where the required driver methods are supported. Keep another source of truth for domains maintained better elsewhere, with clear agreement about authority, because NetBox validation still needs human judgment.

Try one change and one recovery path in a lab

Use this documentation-based evaluation on an isolated device you own or administer. Preserve a secure baseline backup and arrange independent console or other recovery access. The Python fragment below is for a Linux control host with a prepared device session, not a universal script.

1. Check the driver and device.

Use NAPALM's ios driver as the example only after checking your exact device release, installed driver and platform caveats. The support matrix lists configuration comparison, rollback and commit confirmation for IOS, but that doesn't approve every model or release. Stop at preview and discard if required recovery support or independent access is missing.

2. Verify identity and collect the baseline.

Check the Secure Shell (SSH) host-key fingerprint for LAB_DEVICE_ADDRESS against a trusted record. A successful login doesn't prove identity.

NAPALM documents these optional arguments for its IOS driver: set ssh_strict and alt_host_keys to true, with alt_key_file pointing to TRUSTED_HOST_KEYS_FILE. Populate that file from independently verified host keys. Pass the options when constructing the driver, using the connection and credential method documented for your installed version, then open the session. Don't disable host-key checking to make a failed connection succeed.

Use LAB_USERNAME for your authorized account. Collect supported facts, running configuration and service checks relevant to the task, then save the baseline securely. The options above describe the documented controls; they don't establish a tested setup for your particular device release or SSH backend.

3. Preview and discard a reviewed change.

Use a small, administrator-reviewed merge candidate, a file containing the change you want to add. In the prepared session, load it, print the proposed differences and discard it:

device.load_merge_candidate(filename="REVIEWED_CANDIDATE_FILE")
print(device.compare_config())
device.discard_config()

Expect only the reviewed changes in the diff. Unexpected differences mean discard and review before retrying. A candidate diff doesn't prove service health, and Nornir's dry_run flag isn't a universal no-write guarantee. Close the session when the preview-only evaluation ends.

4. Reload the candidate and choose exactly one branch.

For a separate change run, open a verified session and reload the reviewed candidate. Choose one alternative below. Don't run these branches in sequence.

  • Ordinary commit and manual recovery: Call commit_config, then verify the desired configuration and relevant services. Call supported rollback, verify the restored baseline and services, then call close.
  • Timed recovery drill: Call commit_config with revert_in set to APPROVED_SECONDS, then check that has_pending_commit is true. Deliberately don't call confirm_commit. After expiry, verify the restored baseline, restored services and that has_pending_commit is false. Call close, without calling rollback after the timer has restored the baseline.
  • Successful timed confirmation: Use supported commit_config with revert_in set to APPROVED_SECONDS. Verify the desired configuration and services before expiry, then call confirm_commit only if those checks pass. If checks fail, don't confirm and follow your preselected recovery plan. After successful confirmation, verify that has_pending_commit is false, then call close.

Configuration checks show whether the intended state is present. Service checks show whether the functions you tested still work. A successful commit alone proves neither.

5. Record the outcome and stop on surprises.

Record device and library versions, driver, input file, diff, verification results and recovery outcome. Unexpected post-change state means stop further deployment and use your selected recovery path. If the session drops, reconnect through independently verified access. A passed lab qualifies the tested workflow, not all devices or a network-wide rollout.

Where doxx.net fits. Agents configure the doxx.net network through its application programming interface (API) and get controlled network access. For that network-specific need, not as a replacement for these tools, you can create a doxx.net account, download the app and connect a device or agent.

Ask an AI assistant

Share this article

Private Everywhere

Stop giving the internet everything

Keep your browsing, messages, files, and agents private.