Here are the slides from Rick Sherman's PuppetConf 2016 presentation called Why Network Automation Matters, and What You Can Do About It. Watch the videos at https://www.youtube.com/playlist?list=PLV86BgbREluVjwwt-9UL8u2Uy8xnzpIqa

1. Why Network
Automation
Matters
...And what you can do about it.
Rick Sherman
Puppet

2. 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

3. 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

4. Series of Tubes!
Content Credit: Cumulus Networks and bgpmon.net
...or networks are a compound cluster something
4

5. Hand crafted,
artisanal configs
5

6. A tale of two configs - CLI
IOS
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;
}
}
}
}

7. A tale of two configs - CLI
IOS
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;
}
}
}
}

8. Ad-hoc
management
It Sucks
8

9. 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

10. The Puppet world today
10
Cisco
cisco_interface { 'GigabitEthernet2' :
shutdown => true,
description => 'core',
ipv4_address => '192.168.2.3',
ipv4_netmask_length => 24,
}
Cumulus
cumulus_interface { 'swp2':
ipv4 => ['192.168.2.3/24']
speed => 1000
}
Arista
eos_ipinterface { 'Ethernet2':
address => '192.168.2.3/24',
mtu => 1514,
}
Huawei
network_l3_interface{'10GE1/0/2':
ensure => present,
name => '10GE1/0/2',
description => 'core',
enable => 'false',
ipaddress => '192.168.2.3 255.255.255.0',
}

11. 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

12. Screen-scraping
I seriously hate it - let’s not.
12

13. 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

14. A tale of two configs - NETCONF
IOS
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>

15. 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. 16

17. 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";

18. Industry Standards
18
Vendor Agnostic

19. YANG
Transformation
It’s what’s for dinner!
19

20. Dot Format
module: 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

21. 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

22. GUI Tools
22
github.com/CiscoDevNet/yang-explorer

23. So I have to
build XML?
That sounds terrible
23

24. Puppetize with YANG
Gotcha Back
24

25. 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

26. 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.

27. Created Proof of Concept Module
vanilla_ice
Set 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

28. Puppet
Type & Provider
28
Auto-generated!

29. Custom Type & Provider
Type Provider
Describes 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.'
end
end

30. Code Generation
30

31. 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

32. Demo Environment
Using `puppet resource` and `puppet apply`
(Getter) (Setter)
32
Local Machine
Puppet 4.7.0
CSR1000v
IOS-XE 16.03.01
NETCONF

33. 33
Demo

34. 34
Q&A

35. 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