Why Network Automation Matters...And what you can do about it.

Rick ShermanPuppet

A Quick Introduction

● Professional Services○ Identity and Policy Management○ Workflow systems

● Security Business Unit○ Cloud Architect

● Junos Manageability○ PyEZ (Python micro-framework)○ Ansible Modules○ Onbox scripting○ NetDev Evangelism

● Sr. Engineer - Ecosystem○ Network Automation Czar

■ SME○ Release Engineering

■ Puppet Agent

2

What makes networks difficult?

● Network devices have historically been closed systems with vendor specific CLIs

● Configurations are hundreds if not thousands of lines (per system)

● Configuration != Desired state

● Vendors slow to introduce features, sometimes 18-24 months - upgrade cycle is just as long

● Network Engineers typically do not have a Sys Admin or programming background

● Networks serve multiple applications

3

Series of Tubes!

Content Credit: Cumulus Networks and bgpmon.net

...or networks are a compound cluster something

4

Hand crafted, artisanal configs

5

A tale of two configs - CLIIOS

6

Junos

interface GigabitEthernet2

description core

ip address 192.168.2.3 255.255.255.0

shutdown

!

interfaces {

ge-0/0/2 {

description core;

disable;

unit 0 {

family inet {

address 192.168.2.3/24;

}

}

}

}

A tale of two configs - CLIIOS

7

Junos

interface GigabitEthernet2

description core

ip address 192.168.2.3 255.255.255.0

shutdown

!

interfaces {

ge-0/0/2 {

description core;

disable;

unit 0 {

family inet {

address 192.168.2.3/24;

}

}

}

}

Ad-hoc managementIt Sucks

8

The Puppet world today

9

● Platforms are supported via Puppet Agent○ Cisco

■ NXOS■ IOS-XR

○ Arista■ EOS

○ Huawei■ CloudEngine 12800

○ Cumulus■ CumulusLinux 2/3x x86

● Variety of Puppet Modules○ Vendor specific types○ Puppet “NetDev” types

● Multiple methods of interacting with the device

○ Screen Scraping○ API Bindings○ NETCONF

What you can do right now

The Puppet world today

10

Ciscocisco_interface { 'GigabitEthernet2' :

shutdown => true,

description => 'core',

ipv4_address => '192.168.2.3',

ipv4_netmask_length => 24,

}

Cumuluscumulus_interface { 'swp2':

ipv4 => ['192.168.2.3/24']

speed => 1000

}

Aristaeos_ipinterface { 'Ethernet2':

address => '192.168.2.3/24',

mtu => 1514,

}

Huaweinetwork_l3_interface{'10GE1/0/2':

ensure => present,

name => '10GE1/0/2',

description => 'core',

enable => 'false',

ipaddress => '192.168.2.3 255.255.255.0',

}

That’s great, but...

● Building Puppet Agents require serious investment

● Implementations are fragmented

● Yes, there is some screen scraping in there

● Puppet netdev_stdlib not industry recognized

11

Screen-scrapingI seriously hate it - let’s not.

12

Enter the NETCONF

● XML based encoding○ Vendor specific data models

● Configuration RPCs○ get-config, edit-config, copy-config,

delete-config, lock, unlock● Operational state RPCs

○ Generally map to CLI “show” commands● Transport: SSH, HTTPS, TLS, BEEP

13

IETF network management standard

A tale of two configs - NETCONFIOS

14

Junos

<interface>

<GigabitEthernet>

<name>2</name>

<description>core</description>

<ip>

<address>

<primary>

<address>192.168.2.3</address>

<mask>255.255.255.0</mask>

</primary>

</address>

</ip>

<shutdown/>

</interface>

<interface>

<name>ge-0/0/2</name>

<description>core</description>

<disable/>

<unit>

<name>0</name>

<family>

<inet>

<address>

<name>192.168.2.3/24</name>

</address>

</inet>

</family>

</unit>

</interface>

That’s great, but...

● Implementation is up to the vendor

○ Same problem - different format

● How in the hell do I know what data to send the device?

● Remember, NetEng’s often not programmers

○ How will I interpret this data?○ How will I create and modify it?

15

16

