SlideShare a Scribd company logo
1
Devops Day Amsterdam
2015
Network Automation Tools
Chef and Zero Touch Provisioning/Replacement (ZTP/ZTR)
2
Agenda
 Introduction (EB)
 ZTP/ZTR (MA)
- Boot three bare metal switches
 Chef (EB)
- Orchestrate two switches with baseline interface configuration
- Enforce configuration statements
- Reject certain config lines
3
Speaker Bios
Michael Amstelveen, Consulting Engineer, Arista Networks
Arista is the fastest growing switch vendor in the 10/40/100 GeE space, our platform is
based on Linux and a fully open operating system which is becoming very popular.
I’m passionate about computer networking, automation and innovation.
Mail: ma@arista.com
Edwin Beekman, Engineer, Schuberg Philis bv
Working at Schuberg Philis bv, a company focused on Critical Application
Outsourcing.
My main focus is everything related to networking, from routing/switching/security to
SDN, virtualization, programming and automation.
BsC in Telematics and CISSP Certified.
Mail: ebeekman@schubergphilis.com and Twitter: FirebladeEd
4
Automatic Network Provisioning
5
Automatic Network Provisioning
System ID <--> CONFIG
CONFIG
CONFIG CONFIG CONFIG CONFIG
ZTP Server
6
Automatic Network Provisioning
BGP LLDP
VXLAN
IP
BGP
IP_9
IP_1
IP_n
EOS
4.13.6
Splunk
Actions
Definition
Definition
Definition
Definition
Definition
System ID <--> Definition
EOS
4.12.5
API
ZTP Server
7
Automatic Network Provisioning
BGP
IP = $IP_ADDR
IP
BGP
LLDP/sysID <--> Definition
…
VXLAN
IP1, IP2, …
allocate
ZTP Server
8
ZTP Process Overview
DHCP Request
Arista EOS ZTP Server DHCP Server
DHCP Response (MGMT IP, Name Server, Boot File)
HTTP Get Bootstrap
Syslog Server XMPP Server
Run
Bootstrap
HTTP Get Config
HTTP Post Nodes
HTTP Get Definition
HTTP Get Action
HTTP Get Resource
Start Logging
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Load
Definition
Run
Action
. . .
Reboot – if startup-config
Collect Node
Details via eAPI
9
Definitions File
 Specifies tasks to be performed
during the bootstrap of a node.
 The definition file can be either:
- manually created or
- auto-generated by the server based
on match in neighbordb file
 Definition file contains…
