Automating Base Configuration in a Cisco Networking Homelab

Let’s face it: resetting Cisco devices in your homelab to factory defaults is painful. The process of plugging in a console cable, erasing the contents of the NVRAM, reloading the device, then initially configuring the device so that you can remotely access it is bearable for a single device, but most networking homelabs have six devices, sometimes more! Modern Cisco devices solve this issue with dedicated management interfaces that retain their configuration even after a write erase command, but these devices tend to be outside the budget of somebody studying for their CCNA or CCNP. One common solution is a router acting as a terminal server, which uses reverse telnet to remotely console into devices using the console or aux ports; however, the total cost of such a project easily can be hundreds of dollars and can be difficult for somebody new to Cisco devices to configure.

Cisco’s AutoInstall feature provides a convenient automation solution to this issue while minimizing expensive hardware purchases. By configuring a device connected to our homelab to act as a TFTP and DHCP server, we can automatically push an initial configuration to each of our Cisco devices that have been remotely reset to factory settings. This service automatically provides remote access, AAA configuration, and much more to our devices after resetting them!

Requirements

According to Cisco’s Feature Navigator, Cisco introduced AutoInstall in IOS Release 12.1(5)T, which was released in the early 2000s and reached end-of-support in 2013. This means that the vast majority of Cisco devices on the used market should be running 12.1 or higher. As an example, the oldest image available for download from Cisco for the very-popular CISCO1841 router is 12.3(8)YG4, and I have confirmed that Cisco AutoInstall is supported at this version with IP Base licensing.

Another feature we’re going to utilize is TCL, which we will use to write configurations to a file. Support for TCL was introduced in 12.2(33)IRA, which is still old enough that compatibility should not be an issue for the vast majority of networking pods.

If you’re going to be using a Cisco device to serve as your DHCP and TFTP server, you will need to ensure that the device is capable of running at least IOS 12.2(33)SRA or greater. This software is the earliest release where both DHCP pools and TFTP server configuration is supported.

The base configurations that I will be creating are designed to provide remote access to a device by bringing up an interface, assigning an IP address to it, creating a new user with a password, creating a secret password, and requiring users to log into the device when accessed through VTY lines. This configuration works well with the topology below, where every device in the pod is connected via Ethernet to a management switch reachable at 192.168.0.1. In our topology, the management switch (a Catalyst 3560) will be providing management connectivity to all devices in the pod, as well as serving as our DHCP and TFTP server.

Your topology could replace the management switch with a dumb switch and have a host (such as a Raspberry Pi) connected to it, which would serve as your DHCP and TFTP server. The details do not matter – the end goal of this topology is that each device dedicates a single Ethernet interface for a management network, and the rest of the interfaces can be used for practicing configuration as you normally would in a lab. You remotely access all of the devices in your lab via Telnet, and when you finish with your lab and wish to erase your work, you simply reset each device to factory settings via a write erase command and a reload. When the device boots up, it will automatically pull your base configuration from the TFTP server. Your base configuration can contain whatever configuration best suits your needs: The goal of this article is to show you an example of what can be automated in your pod without the need for moving a console cable from device to device.

Testing

I attempted to utilize equipment that likely would be found in a CCNA or CCNP certification homelab wherever possible. However, my testing is not comprehensive; it is entirely possible that you may encounter issues with your equipment due to the multiple different combinations of Cisco hardware and software that are available.

Management Switch

WS-C3560X-24P-L running 15.2(3)E

Router Clients

CISCO1841 running 15.1(4)M12A

C2620XM-1FE running 12.4(25d)

C1861E-SRST-F/K9 running 15.2(4)M3

Switch Client

WS-C3560X-24P-L running 15.2(3)E

If you encounter issues with configuring AutoInstall on your equipment, I highly recommend updating to the latest recommended version of code, if at all possible. If that is not a feasible option, feel free to contact me with your software, hardware, and configurations! I would be more than happy to review your setup and point out any issues I can find.

