Network Automation and Orchestration with Saltstack Adam Pavlidis

Network Automation and Orchestration with Saltstack Adam Pavlidis

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

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

Network Automation and Programmability Abstraction Layer with Multivendor support - NAPALM Unified Interface for multivendor device management https: //napalm-automation. net/ , https: //github. com/napalm-automation § Python-based library § Supported OS q q eos, junos, ios-xr, nx-os, ios vyos, cumulus, asa, dellos 10, ros, fortios § Functionality q “getters” □ q “Configuration & Templates (Jinja 2)” □ q q bgp, routes, interfaces, ips, arp, mac load, compare, discard, rollback, commit *Parsing and Handling Logs* *Compliance* (Desired State vs Reality)

Salt. Stack Platform § Automation & Configuration Management Framework q Python-based, Open Source and Enterprise § Event-based Architecture q Define, Fire and React to specific events § Master – Minion (agent needed) q q Remote Execution of commands Applying State (Sa. Lt State Files – SLS) § Data Sources q q Grains Retrieve “static” data from minions, e. g. OS Pillar Master provided data for minions, e. g. Users source: https: //docs. saltstack. com/en/getstarted/

But what about the network gear!? § 1 minion => 1 network device q q § § 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 q q Deploy based on Custom labels: “Border_Routers”, “Core_Switches” Organizing Configuration Templates per OS/Chassis

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

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

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

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

Complete Lifecycle Management

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

THANK YOU! Adam Pavlidis https: //gr. linkedin. com/in/adam-pavlidis