One of the many features CloudVision offers along with Configuration management, image management, Telemetry, and Change Management are the Zero Touch Provisioning (ZTP) and Zero Touch Replacement (ZTR) features. Users can either use the preinstalled DHCP server on the CloudVIsion Portal platform or use any other DHCP server found in Linux or Microsoft Windows.

In this article, we will outline the steps required to get DHCP working on both the Linux and Microsoft platform as well as basic steps to provision a new switch, and replacement. All this can be done without the need for the blue console cable!

By default, every Arista switch (including vEOS) boots up for the first time into ZTP mode. All ports on the switch become layer 3 ports (no switchport) and broadcast for an IP address. A workflow diagram is shown below.

Arista supports two methods platforms for ZTP: an free, open-source, Linux-based ZTP Server (documentation found here) or CloudVision Portal. For this article, we will focus on CloudVision Portal.

Further reading for ZTP Server can be found on eos.arista.com and searching for ZTP for articles related to ZTP. One article is found here.

Linux DHCP Steps

For the full list of options that can be used, check the IANA page for all Options here.

For the full documentation for running DHCP on CentOS, please click here.

Step 1 – Edit the DHCPD.CONF file

CloudVision includes a preinstalled DHCP server by default. It is not configured or enabled by default. In order to set this up, once we’ve installed the CloudVision server (for this step, please consult your local SE or view the CloudVision Config Guide here) in the bash shell of the server, edit the /etc/dhcpd/dhcpd.conf file.

[root@cvp ~]# cat /etc/dhcp/dhcpd.conf

#

# DHCP Server Configuration file.

#   see /usr/share/doc/dhcp*/dhcpd.conf.example

#   see dhcpd.conf(5) man page

#

By default, there is no configuration. We will configure a scope for the ZTP’ed switches, as well as Option 67 pointing the switch to the CloudVision server. This concept is very similar to booting up a wireless access point, or IP Phone.

You can use any file editor to edit this file, in this example, we will use vi.

[root@cvp ~]# vi /etc/dhcp/dhcpd.conf

subnet 192.168.0.0 netmask 255.255.255.0 {

 range 192.168.0.200 192.168.0.240;

 option bootfile-name “http://192.168.0.5/ztp/bootstrap”;

}

This will specify the subnet, range of IPs, as well as option 67 specifying the IP address of the CVP server as well as the bootstrap filename. Use ESC > wq! to save and close the file.

Step 2 – Option 3 Router and DHCP Relay Config

Furthermore, if this subnet is not in the same broadcast domain as the CVP server’s IP, you will need to add Option 3 Router to add in a default gateway for the DHCP subnet.

[root@cvp ~]# vi /etc/dhcp/dhcpd.conf

subnet 192.168.0.0 netmask 255.255.255.0 {

 range 192.168.0.200 192.168.0.240;

 option routers 192.168.0.1;

 option bootfile-name “http://192.168.0.5/ztp/bootstrap”;

}

In addition to this, you will need to add ip address-helper command, which enables DHCP Relay Agents to allow for forwarding of DHCP requests under an interface. See the EOS Config Guide for details.

Command Syntax

ip helper-address ipv4_addr

no ip helper-address [ipv4_addr]

default ip helper-address [ipv4_addr]

 Example

• This command enables DHCP relay on VLAN interface 200 and configure the switch to forward DHCP requests received on this interface to the server at 10.10.41.15.

switch(config)#interface vlan 200

switch(config-if-Vl200)#ip helper-address 10.10.41.15

switch(config-if-Vl200)#show active

interface Vlan200

  ip helper-address 10.10.41.15

switch(config-if-Vl200)#

Step 3 – Enable the DHCP Scope

To enable this scope, you need to start the dhcpd service. On the bash shell type

[root@cvp ~]# service dhcpd start

Redirecting to /bin/systemctl start  dhcpd.service

[root@cvp ~]# service dhcpd status

Redirecting to /bin/systemctl status  dhcpd.service

dhcpd.service – DHCPv4 Server Daemon

  Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled; vendor preset: disabled)

  Active: active (running) since Sat 2017-08-12 18:18:15 UTC; 49min ago