Procedure

Our first step is going to be configuring our management switch to act as a DHCP server. Again, any switch can be used (whether it be a smart/managed switch or a dumb switch), so long as all devices are plugged into the switch, and the device that serves as your TFTP and DHCP server is plugged into the switch too. The following procedure assumes that you are using a Cisco device to provide TFTP and DHCP services to your networking pod.

First, let’s configure DHCP on our switch by creating a pool named LAB-DHCP, setting the scope of the pool to 192.168.0.0/24, setting our default router to 192.168.0.1, setting the TFTP server IP address option (150) of our DHCP pool to point to 192.168.0.1, and excluding the switch’s own IP (192.168.0.1) from the DHCP pool. Then, we’re going to assign 192.168.0.1/24 to our Vlan 1 interface.

At this point, if you go to another device in your topology and execute ip address dhcp on your interface facing the management switch, you should be able to obtain an IP address in the 192.168.0.0/24 range.

Before we configure our management switch to act as a TFTP server, we need to create the base configuration to be used across all our devices. The reasoning behind this is that in order to configure a device as a TFTP server in Cisco IOS, we need to choose individual files that we wish to be accessed via TFTP. As of right now, we don’t have a file that we can serve via TFTP.

To create our base configuration, we’re going to be using the TCL shell on our management switch to write commands to a file. This option is better than copying a base configuration from one of our devices, as our networking pod may have a mixture of device models, images, and types. A base configuration derived from one of those devices may cause configuration errors on other devices if interface names, image versions, or capabilities are different. When we create our configuration, we’re going to want to make sure we name it network-confg, as AutoInstall requires base configurations to be named either network-confg or cisconet.cfg.

We can access the TCL shell from privileged EXEC mode by typing the tclsh command; you should see your prompt change from Hostname# to Hostname(tcl)#, which indicates a successful transition. From this point forward, you want to tailor your base configuration to your specific needs; as I described above, my base configuration is only going to contain the necessary configuration to establish telnet connection from the management switch using a username, password, and secret of “cisco”. My commands in the TCL shell, as well as my base configuration are shown below – feel free to customize it to fit your environment.

Success! However, we still have room for improvement; in its current shape, AutoInstall will result in all of our pod devices having the same hostname, and IP addresses will be assigned randomly. This will make remote management a bit more difficult, as we’ll need to find out which IP address each of our devices grabbed before being able to telnet into them. Let’s customize our configuration on R1 a little bit more by creating a file named R1-confg on the management switch using TCL:

The naming scheme of this configuration file (along with all of your future, device-specific configuration files) is important. Cisco AutoInstall follows the naming scheme “hostname-confg” or “hostname.cfg”, where hostname is the hostname that you choose to give to your device. Therefore, if you want a device named “AggSw” to install a host-specific configuration automatically, you need to name that configuration file AggSw-confg on your TFTP server.

However, we must first answer an important question: how does our DHCP/TFTP server know which host-specific configuration goes with which device?

The answer is through configuring manual bindings in a DHCP pool for each individual host. In order to do this, we need to find the client identifier for each host. The easiest way to do this is to allow each device to load its base configuration from the management switch (which involves grabbing an IP address from the DHCP server), then use the show ip dhcp binding command to find the client identifier, as shown highlighted below in bold:

Once you’ve found the client-identifier for your device, you can set up a DHCP pool for that specific device. When configuring manual bindings for devices, each device requires its own specific DHCP pool. This is demonstrated below:

Conclusion

We are now able to create a custom configuration for each of the devices in our networking homelab, and we have confirmed that we are able to remotely configure a device, reset it to factory settings when we’re done with our lab for the day, and connect to it remotely once more after the factory-reset process is complete. This is demonstrated below, where I was able to telnet into a Cisco1841 router, factory reset and reload the device, then remotely access it once more after about 2.5 minutes: