AUTOMATION – Part 2 Zero Touch

AUTOMATION – Part 2 Zero Touch

Following on from my first post on automation of network device configurations I think the next easy win for network engineers in automation is a zero touch deployment of network devices. The zero touch deployment feature has been around for many years but from my experience I have never seen it been fully utilized on the network up until recently. Each networking vendor has their own flavor, Cisco has POAP (Power On Auto Provisioning) for their Nexus platofrms & Smart Install for their Catalyst & ISR platforms, Arista has ZTP (Zero Touch Provisioning), Cumulus also has ZTP, Juniper also has ZTP and Dell Networking has BMP (Bear Metal Provisioning).

I will not be going into each vendors zero touch feature within this post as they all provide the same function and utilize the same feature, DHCP in some form or another. For this post I will be working with the Dell Networking BMP feature as at the time of this writing I am working mostly with the Dell Networking products than the other vendors I have mentioned above. But the purpose of this post is to show how utilizing the zero touch feature along with the configuration I built in the first post with Ansible can save you time when it comes to doing a standard stand up of a network device in your network.

The lab network I will be testing this in is pretty simple and straight forward. Two ToR switches (Dell Networking S4048-ON), a single Core switch (Dell Networking S6000-ON) and a Linux CentOS server running Ansible, DHCP and TFTP. Not shown in the below diagram is the MGMT network that the MGMT interfaces for the network switches are connect into, the red lines are representing the MGMT network.


The DHCP configuration file which I will be using for BMP is straightforward. For this example I will be calling on the MGMT interface MAC address to be the identifier for the switches within the DHCP config file. I could of identified the switches through their Server Tag, Serial Number, Vendor ID or the device Model but to keep this post simple using the MAC address is the easiest option.

default-lease-time 86400;

# BMP Options declaration
option boot-filename code 67 = text;
option config-file code 209 = text;


