Infrastructure as Code: Using SaltStack for Network Configuration
This post introduces SaltStack as an infrastructure as code tool for network configuration. It walks through setting up proxy minions for agentless network devices, writing NAPALM-backed state files, and applying configuration changes using Salt's master/minion architecture.
Network engineers are increasingly expected to manage infrastructure through code rather than manual CLI sessions. Infrastructure as code (IaC) brings repeatability, version control, and scalability to network configuration, and SaltStack is one of the most powerful tools available for doing exactly that. If you are familiar with Ansible but want to explore an event-driven, agent-capable alternative, SaltStack is worth your attention.
What Is SaltStack?
SaltStack (often just called Salt) is an open-source automation and configuration management platform originally developed by Thomas Hatch in 2011. It was acquired by VMware in 2020 and continues to be managed under VMware, which is itself now a subsidiary of Broadcom. Salt uses a master/minion architecture where a central Salt Master pushes configuration to Salt Minions running on managed nodes. For network devices that cannot run an agent, Salt also supports an agentless proxy minion model, which is the approach most network engineers will use.
Salt communicates over a high-speed message bus using ZeroMQ, making it extremely fast compared to SSH-polling tools. It also supports event-driven automation, meaning you can trigger configuration changes in response to real-time events on your network.
Core Concepts Before You Start
Before diving into network configuration, you need to understand three Salt building blocks:
- States: declarative configuration files written in YAML that describe the desired state of a system
- Grains: static data about a minion, such as its OS, role, or device type
- Pillars: sensitive or environment-specific data stored securely on the master and pushed to minions on demand
These three components work together to give you flexible, data-driven network configuration management.
Setting Up a Proxy Minion for Network Devices
Most network devices cannot run a Salt Minion directly. Instead, you run a proxy minion on a Linux host that acts as an intermediary between the Salt Master and your router or switch. Salt supports several network proxy modules, including napalm, which works with Cisco IOS, NX-OS, Junos, EOS, and more.
First, install the required packages on your proxy host:
pip install salt napalmNext, define your proxy configuration in /etc/salt/proxy:
master: 192.168.1.10Then create a pillar file that describes the device connection details. In /srv/pillar/router01.sls:
proxy:
proxytype: napalm
driver: ios
host: 192.168.1.1
username: admin
password: secretpasswordStart the proxy minion process targeting your device:
salt-proxy --proxyid=router01 -dAccept the minion key on the master:
salt-key -a router01Verify connectivity with a test ping:
salt router01 test.pingWriting a Network State File
Once your proxy minion is connected, you can write Salt states to manage configuration. The napalm module provides execution functions that let you apply configuration templates using Jinja2.
Create a state file at /srv/salt/ntp_config.sls:
configure_ntp:
napalm.load_template:
- template_name: salt://templates/ntp.j2
- test: FalseCreate the Jinja2 template at /srv/salt/templates/ntp.j2:
ntp server 10.0.0.1
ntp server 10.0.0.2
ntp source Loopback0Apply the state to your device:
salt router01 state.apply ntp_configSalt will render the template, connect to the device via NAPALM, and apply the configuration. The output confirms which changes were committed and whether any errors occurred.
Why SaltStack Stands Out for Network Automation
Salt offers several advantages that make it compelling for infrastructure as code in networking environments:
- Speed: ZeroMQ-based communication is significantly faster than SSH polling
- Targeting flexibility: apply states to devices based on grains like role, site, or platform using a single command
- Event-driven automation: trigger remediation or configuration pushes automatically when a device reports an event
- Idempotency: Salt states only make changes when the current state differs from the desired state
What's Next
Now that you understand how SaltStack connects to network devices and applies configuration through states, the next step is exploring Salt's reactor system. The reactor allows you to define automated responses to network events, which takes your infrastructure as code practice from scheduled configuration pushes to true event-driven network automation. We will cover that in an upcoming post.