YANG

● Human-readable representation of model● Hierarchical data node representation

○ Can combine multiple models● Built-in data types

○ String, Boolean, Custom● Constraints

○ What is mandatory?● Backwards compatibility rules● Extensible● Deviations

* Data is still vendor (or group) specific

17

IETF Data Modeling Language for NETCONF

container interfaces {

list interface { key "name"; description "The list of configured interfaces...";

leaf name { type string; description "The name of the interface..."; }

leaf enabled { type boolean; default "true";

Industry Standards

18

Vendor Agnostic

YANG TransformationIt’s what’s for dinner!

19

Dot Formatmodule: ietf-interfaces

+--rw interfaces

| +--rw interface* [name]

| +--rw name string

| +--rw description? string

| +--rw type identityref

| +--rw enabled? boolean

| +--rw link-up-down-trap-enable? enumeration {if-mib}?

| +--rw ip:ipv4!

| | +--rw ip:enabled? boolean

| | +--rw ip:forwarding? boolean

| | +--rw ip:mtu? uint16

| | +--rw ip:address* [ip]

| | | +--rw ip:ip inet:ipv4-address-no-zone

20

github.com/mbj4668/pyang

XML

<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">

<interface><name/><description/><type/><link-up-down-trap-enable/>

<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">

<mtu/>

<address>

<ip/>

<prefix-length/>

<netmask/>

</address>

</ipv4>

</interface>

</interfaces>

21

github.com/mbj4668/pyang

GUI Tools

22

github.com/CiscoDevNet/yang-explorer

So I have to build XML?That sounds terrible

23

Puppetize with YANGGotcha Back

24

Project Goals● Provide “Agentless” network device management

○ Also be able to use same code with an Agent

● Use standard protocols○ NETCONF○ gRPC*

● Provide established Puppet experience○ Puppet DSL○ Idempotency / noop○ Puppet Graph

● Auto-generate as much as possible○ Puppet Types○ Puppet Providers○ Tests

25

Leverage existing tools

pyang

Python tool for validating and converting YANG data models

Built plugin for generating Puppet code from YANG models

26

Do not re-invent the wheel - contribute to the community

net-netconf (kkirsche fork)

Ruby library for NETCONF

Added client side support for NETCONF 1.1 (does not validate chunk sizes)

Fixed various issues in framework

In discussions with community maintainer for long term maintenance direction.

Created Proof of Concept Modulevanilla_iceSet of experimental Puppet Types and Providers (varying levels of completion)

● Artifacts created by code generation + human interaction

● Predominantly NETCONF based○ Early gRPC investigation

● IOS-XE○ ietf-interfaces○ ietf-ospf○ ietf-nvo○ cisco-interfaces (ned)

● IOS-XR○ cisco-ifmgr

27

PuppetType & Provider

28

Auto-generated!

Custom Type & Provider

Type ProviderDescribes the “What”

Lists all of the attributes for a resource

Implements the “How”

self.instances (Getter)

What is currently set on the device

flush (Setter)

Enforce the configuration on the device

29

Puppet::Type.newtype(:xe_ietf_interfaces) do ensurable apply_to_device

newparam(:name) do desc 'The name of the interface' isnamevar end

newproperty(:description) do desc 'A description of the interface' end

newproperty(:ipv4_address_ip) do desc 'The IPv4 address on the interface.' endend

Code Generation

30

Demo Goals

● Create / modify / delete loopback interfaces via ietf-interfaces model

● Modify OSPF via ietf-ospf model

● noop + idempotency

● Show code generation ○ Type○ self.instances (resources)○ Flush (writing to device)

What we’re going to show

31

Demo EnvironmentUsing `puppet resource` and `puppet apply`

(Getter) (Setter)

32

Local Machine

Puppet 4.7.0

CSR1000v

IOS-XE 16.03.01

NETCONF

33

Demo

34

Q&A

TL;DR Recap

Problem: Vendor CLI’s, Ad-Hoc Management

Symptoms: Spending all our time as CLI jockeys

Solution: Puppet resources from industry models

Benefit: Puppet DSL, graph, idempotent, noop

Differentiation: Code Generated, Agentless

35