# Assignments
subnet netmask {
 # Common for everyone
 option routers;
 option domain-name "";

 host ToR_SW1 {
 hardware ethernet 14:18:77:03:fa:02; 
 option config-file "tftp://";
 option boot-filename "tftp://";
 host ToR_SW2 {
 hardware ethernet 14:18:77:07:1f:00;
 option config-file "tftp://";
 option boot-filename "tftp://";

From the above dhcpd.conf file I have identified the switches using their hardware ethernet addresses. The DHCP options which we will need to be able to bring our switches online with the standard configuration I built through Ansible and our standard software image are the config-file option 67 and the boot-filename option 209 respectively.

Now I have my dhcpd.conf file configured correctly to tell each switch where they can download both their configuration file and OS from lets move over to the switches themselves. All Dell Networking switches running FTOS come with BMP enable straight out of the box (factor default configuration). This can also be said for the other vendors devices who I mentioned at the beginning of this post who also support the zero touch feature straight out of the box.

Below is showing the console output from the Dell Networking switch that has just been powered on;

This device is configured to enter Bare Metal Provisioning (BMP). 
BMP will now attempt to download an image, configuration file or boot script using DHCP. 
To cancel BMP, apply the startup config, and continue with the standard manual interactive mode,
enter "stop bmp" from the console at any time. 
To disable BMP for the next reload, configure the switch with "boot-type normal-reload" from reload-type sub mode. 
Nov 4 09:26:17: %STKUNIT0-M:CP %IFMGR-5-OSTATE_UP: Changed interface state to up: Ma 1/1
Nov 4 09:26:19: %STKUNIT0-M:CP %CRYPTO-5-FIPS_SELF_TEST_PASSED: [bmp] FIPS crypto module self-test passed
Nov 4 09:26:20: %STKUNIT0-M:CP %BMP-5-PROCESS_STARTED: Starting BMP process

You can see the switch has come up with BMP enabled. This means the switch is actively seeking a DHCP server to provide the information it needs to come online. Below is the output from the DHCP server who is receiving the request from the switch running in BMP mode;

OPTION: 61 ( 7) Client-identifier 01:14:18:77:03:fa:02
OPTION: 60 ( 83) Vendor class identifier TY=DELLNTW-S4048-ON ;HW=2.0 ;SN=HADL146S20125;ST=C1QRX42 ;OS=9.9(0.0) ;MD=BMP;

 TIME: 2016-11-04 14:24:39.560
 IP: (0:50:56:85:dc:ce) > (0:1:e8:8b:e2:39)
 HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 1
 XID: 461f4188
 SECS: 0
 FLAGS: 7f80
CHADDR: 14:18:77:03:fa:02:00:00:00:00:00:00:00:00:00:00
OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER)
OPTION: 54 ( 4) Server identifier
OPTION: 51 ( 4) IP address leasetime 86400 (24h)
OPTION: 1 ( 4) Subnet mask
OPTION: 3 ( 4) Routers
OPTION: 15 ( 10) Domainname
OPTION: 28 ( 4) Broadcast address
OPTION: 67 ( 56) Bootfile name tftp://
OPTION: 209 ( 45) Configfile name tftp://

From the above you can see all the options that the DHCP server is offering to the switch. The options we are most concerned about for this example are Option 67 & Option 209 which we can see have been offered to the switch.

Now if we look at the switch which we want to come onto the network as ToR_SW1 we will see the switch has accepted the DHCP offer and has download the OS;

Nov 4 10:00:14: %STKUNIT0-M:CP %BMP-2-BMP_DOWNLOAD_START: The Dell Networking OS image download has started.
Erasing Sseries Primary Image, please wait
...........................Writing ................
System image upgrade completed successfully.

The switch will reboot itself once the image has been downloaded and installed correctly. Next the switch will download its configuration file;

Nov 4 10:10:38: %STKUNIT0-M:CP %BMP-2-BMP_DOWNLOAD_START: The config file download has started.
Nov 4 10:10:44: %STKUNIT0-M:CP %BMP-5-CFG_APPLY: The downloaded config from dhcp server is being applied.
Nov 4 10:10:45: %STKUNIT0-M:CP %SYS-5-CONFIG_LOAD: Loading configuration file
Nov 4 10:10:46: %STKUNIT0-M:CP %BMP-5-BMP_POST_SCRIPT_NOT_PRESENT: The Post-Config Script is not present.
Nov 4 10:10:47: %STKUNIT0-M:CP %SEC-5-USER_ACC_CREATION_SUCCESS: User account "lord" created or modified by default from svceAgent successfully
Nov 4 10:10:47: %STKUNIT0-M:CP %SPANMGR-5-STP_ROOT_CHANGE: RSTP root changed. My Bridge ID: 32768:1418.7703.fa00 Old Root: 32768:0000.0000.0000 New Root: 32768:1418.7703.fa00
Nov 4 10:10:47: %STKUNIT0-M:CP %SPANMGR-5-STP_ROOT_CHANGE: RSTP root changed. My Bridge ID: 8192:1418.7703.fa00 Old Root: 32768:1418.7703.fa00 New Root: 8192:1418.7703.fa00
Nov 4 10:10:47: %STKUNIT0-M:CP %IFMGR-5-ASTATE_UP: Changed interface Admin state to up: Ma 1/1
Nov 4 10:10:47: %STKUNIT0-M:CP %SNMP-6-SNMP_WARM_START: Agent Initialized - SNMP WARM_START.
Nov 4 10:10:47: %STKUNIT0-M:CP %CLOCK-6-TIME CHANGE: Timezone configuration changed from "UTC 0 hrs 0 mins" to "GMT 0 hrs 0 mins"
Nov 4 10:10:49: %STKUNIT0-M:CP %IFMGR-5-OSTATE_UP: Changed interface state to up: Ma 1/1
Nov 4 10:10:49: %STKUNIT0-M:CP %BMP-5-PROCESS_COMPLETED: BMP process is complete. The configuration/script must be saved in order to use it after subsequent reloads

It is worth mentioning with BMP if the OS you have offered the switch within the DHCP offer is the same as the one which is currently active on the switch then BMP will skip over this phase of the BMP process. For this example my switches were running FTOS 9.9 out of the box and I had them move to FTOS as part of the BMP process.

I will now look over the switch configuration and confirm that everything looks correct while also checking to see if the switch is also running the correct OS version.

ToR_SW1#sh run
Current Configuration ...
! Version 9.10(0.1P13)
! Last configuration change at Fri Nov 4 10:14:20 2016 by default
boot system stack-unit 0 primary system: A:
boot system stack-unit 0 secondary system: B:
hostname ToR_SW1
protocol lldp 
 advertise management-tlv system-capabilities system-description system-name 
 advertise interface-port-desc 
redundancy auto-synchronize full
enable secret 5 fb08b1ca9738d4b3370428875157de34
username lord password 7 9e1b710921f3b205 privilege 15 
protocol spanning-tree rstp 
 no disable 
 hello-time 1 
 forward-delay 4 
 bridge-priority 8192 
stack-unit 0 provision S4048-ON
interface TenGigabitEthernet 1/1
 no ip address
---- interface config removed ----
interface fortyGigE 1/49
 no ip address
---- interface config removed ----
interface ManagementEthernet 0/0
 ip address
 no shutdown
interface Vlan 1
ip access-list standard SNMP
 remark 1 SNMP Standard
management route 
ip domain-name 
ip name-server 
ip name-server 
logging source-interface ManagementEthernet
banner motd ^C

snmp-server community upintheether rw SNMP
snmp-server location DUB,DC1,R1R1
tacacs-server key 7 b47738f37895aee9ef1c0cdd59a4301b 
tacacs-server host
tacacs-server host
aaa authentication enable default tacacs+ enable
aaa authentication enable tacuser tacacs+ enable
aaa authentication login localmethod local
aaa authentication login tacuser tacacs+ local
clock timezone GMT 0 
line console 0
 password 7 9e1b710921f3b205 
line vty 0
 password 7 9e1b710921f3b205 
 login authentication tacuser
 exec-timeout 120 0
 logging synchronous level 2 limit 20
---- line vty config removed ----
 boot-type normal-reload
 config-scr-download enable

As you can see from the above configuration taken directly from the switch, some lines have be removed to keep it clean for this post, this is the exact same configuration I built with Ansible in the first post.

ToR_SW1#sh boot system stack-unit all

Current system image information in the system:

Type               Boot Type                  A                                 B
stack-unit 1       FLASH BOOT                 9.10(0.1P13)[boot]                 9.9(0.0)

Again from the output above we can see the switch has booted into the correct OS which we specified in the DHCP option.

The BMP process will also be used to bring online ToR_SW2 using the same process which has been outline above. In fact both switches were powered on together and ran through the BMP process simultaneously which meant both switches became production ready together.

In this post I kept it simple to how the zero touch feature can save you time and a lot of effort. You can add to this process by adding pre and post check scripts which allow for greater reliability that the installation has been completed successfully, one check you can add in is cable verification by checking to see the correct LLDP or CDP neighbors on the correct ports.

In my example I kept the network simple and brought up two switches using the Dell Networking zero touch method. You can add any number of switches to this process to be brought up online at the same time using the vendor of your choice zero touch methods. This is another easy win and keeping automation simple in your network for starting off.

Comments are closed.