1. Network Automation and Orchestration with Saltstack
Adam Pavlidis

2. Common Problems/Concerns
Orchestrating Manual Operations
Provisioning and Managing Services
Coordinating actions across multiple devices
Reacting to disasters and emergencies
Configuration Management and Compliance
Updating Policies (e.g. Security)
Garbage Collection
Heterogeneous, Multi-vendor environments
Device-specific context and capabilities
Data modeling (e.g. YANG)
Management API/Protocol

3. Network Automation & Orchestration
Streamlining Workflows (Imperative Orchestration)
Execute batches of actions
Dependency checking (first do X then Y)
Configuration Management (Declarative Automation)
Describe & Apply a desired state
Modeling infrastructure data
Solutions
Enterprise software
Custom Scripts
Open Source Tools & Frameworks
+++ management protocols +++
SSH, SNMP, NETCONF, …, vendor APIs

4. Network Automation and Programmability Abstraction Layer with Multivendor support - NAPALM
Unified Interface for multivendor device management ,
Python-based library
Supported OS
eos, junos, ios-xr, nx-os, ios
vyos, cumulus, asa, dellos10, ros, fortios
Functionality
“getters”
bgp, routes, interfaces, ips, arp, mac
“Configuration & Templates (Jinja2)”
load, compare, discard, rollback, commit
*Parsing and Handling Logs*
*Compliance* (Desired State vs Reality)

5. SaltStack Platform Automation & Configuration Management Framework
Python-based, Open Source and Enterprise
Event-based Architecture
Define, Fire and React to specific events
Master – Minion (agent needed)
Remote Execution of commands
Applying State (SaLt State Files – SLS)
Data Sources
Grains Retrieve “static” data from minions, e.g. OS
Pillar Master provided data for minions, e.g. Users
source:

6. But what about the network gear!?
1 minion => 1 network device
Proxy Minions
NAPALM, Junos, Cisco NXOS & NSO, DIY
Directly installed on devices
Arista EOS, Cumulus
Connections maintained open (keep alive mechanism)
Efficient task distribution to minions/devices
Multivendor (Proxy / NAPALM driver)
“Grains” for delegating tasks and manipulating configuration
Deploy based on Custom labels: “Border_Routers”, “Core_Switches”
Organizing Configuration Templates per OS/Chassis

7. Key Principles Service-centric data => Device-specific data
Pillar data are assigned per minion
Independent workflows and actions
Respect Dependencies
Reuse as much as possible
Modular components
Abstract “ugly” internals
Developed a Python Library

8. @Lamda Hellix – Workflows (1/2)
Actions / Workflows => Configuration Lines
Primitives
Low-level device agnostic actions (ospf, acl, prefix-set, swport)
Use Salt+NAPALM to generate device-specific configuration
Orchestration Workflows
primitives + workflows* = workflow
procedural (Sequential actions)
Create new l3 iface (disabled)
Disable old l3 iface
Enable new l3 iface
Workflow
Primitives

9. @Lamda Hellix – Workflows (2/2)
In-house CLI Utility
Select workflow
Display related Primitive actions
Generate Configuration Files (Salt+NAPALM) File name represents: Device, Dependency, Action
Optionally: Pause and Inspect
Order, Aggregate, Deploy (Salt+NAPALM)

10. @Lamda Hellix – Config Management
High-Level Files describing the desired State
Network-wide Configuration
AAA & Users
SNMP
Logging
Device-specific
Upstreams
Customer Services
Interfaces, ACL, VRRP/HSRP, BGP
Well suited for Compliance

11. Complete Lifecycle Management

12. Challenges Theory vs Reality  Reduce manual configs
Cover corner cases
Layers of abstraction
Troubleshooting
Consistency
Maintain clean, reusable workflows
Concurrency and Locking

13. Thank you! Adam Pavlidis Thank you very much for your time.