If you need to troubleshoot why the DHCP service did not start, view the logs under /var/log/messages. You can also use tail to view the latest entires or grep for dhcpd.

Finally, use the chkconfig command to ensure the DHCP service runs after the CloudVision server is rebooted.

[root@cvp ~]# chkconfig dhcpd on

Note: Forwarding request to ‘systemctl enable dhcpd.service’.

Step 4 – Optional – Static DHCP Mappings

If desired, users may also perform static MAC to IP mappings use the fixed-address option. An example is shown below.

subnet 192.168.0.0 netmask 255.255.255.0 {

 range 192.168.0.200 192.168.0.240;

 option bootfile-name “http://192.168.0.5/ztp/bootstrap”;

}

host spine1 {

 hardware ethernet 2c:c2:60:56:df:93;

 fixed-address 192.168.0.10;

}

Step 5 – Optional – Multiple DHCP Subnets on CloudVision Server

There may be times where the DHCP scope given may not match the eth0 interface. If you try to start the DHCP service, you will see errors in the /var/log/messages file stating the DHCP couldn’t start due to no device being able to listen on this scope.

In order to workaround this issue, create a dummy scope based on the IP address on CloudVision eth0 interface. For example, if the IP address on eth0 is 10.20.30.170/24, create a scope in this subnet under dhcpd.conf

subnet 10.20.30.0 netmask 255.255.255.0 {

}

Note there is no need to add any parameters. Next, add in the “real” scope. In this example, 192.168.0.0/24.

 subnet 192.168.0.0 netmask 255.255.255.0 {

 range 192.168.0.200 192.168.0.240;

 option bootfile-name “http://192.168.0.5/ztp/bootstrap”;

}

Step 6 – Configure the ZTP switch in CloudVision

Once DHCP is properly configured, the switch will appear in the CloudVision server under the Undefined container. If you have multiple switches that are in ZTP mode, you can check which switch is which by using its MAC address (also found outside of the box of each switch).

On the console of the switch, you will see:

On the CloudVision server, you will see

 The switch is now ready to be provisioned. Right click the switch to move it to another container and right click it again to start pushing configuration to the switch.

 Zero Touch Replacement and CloudVision

 A byproduct of ZTR is ZTP. Having CVP and the DHCP scope configured, and having all the config already applied on the switch on CloudVision, in case the switch needs to get replaced.

 In our example, leaf4 has gone offline (please confirm first if it’s an IP reachability issue, the eAPI has been turned off before replacing a switch).

Step 1 – Initiate ZTR

Instead of having to rebuild the entire config from scratch, use ZTR. Right click leaf4 and select Replace. This will show a list of switches currently in ZTP mode, awaiting configuration.

Click on the ZTP switch and click Replace followed by Save to confirm.

Step 2 – Execute the Pending Task

Once you’ve selected a ZTP switch, a “T” icon is replaced on the down switch and the switch to inherit all configuration will have an R icon. To execute this task, click on the Task pane from the Homepage and execute the task.

 

The console will reflect the config’s being pushed. The switch will reboot with all configs initially from leaf4. The MACs will change showing the ZTP switch being the “new” leaf4 switch.

Configuring Microsoft Windows DHCP Server

For full details on installing Microsoft Windows DHCP server, click here.

Creating a scope in Windows is very user friendly. Microsoft has plenty of documentation for creating a new scope, click here for details.

As with the Linux installation, along with the DHCP scope, we must add in Options to the scope for both Option 3 (if a default gateway is required), and Option 67 to specify the bootfile-name and server. A screenshot is shown below.

Conclusion

We hope that this has been a useful guide for you in setting up ZTP and CloudVision. Please reach out to your local SE should you have any issues.

This post is a post I originally wrote for Arista EOS Central – see the original link here.

William Zambrano

William Zambrano

NYC networkers is run by William Zambrano, a passionate network engineer who has been in the IT industry for eight years who posts up blog articles, YouTube videos, and holds meetup.com events in the NYC area. He lives in Queens, New York and has consulted in various different companies in the NY area. Previously William worked as a Cisco Certified Systems Instructor (CCSI) but now currently works for Arista Networks serving as a Systems Engineer. William can be reached by email at willzambrano@gmail.com

More Posts - Website

Follow Me:
Twitter