Ansible :hearts brownfield networksCommitted to you on Day 2Bradley A. ThorntonSenior Principal Engineertwitter: @codethenetwork

My automation story

1. How did I get started with Ansible?

2. How long have I been using it?

3. What's your favorite thing to do when you Ansible?

Overview

1. The network automation journey and it’s pitfalls2. Ansible has been a one way street3. Building technical debt4. The promise and cost of structured data5. Introducing resource modules and facts6. Brownfield use-cases7. Ansible 2.9

ANSIBLE NETWORK AUTOMATION

ansible.com/for/networksgalaxy.ansible.com/ansible-network

Ansible Network modules comprise 1/3 of all modules that ship with Ansible Engine

1,000+ NetworkModules

65+ Network

Platforms

15 Galaxy

Network Roles

Ansible Network modules comprise 1/3 of all modules that ship with Ansible Engine

More than 4M customer systems worldwide now automated by Red Hat Ansible Automation

Ansible Network modules comprise 1/3 of all modules that ship with Ansible Engine

A10

Apstra AOS

Arista EOS, CVP

Aruba ArubaOS

AVI Networks

Big Switch Networks

Brocade Ironware

Cisco ACI, AireOS, ASA, FTD, IOS, IOS-XR, Meraki, NSO, NX-OSCheck Point

Citrix Netscaler

Ingate SBC

Itential

Juniper JunOS

Lenovo CNOS,

ENOS

Mellanox ONYX

MikroTik RouterOS

Openswitch (OPX)

Ordnance

NETCONF

Netvisor

AVAILABLE NETWORK PLATFORMSCumulus Linux

Dell OS6, OS9, OS10

Exoscale

Extreme EX-OS, NOS,

SLX-OS, VOSS

F5 BIG-IP, BIG-IQ

Fortinet FortIOS, FMGR

FRR

Huawei CloudEngine

Illumos

Infoblox NIOS

Nokia NetAct, SR OS

Nuage VSP

OpenSwitch

Open vSwitch (OVS)

Palo Alto PAN-OS

RESTCONF

Skydive

Ubiquiti EdgeOS,EdgeswitchVyOS

Ansible Network modules comprise 1/3 of all modules that ship with Ansible Engine

7 Platforms28 Modules

17 Platforms141 Modules

29 Platforms267 Modules

33 Platforms463 Modules

2.1May 2016

2.2Oct 2016

2.3Apr 2017

2.4Sep 2017

NETWORK AUTOMATION PROGRESS

40 Platforms572 Modules

2.5Mar 2018

45 Platforms639 Modules

2.6Jun 2018

50 Platforms700 Modules

2.7Oct 2018

65 Platforms1,088 Modules

2.8May 2019

WE ARE ON A JOURNEY TOGETHER

What can Ansible do? vs. How is Ansible being used?

NETWORK AUTOMATIONCrawl

Automation is ad hoc and used as neededPer device changesConfiguration changes are additive

Why didn’t we start sooner?How do I get everyone on board?How do I share my playbooks?

SpeedConsistencyDecreased human error

NETWORK AUTOMATIONWalk

Building a configuration data inventory Templating configuration using jinja alongside config modulesDevices are managed in groupsUsing higher order Ansible modules, (vlan, interface)

Where is the Ansible xxx module?How do I parse this with Ansible?How do we reconcile the Ansible inventory data?

Source of truth is migrating incrementallyPlaybooks are repeatable processesTrust building in automation as a platform

NETWORK AUTOMATIONRun

Dynamic inventory scripts for external data sourcesParsing configuration and operating state dataSource of truth migration continues

What about “out-of-band” changes?How do we detect configuration drift with Ansible?Why are playbooks runs manually triggered?

Operating state data used to measure change successEnterprise standards are enforcedThe network automation pattern has been established

NETWORK AUTOMATIONFly

Integration with external infrastructure platformsEvent driven automationFocus switches to data management from configuration mgmtSource of truth established

Ongoing source of truth managementTemplate upkeep and maintenanceHow can we make it simpler?

Changes become unattendedAutomation “corrects” manual changesConfiguration drift is minimized

ARE WE DONE?

1. Many complex jinja templates2. Templates are fragile and assume a specific data