- Actions, with…
- Attributes…
- which can call config templates
- and in turn, utilise resource pools to
assign values
actions:
-
action: install_image
always_execute: true
attributes:
url: files/images/vEOS.swi
version: 4.13.5F
name: "validate image”
-
action: add_config
attributes:
url: files/templates/ma1.template
variables:
ipaddress: allocate('mgmt_subnet')
name: "configure ma1”
-
action: add_config
attributes:
url: files/templates/system.template
variables:
hostname: allocate('tor_hostnames')
name: "configure global system”
10
Available Actions
Action Description
add_config Adds a block of configuration to the final startup-config
copy_file Copies a file from the server to the destination node
install_cli_plugin Installs a new EOS CLI plugin and configures rc.eos
install_extension Installs a new EOS extension
install_image Validates and installs a specific version of EOS
replace_config Sends an entire startup-config to the node (overrides (overrides add_config)
send_email Sends an email to a set of recipients routed through a relay host. Can include file
attachments
run_bash_script Run bash script during bootstrap.
run_cli_commands Run CLI commands during bootstrap.
11
Examples of Templates & Resource
Pools
 Templates  Resource Pools
#login.template
#::::::::::::::
username admin priv 15 secret admin
#ma1.template
#::::::::::::::
interface Management1
ip address $ipaddress
no shutdown
#mgmt_subnet
#::::::::::::::
192.168.100.210/24: null
192.168.100.211/24: null
192.168.100.212/24: null
192.168.100.213/24: null
192.168.100.214/24: null
#tor_hostnames
#::::::::::::::
veos-dc1-pod1-tor1: null
veos-dc1-pod1-tor2: null
veos-dc1-pod1-tor3: null
veos-dc1-pod1-tor4: null
veos-dc1-pod1-tor5: null
#hostname.template
#::::::::::::::
hostname $hostname
12
ZTP Resources
 Documentation
http://ztpserver.readthedocs.org/en/latest/overview.html
 ZTPServer Download
https://github.com/arista-eosplus/ztpserver
 Packer based ZTPS Virtual Machine
https://github.com/arista-eosplus/packer-ztpserver
13
Topology
BGP AS
65535
BGP AS
65001
eth1.131
eth2
.132
eth1
.133
s1
l2l1
s2
eth1
.196
eth1.130
eth2
.198
eth2
.199
eth2
.197
l4l3
eth2
.201eth4
.202
eth2
.1203
eth3
.200
eth2.35
eth4.136
eth2.137
eth3.134
172.16.0/24
X1_Chef
14
POD IP addressing
15
Lab 1: Preparation
 www.ravello.com
 A virtual Arista VEOS switch and Opscode Chef environment has been prepared in the
Cloud.
 Login to the website, select the application and canvas to see the environment.
 Verify the Public IP address for host X1. This host will function as the admin box for the
virtual environment.
 Bash: ssh [public_IP] user devops/Dev0ps2015
 Chef-server: https://[public_IP] user admin/arista
 Connect to the Spine and Leaf switches via ssh s1, ssh l1 etc
16
Lab 0: Get all VMs up and running
 Activity Objective
 In this activity you will meet these objectives:
- Verify all host and switch VM’s in the virtual LAB
- Have management connectivity between all lab host
- Install a chef-client on a leaf switch
 Required Resources
 These are the resources and equipment required to complete this
activity:
- A Ravello lab environment
 Command List
- Ping
- Ifconfig
- Show
17
XMPP client on vEOS
The following configuration is required on the Arista switches. The XMPP client is part
of EOS and works out of the box. Encryption and AAA is also supported
username all privilege 15 role network-admin nopassword
!
management xmpp
no shutdown
server 192.168.0.4
username s2@192.168.0.4 password 7 070E33455D1D18
switch-group all@conference.192.168.0.4
switch-group spines@conference.192.168.0.4
domain 192.168.0.4
Verify your XMPP connection with the XMPP server
s2#show xmpp status
XMPP Server: 192.168.0.4 port 5222
Client username: s2@192.168.0.4
Default domain: 192.168.0.4
Default privilege level for received commands: 1
Connection status: connected
18
XMPP client on vEOS
How to verify your XMPP neighbors
s1#show xmpp neighbors
Neighbor State Time Since Last Change
------------------------------ --------------- -------------------------
l1@192.168.0.4 present 14:19:09 ago
l2@192.168.0.4 present 14:19:11 ago
l3@192.168.0.4 present 14:28:33 ago
l4@192.168.0.4 present 14:28:32 ago
s2@192.168.0.4 present 14:19:07 ago
Neighbor Status Message
------------------------------ ----------------------------------------
l1@192.168.0.4 Arista Networks vEOS
l2@192.168.0.4 Arista Networks vEOS
l3@192.168.0.4 Arista Networks vEOS
l4@192.168.0.4 Arista Networks vEOS
s2@192.168.0.4 Arista Networks vEOS
19
XMPP client on vEOS
How to find IP 172.16.2.68 in a large underlay network using XMPP
s2#xmpp session all@conference.192.168.0.4
xmpp-all#
xmpp-all#show arp | grep 172.16.2.68
response from: l2@192.168.0.4
--------------------------------------------------
172.16.2.68 0 2cc2.6029.9828 Ethernet5
Show software version:
xmpp-all#show version | grep Software
response from: l1@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
response from: l2@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
response from: l3@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
20
XMPP client on vEOS
Show software version for a specific group, i.e. for all leafs (TOR) switches
l4#xmpp send leafs@conference.192.168.0.4 command show version | grep Software
message from user: l1@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
message from user: l2@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
message from user: l3@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
message from user: l4@192.168.0.4
--------------------------------------------------
Software image version: 4.14.7M
21
Task 0: Get your virtual lab prepared
for this workshop
Activity Procedure
Complete these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
22
Chef controlled network
Chef is an automation platform that transforms infrastructure into
code.
Chef relies on reusable definitions known as cookbooks and
recipes that are written using the Ruby programming language.
Cookbooks and recipes automate common infrastructure tasks.
Their definitions describe what your infrastructure consists of and
how each part of your infrastructure should be deployed,
configured and managed. Chef applies those definitions to servers
to produce an automated infrastructure.
23
Chef controlled network
For coding the infrastructure we have chosen for Chef and rolled
out our own private Chef infrastructure. We can automate an awful
lot: roll-out new Hypervisors, applications, configurations, services.
But coding the underlay is still something that is in development.
Cisco has an integration with OnePK/Chef/Puppet or with an expect
script. But what really intrigues me are the implementations that
makes directly use of the network Operating System on the device
itself. Integrations which allows for off-the-shelve installation of the
Chef-client, with or without an additional plugin.
Arista switches can easily be integrated in the Chef deployment and
allows for easy central configuration.
But actual any (Linux) network device can be used for automation.
24
Chef controlled network
server
client
Recipes
Roles
Nodes
Attribbutes
Templates
25
Task 1: Chef-client on VEOS
Login with SSH to the X1 admin box.
Verify the Chef client nodes, you should see something like: s1, s2, l1, l2, l3
cd ~/chef-repo
knife node list
Install the chef-client on the switch.
copy scp:admin@192.168.0.4/home/admin/switch/chef-11.18.6-1.el6.i686.rpm extension:
extension chef-11.18.6-1.el6.i686.rpm
copy installed-extensions boot-extensions
bash
sudo su –
mkdir /persist/local/chef
scp admin@192.168.0.4:/home/admin/switch/validator.pem /persist/local/chef
scp admin@192.168.0.4:/home/admin/switch/client.rb /persist/local/chef
26
Task 1: Chef-client on VEOS
Run the chef-client on the SPINE switch, this will register the switch to the Chef server
chef-client –c /persist/local/chef/client.rb
On the Chef server:
knife node edit s1
{
"name": "s1",
"chef_environment": "spine-leaf",
"normal": {
"tags": [
]
},
"run_list": [
"role[spine-leaf]"
]
}
Run the client again on the switch
chef-client –c /persist/local/chef/client.rb
27
Task 1: Chef-client on VEOS
Run the chef-client on the LEAF switch, this will register the switch to the Chef server
chef-client –c /persist/local/chef/client.rb
On the Chef server, add extra node properties:
knife node edit l2
{
"name": "l2",
"chef_environment": "spine-leaf",
"normal": {
"pod": {
"asno": 65001,
"inet6_prefix": "fd00:411:0112:02",
"inet_prefix": "172.16.2",
"name": "l2",
"number": 1
},
"provisioning": {
"boot_option": "EOS-4.14.6M",
"deployed": true
},
"tags": [
]
},
"run_list": [
"role[leaf-spine]"
]
}
Run the client again on the switch
chef-client –c /persist/local/chef/client.rb
28
Task 2: The Chef cookbook setup
The cookbooks reside on the admin box X1 in /home/admin/chef-repo
Roles/
A role is a way to define certain patterns and processes that exist across nodes in an organization as belonging
to a single job function
Environment/
An environment is a way to map an organization’s real-life workflow to what can be configured and managed
when using Chef server.
Cookbooks/
A cookbook is the fundamental unit of configuration and policy distribution. A cookbook defines a scenario and
contains everything that is required to support that scenario:
Recipes that specify the resources to use and the order in which they are to be applied
Attribute values
File distributions
Templates
Extensions to Chef, such as libraries, definitions, and custom resources
29
Task 2: The Chef cookbook setup
 Environment
 There is one environment configuration, the spine-leaf.json. It contains all the
technical attributes (bgp/ospf/mlag/routes/etc) for the environment.
 Roles
 Currently two roles are available, for the spine and the leaf. Each containing a
different run-list (cookbook).
 "run_list": [
 "recipe[coreswitch_role]“
30
Task 2: The Chef cookbook setup
 Cookbooks
 Arista_api
 Contains the actual code to login and send commands to the the VEOS switch
 Arista_switch
 Contains the code to translate the environment attributes to VEOS switch
configuration and send it to the Arista_api cookbook. Every part
(mlag/interface/acls/etc) has it’s own Ruby code file.
 Coreswitch_role and Podswitch_role
 Controls which configuration is needed and possible default attributes (for
example banners or acls).
31
Task 2: The Chef cookbook setup
Updates on cookbooks to adjust/update or add new features
After changing: knife cookbook upload [cookbook_name]
Leaf or Pod switches can be configured from the environment file.
After changing: knife environment from file spine-leaf.json
Verify the VEOS switch by checking the Chef run or run it manually on the switch
Sudo chef-client –c /persist/local/chef/client.rb
32
SDN initiatives in the Netherlands
Early last year we started a new SDN MeetUp group in Amsterdam.
We held four meetings which where well received.
If you are interested make sure to check and join the group:
http://www.meetup.com/Amsterdam-SDN-Group/

More Related Content

Chef arista devops days a'dam 2015

  • 1. 1 Devops Day Amsterdam 2015 Network Automation Tools Chef and Zero Touch Provisioning/Replacement (ZTP/ZTR)
  • 2. 2 Agenda  Introduction (EB)  ZTP/ZTR (MA) - Boot three bare metal switches  Chef (EB) - Orchestrate two switches with baseline interface configuration - Enforce configuration statements - Reject certain config lines
  • 3. 3 Speaker Bios Michael Amstelveen, Consulting Engineer, Arista Networks Arista is the fastest growing switch vendor in the 10/40/100 GeE space, our platform is based on Linux and a fully open operating system which is becoming very popular. I’m passionate about computer networking, automation and innovation. Mail: ma@arista.com Edwin Beekman, Engineer, Schuberg Philis bv Working at Schuberg Philis bv, a company focused on Critical Application Outsourcing. My main focus is everything related to networking, from routing/switching/security to SDN, virtualization, programming and automation. BsC in Telematics and CISSP Certified. Mail: ebeekman@schubergphilis.com and Twitter: FirebladeEd
  • 5. 5 Automatic Network Provisioning System ID <--> CONFIG CONFIG CONFIG CONFIG CONFIG CONFIG ZTP Server
  • 6. 6 Automatic Network Provisioning BGP LLDP VXLAN IP BGP IP_9 IP_1 IP_n EOS 4.13.6 Splunk Actions Definition Definition Definition Definition Definition System ID <--> Definition EOS 4.12.5 API ZTP Server
  • 7. 7 Automatic Network Provisioning BGP IP = $IP_ADDR IP BGP LLDP/sysID <--> Definition … VXLAN IP1, IP2, … allocate ZTP Server
  • 8. 8 ZTP Process Overview DHCP Request Arista EOS ZTP Server DHCP Server DHCP Response (MGMT IP, Name Server, Boot File) HTTP Get Bootstrap Syslog Server XMPP Server Run Bootstrap HTTP Get Config HTTP Post Nodes HTTP Get Definition HTTP Get Action HTTP Get Resource Start Logging . . . . . . . . . . . . . . . . . . . . . . . . Load Definition Run Action . . . Reboot – if startup-config Collect Node Details via eAPI
  • 9. 9 Definitions File  Specifies tasks to be performed during the bootstrap of a node.  The definition file can be either: - manually created or - auto-generated by the server based on match in neighbordb file  Definition file contains… - Actions, with… - Attributes… - which can call config templates - and in turn, utilise resource pools to assign values actions: - action: install_image always_execute: true attributes: url: files/images/vEOS.swi version: 4.13.5F name: "validate image” - action: add_config attributes: url: files/templates/ma1.template variables: ipaddress: allocate('mgmt_subnet') name: "configure ma1” - action: add_config attributes: url: files/templates/system.template variables: hostname: allocate('tor_hostnames') name: "configure global system”
  • 10. 10 Available Actions Action Description add_config Adds a block of configuration to the final startup-config copy_file Copies a file from the server to the destination node install_cli_plugin Installs a new EOS CLI plugin and configures rc.eos install_extension Installs a new EOS extension install_image Validates and installs a specific version of EOS replace_config Sends an entire startup-config to the node (overrides (overrides add_config) send_email Sends an email to a set of recipients routed through a relay host. Can include file attachments run_bash_script Run bash script during bootstrap. run_cli_commands Run CLI commands during bootstrap.
  • 11. 11 Examples of Templates & Resource Pools  Templates  Resource Pools #login.template #:::::::::::::: username admin priv 15 secret admin #ma1.template #:::::::::::::: interface Management1 ip address $ipaddress no shutdown #mgmt_subnet #:::::::::::::: 192.168.100.210/24: null 192.168.100.211/24: null 192.168.100.212/24: null 192.168.100.213/24: null 192.168.100.214/24: null #tor_hostnames #:::::::::::::: veos-dc1-pod1-tor1: null veos-dc1-pod1-tor2: null veos-dc1-pod1-tor3: null veos-dc1-pod1-tor4: null veos-dc1-pod1-tor5: null #hostname.template #:::::::::::::: hostname $hostname
  • 12. 12 ZTP Resources  Documentation http://ztpserver.readthedocs.org/en/latest/overview.html  ZTPServer Download https://github.com/arista-eosplus/ztpserver  Packer based ZTPS Virtual Machine https://github.com/arista-eosplus/packer-ztpserver
  • 15. 15 Lab 1: Preparation  www.ravello.com  A virtual Arista VEOS switch and Opscode Chef environment has been prepared in the Cloud.  Login to the website, select the application and canvas to see the environment.  Verify the Public IP address for host X1. This host will function as the admin box for the virtual environment.  Bash: ssh [public_IP] user devops/Dev0ps2015  Chef-server: https://[public_IP] user admin/arista  Connect to the Spine and Leaf switches via ssh s1, ssh l1 etc
  • 16. 16 Lab 0: Get all VMs up and running  Activity Objective  In this activity you will meet these objectives: - Verify all host and switch VM’s in the virtual LAB - Have management connectivity between all lab host - Install a chef-client on a leaf switch  Required Resources  These are the resources and equipment required to complete this activity: - A Ravello lab environment  Command List - Ping - Ifconfig - Show
  • 17. 17 XMPP client on vEOS The following configuration is required on the Arista switches. The XMPP client is part of EOS and works out of the box. Encryption and AAA is also supported username all privilege 15 role network-admin nopassword ! management xmpp no shutdown server 192.168.0.4 username s2@192.168.0.4 password 7 070E33455D1D18 switch-group all@conference.192.168.0.4 switch-group spines@conference.192.168.0.4 domain 192.168.0.4 Verify your XMPP connection with the XMPP server s2#show xmpp status XMPP Server: 192.168.0.4 port 5222 Client username: s2@192.168.0.4 Default domain: 192.168.0.4 Default privilege level for received commands: 1 Connection status: connected
  • 18. 18 XMPP client on vEOS How to verify your XMPP neighbors s1#show xmpp neighbors Neighbor State Time Since Last Change ------------------------------ --------------- ------------------------- l1@192.168.0.4 present 14:19:09 ago l2@192.168.0.4 present 14:19:11 ago l3@192.168.0.4 present 14:28:33 ago l4@192.168.0.4 present 14:28:32 ago s2@192.168.0.4 present 14:19:07 ago Neighbor Status Message ------------------------------ ---------------------------------------- l1@192.168.0.4 Arista Networks vEOS l2@192.168.0.4 Arista Networks vEOS l3@192.168.0.4 Arista Networks vEOS l4@192.168.0.4 Arista Networks vEOS s2@192.168.0.4 Arista Networks vEOS
  • 19. 19 XMPP client on vEOS How to find IP 172.16.2.68 in a large underlay network using XMPP s2#xmpp session all@conference.192.168.0.4 xmpp-all# xmpp-all#show arp | grep 172.16.2.68 response from: l2@192.168.0.4 -------------------------------------------------- 172.16.2.68 0 2cc2.6029.9828 Ethernet5 Show software version: xmpp-all#show version | grep Software response from: l1@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M response from: l2@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M response from: l3@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M
  • 20. 20 XMPP client on vEOS Show software version for a specific group, i.e. for all leafs (TOR) switches l4#xmpp send leafs@conference.192.168.0.4 command show version | grep Software message from user: l1@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M message from user: l2@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M message from user: l3@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M message from user: l4@192.168.0.4 -------------------------------------------------- Software image version: 4.14.7M
  • 21. 21 Task 0: Get your virtual lab prepared for this workshop Activity Procedure Complete these steps: Step 1 Step 2 Step 3 Step 4 Step 5
  • 22. 22 Chef controlled network Chef is an automation platform that transforms infrastructure into code. Chef relies on reusable definitions known as cookbooks and recipes that are written using the Ruby programming language. Cookbooks and recipes automate common infrastructure tasks. Their definitions describe what your infrastructure consists of and how each part of your infrastructure should be deployed, configured and managed. Chef applies those definitions to servers to produce an automated infrastructure.
  • 23. 23 Chef controlled network For coding the infrastructure we have chosen for Chef and rolled out our own private Chef infrastructure. We can automate an awful lot: roll-out new Hypervisors, applications, configurations, services. But coding the underlay is still something that is in development. Cisco has an integration with OnePK/Chef/Puppet or with an expect script. But what really intrigues me are the implementations that makes directly use of the network Operating System on the device itself. Integrations which allows for off-the-shelve installation of the Chef-client, with or without an additional plugin. Arista switches can easily be integrated in the Chef deployment and allows for easy central configuration. But actual any (Linux) network device can be used for automation.
  • 25. 25 Task 1: Chef-client on VEOS Login with SSH to the X1 admin box. Verify the Chef client nodes, you should see something like: s1, s2, l1, l2, l3 cd ~/chef-repo knife node list Install the chef-client on the switch. copy scp:admin@192.168.0.4/home/admin/switch/chef-11.18.6-1.el6.i686.rpm extension: extension chef-11.18.6-1.el6.i686.rpm copy installed-extensions boot-extensions bash sudo su – mkdir /persist/local/chef scp admin@192.168.0.4:/home/admin/switch/validator.pem /persist/local/chef scp admin@192.168.0.4:/home/admin/switch/client.rb /persist/local/chef
  • 26. 26 Task 1: Chef-client on VEOS Run the chef-client on the SPINE switch, this will register the switch to the Chef server chef-client –c /persist/local/chef/client.rb On the Chef server: knife node edit s1 { "name": "s1", "chef_environment": "spine-leaf", "normal": { "tags": [ ] }, "run_list": [ "role[spine-leaf]" ] } Run the client again on the switch chef-client –c /persist/local/chef/client.rb
  • 27. 27 Task 1: Chef-client on VEOS Run the chef-client on the LEAF switch, this will register the switch to the Chef server chef-client –c /persist/local/chef/client.rb On the Chef server, add extra node properties: knife node edit l2 { "name": "l2", "chef_environment": "spine-leaf", "normal": { "pod": { "asno": 65001, "inet6_prefix": "fd00:411:0112:02", "inet_prefix": "172.16.2", "name": "l2", "number": 1 }, "provisioning": { "boot_option": "EOS-4.14.6M", "deployed": true }, "tags": [ ] }, "run_list": [ "role[leaf-spine]" ] } Run the client again on the switch chef-client –c /persist/local/chef/client.rb
  • 28. 28 Task 2: The Chef cookbook setup The cookbooks reside on the admin box X1 in /home/admin/chef-repo Roles/ A role is a way to define certain patterns and processes that exist across nodes in an organization as belonging to a single job function Environment/ An environment is a way to map an organization’s real-life workflow to what can be configured and managed when using Chef server. Cookbooks/ A cookbook is the fundamental unit of configuration and policy distribution. A cookbook defines a scenario and contains everything that is required to support that scenario: Recipes that specify the resources to use and the order in which they are to be applied Attribute values File distributions Templates Extensions to Chef, such as libraries, definitions, and custom resources
  • 29. 29 Task 2: The Chef cookbook setup  Environment  There is one environment configuration, the spine-leaf.json. It contains all the technical attributes (bgp/ospf/mlag/routes/etc) for the environment.  Roles  Currently two roles are available, for the spine and the leaf. Each containing a different run-list (cookbook).  "run_list": [  "recipe[coreswitch_role]“
  • 30. 30 Task 2: The Chef cookbook setup  Cookbooks  Arista_api  Contains the actual code to login and send commands to the the VEOS switch  Arista_switch  Contains the code to translate the environment attributes to VEOS switch configuration and send it to the Arista_api cookbook. Every part (mlag/interface/acls/etc) has it’s own Ruby code file.  Coreswitch_role and Podswitch_role  Controls which configuration is needed and possible default attributes (for example banners or acls).
  • 31. 31 Task 2: The Chef cookbook setup Updates on cookbooks to adjust/update or add new features After changing: knife cookbook upload [cookbook_name] Leaf or Pod switches can be configured from the environment file. After changing: knife environment from file spine-leaf.json Verify the VEOS switch by checking the Chef run or run it manually on the switch Sudo chef-client –c /persist/local/chef/client.rb
  • 32. 32 SDN initiatives in the Netherlands Early last year we started a new SDN MeetUp group in Amsterdam. We held four meetings which where well received. If you are interested make sure to check and join the group: http://www.meetup.com/Amsterdam-SDN-Group/

Editor's Notes

  1. So let’s start here, let’s say we have a simple leaf/spine design. In order to provision my network I’lI go and connect my console to each and every switch and do all the work manualy I believe it’s clear to everybody why this is not a good idea, some of us still do this for one reason or the other As you scale your infrastructure the cost will grow exponentially. You need more people. Your downtime will be longer because it’s harder to troubleshoot So what easy way we have to do better than this
  2. One very easy way to do a lot better is to move the configuration from the devices them selves to a provisioning server So we can use open standards and protocols to achive this. You can creat a DHCP server to create a bi-derectional connection between the switches and the server So whenever the switch boot-up it will do a DHCP recquest and get an IP an the location for the server from the DHCP server. So once we have this bi-directional communication between the server and the switch we are able to do a couple of things We can send the configuration from the server to the switch, so we don’t need any manual intervention any more We can now also push the configuration from the switch to the server, if we’ve made any configuration changes So this way we can backup all configuration and find out who made any configuration changes and when Another advance of building this very simple provisioning server, is that it allow us to do ZTR (zero toucn replacement) What if one of my nodes breaks, how do I replace it In this setup it’s very easy,we aready have the latest configuration of the switch on the server. This is great, and it’s better than doing everything manualy. However it still has some drawback: Single configuration file per switch, and in this case we have a system ID per config. I cannot upgrade or downgrade any of my newly installed switches I cannot install eny extention or application So lets see how we can solve that:
  3. So the next step is pretty simple as well. First of all let’s take the configuration and break this into little template. And I believe a lot of people already do this right So for example my LLDP configuration would be the same for every switch, so what’s the point in copy and pasting this 10x Instead I define it once and I test it once and then re-use it in my network Before I move on I need to introduct a couple of new acronyms So we can break the configuration from one file into multiple actions and each action can install a certain template to the devices itself Once we have this concept we can take multiple templates or actions and map them together in what we call a definition file And now we can map the SYS-ID to a defination file, this gives u a lot more flexibility and have less manual intervention JSON can be considered a subset of YAML And on top of this we have the ability to add more actions So far I’ve talked about one action which add a template to the switch But we can have another action with add more complicated logic like upgrading the software of the switch or add an extention to the switch Or before we finish the configuation let’s first check if the field engineers connected the cables to the right ports and act on this. We can do this by adding some custom actions which can enforse all of the cabling checks. Or if you’ve done a ZTR let’s see if we can ping the default gateway and if it doesn’t work what should I do So this is a bit more complex than previous examples so I think its worth talking about how we can monitor the proccess right. How we can make sure that evertthing went fine and what is going to happen if one of the actios would faill And again for this we can leverage opensource tools and protocols. . And the way we do it at Arista is we use XMPP and remote syslog. What this means is that if our customers deploys something like that they use a ZTP server and then the filed engineers have an XMPP app on there phoe and can join a particular XMPP group. Now they get real time notifications if they connect a switch to the network and they possible get tips and tricks if something went wrong. i.e. cable in a wrong port. So what’s the problem here and how can we improve You still need to make the mapping between the system-ID to a definition. In a modern Datacenter there are a lot of devices which has the same functionality based on there location We can have multiple pods which have the same role The conly difference is the hostname and the MGTM IP for example. So let’s see if we can take this one step further?
  4. And I think we can do that by defining classes of switches based on there LLDP location in the network. So define a class of switches and map this to a definition file This means that whenever we are adding a new node we don’t have to make any new configuration changes on the server and we don’t need to touch the switch Just because all the switches in that particalur clas follew the same role. Okay so you might think what to do with the host names, one way to do it is to automatic generate them. We can automatic generate them based on the connection to the management network I,e, How about the MGMT IP or the IP subnets between the spine and leaf. Well in this case you don’t need a specific IP for a particular switch. But you need an IP address from subnet A or B. So instead of defining a template for each induvidual switch we can now define a generic template and we configure what we call a pool of resources. Let create a subnet resource pooland than we say to the server. You know what if this switch comes up allocate any IP address from that pool and mark it as allocated So we started in our first example with doing everything manualy and now we are in a stage where we have to define what we are building but once we’ve done this everything is automatic with very little human intervention. So let’s see how ZTR works. Let’s go to the previous example where there was a mapping between sysID and a definition, Now if you replace a switch the switch will send its LLDP neighbor informatio to the server and ask the server if he sees somebody who looks either excactly like me or very close