When a Cisco switch or router first connects to the network without configuration, it can be convenient to use the AutoInstall feature. Through this, the device can load its configuration from a TFTP server. AutoInstall needs DHCP (or BOOTP), DNS and TFTP services to run but none of them are resource hogs, so we can easily use Raspberry Pi equipped with a dnsmasq package that has all of these services for this purpose.

In this article, we’ll look at the basic configuration of this AutoInstall, along with using Raspberry Pi as a terminal server.

I don’t want to talk too much about Raspberry Pi as we can find a lot of useful information about its features and usage examples elsewhere on the web. What’s important to us at this point is just the installation of the device so we can use the Raspbian Linux distribution on it. I recommend watching this video to be familiarized with the basics of Raspberry Pi: https://www.youtube.com/watch?v=U7Dj7R8bu4k. Prior to starting the actual labs, we will assume that Raspbian has been successfully installed on the Raspberry Pi (which we will now refer to as RPi).

CCNA Training – Resources (Intense)

Before we dive into the features of AutoInstall, let’s talk about another use case of RPi, namely, as a terminal server. A terminal server can be used to establish console connections to many Cisco devices from one central point remotely, using Telnet. You can read more about this concept here: http://www.cisco.com/c/en/us/support/docs/dial-access/asynchronous-connections/5466-comm-server.html.

To achieve this we need several serial ports on the server, but this port type is not too common nowadays so we have to use USB ports instead, with USB-to-Serial adapters. As RPi has only two USB ports, we need a USB hub also and it’s recommended to use a self-powered one.

On the software side, we need a program that transforms data arriving from the Telnet connection on Ethernet to data that’s useable for serial communication and vice versa. This software is called ser2net (Serial to Network), which can be installed with apt-get install ser2net. After the installation we need to look at the configuration file /etc/ser2net.conf. It has very good explanations in the comments, but let’s look at the most important settings.

Firstly, we can define a banner which displays useful information when connecting to a port. The default settings are fine. The next lines are for defining the connection parameters. Each line consists of several fields separated by colons. The first field is the port number to which we need to connect by Telnet. For example, if we define 2000 here, then we need to issue a telnet ip_address_of_rpi 2000 command, and through this we can reach the port that is given in the form of /dev/devicename later in the fourth field.

In our case, devicename will be ttyUSB0, ttyUSB1 and so on (for RS-232 serial ports these names will be ttyS0, ttyS1 and so on). The settings for the serial communication, such as baud rate, data bits, stop bits, etc., are correct so we don’t need to modify them. If we want, we can change the value in the 3rd field: it’s the timeout in seconds, which sets the time of inactivity on a port. If we want to disable it, such as if we don’t want to reconnect after every 600 seconds of inactivity, we can enter 0 here. Save the file and restart ser2net by issuing service ser2net restart command.

Before we connect the console cables, we can check if RPi recognizes the USB-to-serial adapters correctly through the dmesg command. It should display lines similar to this:

[ 810.119662] pl2303 1-1.2.3:1.0: pl2303 converter detected
[ 810.125992] usb 1-1.2.3: pl2303 converter now attached to ttyUSB0

From now on it’ll be easy to reach the console of our physical devices: just telnet to the IP address of RPi and the given port as stated before and we’ll see the banner, then by pressing Enter we can use the console connection. One more thing: if we want to Telnet from the RPi itself, we need to install the telnet package first. My equipment looks like this before I attach it to the router with a crossover cable (I use only one USB-to-serial adapter in this case):

Let’s proceed to the AutoInstall experiments! In our lab we’ll use real devices because we cannot easily simulate a device without startup configuration in GNS3, and of course, AutoInstall only works if the router doesn’t have one.

The lab topology is very simple: I use a C1751 type router, but almost any device will work. We’ll configure this router through the Fa0/0 interface using DHCP for LAN interfaces. AutoInstall works on HDLC and Frame Relay serial interfaces as well. The Raspberry Pi is the ideal server for these kinds of services; moreover, we’ll use dnsmasq for this lab which needs very few hardware resources and is rather easy to configure.

First we need to connect the RPi to the internet and get the dnsmasq package by issuing the apt-get install dnsmasq command. After the package is installed, set the IP address of the RPi to a fixed value, e.g. This can be achieved by issuing the ifconfig eth0 up command.

To configure the installed package, look at the configuration file at /etc/default/dnsmasq. The most important thing here is that we need to ensure that the dnsmasq service starts at boot, so check if the line containing ENABLED=1 exists and is active.

Now we can configure the service through the /etc/dnsmasq file. It’s always a good idea to make a backup of the original file before editing it. For the very basic AutoInstall service we need TFTP and DHCP services to be properly configured. Modify the default settings accordingly:


Most of the settings are self-explanatory. We defined our own domain, then stated the DHCP range from to with a class C netmask and 12 hours of lease time. In order for Cisco devices to find TFTP servers more easily, we defined the DHCP option 150, which points to the IP address of the RPi. Without this the routers will try to find the TFTP server using broadcast messages to the address.

We then need to enable the TFTP service from the /var/tftpd base directory which we created previously. This will contain the configuration files for the Cisco devices. Finally we made the DHCP server authoritative, as there’ll be no other servers on the lab network, and made it log its processes. Save the changes and restart the server by issuing the service dnsmasq restart command.

Now we need to prepare the configuration files to download to the Cisco devices. The AutoInstall process is rather flexible (see the flowchart included in the first document among the links at the end) and uses several files to do its job. The first file it tries to download from the TFTP server, after the device obtained its IP address by DHCP, is called the network configuration file, under the default name of network-confg. If, for some reason, we need to restrict the filename to DOS format, we can use the cisconet.cfg filename as well, but it’s not recommended because it is checked only if network-confg< is not found, therefore the configuration process needs more time.

The main purpose of the network configuration file is to provide mapping between the IP address and the hostname of the device. If we don’t put such information into it, we can still use it for some global settings which we need to set up on every device. For example we can set up a common enable password or configure VTY lines for Telnet connections.

If we don’t want to provide customized configuration files for every router, then there’s another file which the device tries to download optionally, the default configuration file named router-confg (or router.cfg according to DOS naming rules). We can put configuration commands into this as well, but later the administrator has to log in and finish the configuration specific to the device. If neither of these configuration files exist on the server, AutoInstall fails.

If we want to deploy a more customized configuration based on the IP address and the hostname, we need to put these mappings into the network-confg file. This can be achieved the easiest way with the ip host commands. For example, I want my router to have the hostname of R1, and using this information, I want to download later the specific configuration file for this under the name of r1-confg (AutoInstall uses the hostname as the prefix for this filename). In order to do this I’ll put the following line into the network-confg file:

ip host R1

Previously we needed to discover the IP address assigned to this router. We can gather this information from the log file of the DHCP server, which can be found in /var/log/daemon.log or from the router’s console. Then we’ll put some specific configuration into the file r1-confg (note the lowercase filename!), for example:

hostname R1
username admin password ciscoR1
line vty 0 15
login local

Note the end keyword at the end of the file: without this the router may not understand the configuration. Now we need to connect the Ethernet cable to the router and switch it on. We can see on the console that when IOS is loaded, the AutoInstall process first assigns an IP address for the router by DHCP, then loads the network configuration file, and then based on the mapping found in it, loads the specific r1-confg file:

Loading network-confg from (via Fastethernet0/0): !
[OK – 63 bytes]
Configuration mapped ip address to R1
Loading r1-confg from (via FastEthernet0/0): !
[OK – 121 bytes]

…output omitted….

*Mar 12 11:24:26.667: AUTOINSTALL: FastEthernet0/0 is assigned
*Mar 12 11:24:26.667: AUTOINSTALL: Obtain tftp server address (opt 150)
*Mar 12 11:24:26.667: AUTOINSTALL: Obtain default router (opt 3)
*Mar 12 11:24:36.415: %SYS-5-CONFIG_I: Configured from tftp:// by console
*Mar 12 11:24:56.015: %SYS-5-CONFIG_I: Configured from tftp:// by console

Alternatively, if we don’t want to use the ip host commands, we can use a DNS server to map the addresses to hostnames. Though dnsmasq can be configured flexibly, for our purposes its basic features should be enough. It uses the traditional /etc/hosts file by default, which contains the IP address-hostname pairs, so we don’t need to make separate zone files such as for the BIND name server for example. Simply put a line into the hosts file like this: r1.testing.rpi r1

To test the DNS server, we can use at least three programs: nslookup, host and dig. I will use nslookup here (the localhost parameter is needed to set the local server as the DNS server to use):

nslookup r1.testing.rpi localhost

The result is the name and the address of this host. Now we can delete the ip host line from the network-confg file, reload the router and watch the process. The difference is that we’ll see a line like this after loading the network configuration file:

Domain server mapped address to r1.testing.rpi

So far so good. One thing can go wrong: although DHCP tries to assign the same IP address to hosts, it’s not guaranteed every time the router gets this IP address. We should use DHCP reservation based on the MAC address of the router interface. Configure dnsmasq to static IP assignment as follows: open the /etc/dnsmasq.conf file, and put the following into it:


The MAC address of the Fa0/0 interface can be displayed with the following command: show interfaces fa0/0 | include bia. Note that the format required by dnsmasq is different from the Cisco format. Don’t forget to modify the /etc/hosts file accordingly with the new address.

Now save the file, restart dnsmasq service and reload the router again, then we can see that it gets the new address and the process continues as before. If we want to observe the process under the hood, we can use this command on the RPi:

tail –f /var/log/daemon.log

This makes the tail program continuously watch the end of the log file and when something happens, we can immediately see that. Because we switched on the detailed DHCP logging in the beginning, we’ll see really thorough information.

I hope that these examples can be good starting points towards building networks in which AutoInstall can help to setup new devices. Moreover, we can use Raspberry Pi as a very cheap, but very useful device along with our Cisco devices.

Useful links:

AutoInstall procedure in detail:

ser2net on SourceForge:

dnsmasq homepage: