Blog

Automating SONiC Switch Deployments with Ansible and Zero-Touch Provisioning

Learn how SONiC's open-source, container-based architecture enables Ansible automation and zero-touch provisioning for Australian data centre and campus networks.

By xSONiC Team · · SONiCopen networkingdata centerAI fabricEthernetautomation

For Australian network teams managing growing data centre and campus environments, manual switch configuration is no longer sustainable. Every hour spent logging into individual switches, copying configs, and troubleshooting provisioning errors is an hour lost to higher-value work.

SONiC — Software for Open Networking in the Cloud — offers a foundation that makes large-scale network automation genuinely achievable. Its Linux-based, containerised architecture, JSON configuration model, and broad multi-vendor support create natural integration points for tools like Ansible and zero-touch provisioning frameworks.

This guide walks through how SONiC’s design enables automation, what a practical ZTP workflow looks like, and how Ansible fits into the picture.

Why SONiC Is Built for Automation

SONiC is not just another network operating system with a scripting bolted on after the fact. Its architecture was designed from the ground up to be programmable.

Container-Based, Linux-Native Design

SONiC runs each network function — BGP, LLDP, DHCP, and others — in its own Docker container on top of a Debian Linux base. This matters for automation because:

  • Each container can be managed, restarted, or updated independently.
  • Standard Linux tooling (bash, Python, systemd) is available natively on the switch.
  • Configuration state is centralised in a Redis-based database (CONFIG_DB), giving automation tools a single source of truth to read from and write to.

This containerised approach also provides better fault isolation. If the BGP container has an issue, it does not necessarily take down the entire switch management plane.

JSON-Based Configuration

SONiC uses JSON-format configuration files as its primary configuration model. This is a significant advantage for automation because:

  • JSON is natively parseable by virtually every programming language and automation framework.
  • Configuration templates can be rendered from Jinja2 templates in Ansible, making it straightforward to generate switch-specific configs from shared variables.
  • The config_db.json file serves as the canonical configuration state, which can be backed up, diffed, and version-controlled like any other code artifact.

Multi-Vendor, Multi-ASIC Support

SONiC runs on switches from multiple hardware vendors and across different ASIC platforms. For Australian organisations that want to avoid single-vendor lock-in, this means the same automation playbooks and ZTP workflows can potentially target switches from different manufacturers — provided the SONiC image version and ASIC are compatible.

Always check the official SONiC supported devices and platforms list before assuming compatibility.

Zero-Touch Provisioning: The Basics

Zero-touch provisioning (ZTP) is the process of getting a switch from an unboxed, factory-default state to a fully configured and production-ready device with minimal or no manual intervention.

On SONiC switches, ZTP typically works through a DHCP-based discovery mechanism:

  1. Switch boots for the first time. SONiC starts with a default configuration.
  2. DHCP interaction. The switch sends a DHCP request. A DHCP server responds with options that point to a provisioning script or configuration file location (often via TFTP or HTTP).
  3. Script execution. The switch downloads and executes the provisioning script. This script can install a specific SONiC image, push a config_db.json file, or trigger further configuration steps.
  4. Configuration applied. The switch reboots or reloads its configuration to apply the desired state.

This process means that a technician in a data centre or branch office can rack a switch, connect it to the management network, and walk away. The switch provisions itself.

What You Need for ZTP

  • A DHCP server configured with appropriate options for SONiC ZTP.
  • A reachable HTTP or TFTP server hosting SONiC images and configuration templates.
  • Pre-generated configuration files or provisioning scripts for each switch role (leaf, spine, management, etc.).
  • Network connectivity between the switch management port and the provisioning infrastructure.

Ansible and SONiC: How They Fit Together

Ansible is a natural choice for SONiC automation for several reasons:

  • Agentless. Ansible connects to switches over SSH. SONiC’s Linux base means SSH is available out of the box.
  • Idempotent. Well-written Ansible playbooks only make changes when needed, reducing the risk of unintended configuration drift.
  • Inventory-driven. You can define your entire network topology in Ansible inventory files, grouping switches by role, site, or function.
  • Community modules. The SONiC community maintains Ansible modules and roles for common tasks like pushing configurations, managing VLANs, and verifying state.

Typical Ansible Workflow for SONiC

A basic workflow looks like this:

  1. Define inventory. List all SONiC switches in an Ansible inventory, grouped by role (leaf, spine, border leaf, etc.) and site.
  2. Create configuration templates. Use Jinja2 templates to generate config_db.json files for each switch role. Variables like hostname, IP addresses, VLAN assignments, and BGP neighbours are pulled from inventory or group variables.
  3. Push configurations. Use Ansible playbooks to copy the generated configuration to each switch and trigger a config reload.
  4. Verify state. Run validation playbooks that execute SONiC CLI commands (show interfaces status, show ip route, show bgp summary) and check that the output matches expected values.
  5. Ongoing management. Use Ansible for firmware upgrades, configuration backups, compliance checks, and change management.

Combining ZTP with Ansible

ZTP and Ansible are complementary, not competing approaches:

  • ZTP handles Day 0. It gets the switch from bare metal to a base SONiC configuration with network connectivity.
  • Ansible handles Day 1 and beyond. Once the switch is reachable on the network, Ansible takes over for detailed configuration, ongoing management, and compliance enforcement.

A practical combined workflow for an Australian data centre might look like:

  1. Switch arrives at the facility.
  2. Technician racks and cables the switch.
  3. ZTP provisions a base image and management IP.
  4. Ansible discovers the new switch (via dynamic inventory or a CMDB trigger).
  5. Ansible applies the full role-specific configuration.
  6. Validation playbooks confirm the switch is production-ready.

Choosing Your SONiC Automation Approach

FactorZTP OnlyAnsible OnlyZTP + Ansible
Day 0 provisioning speedFastSlow (manual discovery)Fast
Day 1+ configuration depthLimitedFullFull
Ongoing complianceNoYesYes
Infrastructure requiredDHCP + TFTP/HTTPSSH + Ansible control nodeBoth
Best forRemote/branch sitesExisting managed networksGreenfield data centres

Common Pitfalls for Australian Teams

  • ASIC compatibility gaps. Not all SONiC images support all ASICs. Verify before ordering hardware.
  • Image version drift. ZTP scripts and Ansible playbooks must target a specific SONiC version. Version mismatches are a common source of failures.
  • DHCP scope sizing. Ensure your management VLAN DHCP scopes are large enough for the number of switches being provisioned.
  • Template complexity. Start with simple configurations and iterate. Trying to template everything on day one leads to unmanageable playbooks.
  • Australian timezone and support. Open-source SONiC community support operates globally. Consider whether your team needs a local support arrangement for production environments.

Next Steps

If you are exploring SONiC for your Australian network:

  1. Review the SONiC supported devices list to confirm hardware compatibility.
  2. Set up a lab environment with a single SONiC switch and an Ansible control node.
  3. Start with a simple playbook that pushes a base configuration and validates it.
  4. Build out ZTP scripts for your specific provisioning workflow.
  5. Reach out to the xSONiC team for guidance on hardware selection and pre-validated configurations.

SONiC’s open, Linux-based architecture removes many of the barriers that have historically made network automation painful. With the right tooling and a phased approach, Australian network teams can achieve genuinely hands-off switch provisioning at scale.

Sources Reviewed