structure3. Complex inventory4. Unanswered questions concerning ongoing data

management5. Automation platform support is internal6. Ansible is still primarily used to template and push

configuration

BUILDING ON ANSIBLE ENGINE TODAY

Configuration managements remains at the heart of network automation and the native capabilities of Ansible today are primary focused on one-way operations.

1 : 1

running.cfg

nxos101.company.net

many : 1group_vars/atlanta/vlans

atlsw1 atlsw2

atlsw3 atlsw4

all : 1group_vars/all/snmp

ios iosxr

junos nxos

eos

vyos

THE PROMISE OF STRUCTURED DATA

MANAGING STRUCTURED DATA

“...within Ansible and Jinja, it is not as easy or well defined. The user must understand the scoping limitations, and how to navigate through them, in addition to the syntax, which is not always obvious.” - Ken Celenza, NTC

THE COST OF STRUCTURED DATA

PARSERETRIEVE CONFIGURATION

PERSIST

INVENTORY TEMPLATE PUSH CONFIGURATION

NATIVE ANSIBLE ENGINE CAPABILITIES

CONFIGURATION FACTS

STRUCTURED DATA

RESOURCE MODULES

PARSE TEMPLATE

CONFIGURATION FACTS

CONVERT TO STRUCTURED

DATA

snmp: communities: <list> - community: <string> group: <string> ipv4acl: <string> ipv6acl: <string> contact: <string> location: <string> users: <list> - algorithm: <md5|sha> group: <string> localized_key: <bool> password: <string> username: <string>

NETWORK NATIVE

CONFIGURATION(ON BOX)

RESOURCE MODULES

RESOURCE MODULE

snmp: communities: <list> - community: <string> group: <string> ipv4acl: <string> ipv6acl: <string> contact: <string> location: <string> users: <list> - algorithm: <md5|sha> group: <string> localized_key: <bool> password: <string> username: <string>

NETWORK NATIVE

CONFIGURATION(ON BOX)

DAY 2 USE CASES

BROWNFIELD INVENTORY GENERATION● Gather facts from brownfield devices● Persist the facts to the file system, check into SCM, SOT etc● Use the facts as the inventory for subsequent playbook runs

- hosts: all module_defaults: nxos_facts: gather_subset: min gather_network_resources: - all gather_facts: true tasks: - name: Save the network change log for each host to a file copy: content: "{{ ansible_network_resources|to_nice_yaml }}" dest: "inventory/host_vars/{{ inventory_hostname }}/default.yaml"

DETECT CONFIGURATION DRIFT

23

● Use previously stored facts as inventory● Run ansible in checkmode to detect proposed changes● `overridden` would repair manual configuration changes and remove extra ACLs

- hosts: nxos gather_facts: false tasks: - name: Push the configuration in check_mode (previously gathered facts) nxos_acls: config: "{{ acls }}" state: overridden check_mode: yes register: running_config

- assert: that: not running_config.changed

ROLLBACK● Register the results of and configuration changes● Perform basic health checks on the devices, ping, neighbor health etc.● If the health checks fail, reapply the original configuration

- hosts: nxos gather_facts: false tasks: - name: Replace the onbox config with recently updated inventory nxos_bgp: config: "{{ bgp }}" state: merged register: my_config_change < check device health as needed, ping, check neighbor status > - name: Replace the onbox config the original pre-change config nxos_bgp: config: "{{ my_config_change['before'] }}" state: overridden when: health_check.failed

IDEMPOTENT BY DESIGNFacts will always be returned in the same shape the corresponding module expects

- hosts: nxos module_defaults: nxos_facts: gather_network_resources: - interfaces gather_facts: true tasks: - name: Replace the config with the gathered facts nxos_snmp: config: "{{ ansible_network_resources[‘interfaces] }}" state: replaced register: result - assert: that: not result.changed

SOURCE OF TRUTH MIGRATION

state: merged state: replaced

state: overridden

RESOURCE MODULE BEHAVIOUR

RESOURCE MODULE RETURN● before: Resource modules leverage the facts subsystem to collect the native

network configuration and convert it to structured data. The configuration prior to module execution is always returned.

● commands: Resource modules compare the user provided data to the `before` and generate a delta command set for the device

● after: If commands have been issued on the device, use the facts subsystem to collect the configuration post module execution

MODULES & FACTS ROADMAP

28

FOUNDATION● AAA, API, Banners, Local users,

Logging, Mgmt, NTP, Sflow, SNMP, System, VTY

OPERATION● File, Ping, Traceroute

POLICY● ACLs, Prefix lists, QOS, Route maps● ACL interfaces, QOS interfaces

SERVICES● DHCP, GLBP, HSRP, LLDP, UDLD, VPC,

VRRP, VTP● GLBP interfaces, HSRP interfaces, LLDP

interfaces, UDLD interfaces, VPC interfaces

TOPOLOGY● BGP, IGMP, OSPF, RIP, PIM● VRFS, VLAN● Interfaces, L2 interfaces, L3 interfaces,

IGMP interfaces, OSPF interfaces, PIM interfaces, VRF interfaces

ANSIBLE 2.9 RESOURCE MODULESArista EOS● eos_interfaces● eos_l2_interfaces● eos_l3_interfaces● eos_lacp● eos_lldp_global● eos_lldp_interfaces● eos_lacp_interfaces● eos_lag_interfaces● eos_vlans

Cisco IOS XR● iosxr_interfaces● iosxr_l2_interfaces● iosxr_l3_interfaces● iosxr_lacp● iosxr_lldp_global● iosxr_lldp_interfaces● iosxr_lacp_interfaces● iosxr_lag_interfaces● iosxr_vlans

Juniper JunOS● junos_interfaces● junos_l2_interfaces● junos_l3_interfaces● junos_lacp● junos_lldp_global● juos_lldp_interfaces● junos_lacp_interfaces● junos_lag_interfaces● junos_vlans

Cisco IOS● ios_interfaces● ios_l2_interfaces● ios_l3_interfaces● ios_lacp● ios_lldp_global● ios_lldp_interfaces● ios_lacp_interfaces● ios_lag_interfaces● ios_vlans

Cisco NX-OS● nxos_interfaces● nxos_l2_interfaces● nxos_l3_interfaces● nxos_lacp● nxos_lldp_global● nxos_lacp_interfaces● nxos_lag_interfaces● nxos_vlans● nxos_telemetry● nxos_bfd_interfaces

VyOS● vyos_interfaces● vyos_l3_interfaces● vyos_lldp_global● vyos_lldp_interfaces● vyos_lag_interfaces

ANSIBLE 2.9 FACTS ENHANCEMENTSeos_facts & gather_facts● interfaces● l2_interfaces● l3_interfaces● lacp● lldp_global● lldp_interfaces● lacp_interfaces● lag_interfaces● vlans

Iosxr_facts & gather_facts● interfaces● l2_interfaces● l3_interfaces● lacp● lldp_global● lldp_interfaces● lacp_interfaces● lag_interfaces● vlans

junos_facts & gather_facts● interfaces● l2_interfaces● l3_interfaces● lacp● lldp_global● lldp_interfaces● lacp_interfaces● lag_interfaces● vlans

ios_facts & gather_facts● interfaces● l2_interfaces● l3_interfaces● lacp● lldp_global● lldp_interfaces● lacp_interfaces● lag_interfaces● vlans

nxos_facts & gather_facts● interfaces● l2_interfaces● l3_interfaces● lacp● lldp_global● lacp_interfaces● lag_interfaces● vlans● telemetry● bfd_interfaces

vyos_facts & gather_facts● interfaces● l3_interfaces● lldp_global● lldp_interfaces● lag_interfaces

ANSIBLE NETWORK 2.9 FORWARD

Building and enabling high-value network automation as collections content and delivery via Automation hub

Continued full support for the most popular network platforms, extending Certification to partner content

Declarative intent via resource modules:

normalized facts, configurations and

state without sacrifice

Continuing to evolve Ansible as the

de-facto network automation platform

for NetOps

STRENGTH IN NUMBERS● “Deep dive into Ansible Network Resource Modules” (Wed

10am)● Test, use, find issues with resource modules - Ansible 2.9rc1● Build a resource module - Resource module builder● github - Ansible network project board● Documentation and examples● Integration tests● Social media

QUESTIONS