Why Network Automation Matters, and What You Can Do About It

Network automation presents a series of unique challenges for vendors and customers alike. In this session we will discuss the similarities and differences of network versus traditional systems administration. There will be real world examples of the complexity and scale of network configurations with an emphasis of separating the "how" from the "what". I also intend to demonstrate how Puppet is accelerating the depth of network automation by bridging the power of the Puppet language with YANG network data models.

Transcript

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