The challenges of the CLI

I started my IT career at an ISP help desk back in the early 2000s. I remember watching the network engineers typing in what seemed like cryptic commands into a text terminal. Like magic, the network devices would then bend to their will and behave in the way they intended. In time, I got to learn and embrace these magic commands that I could type into the terminal. As network engineers, these CLI-based commands are like secret codes we share with each other in this world we call network engineering. Manually typing in the command was just something we all had to do to get the job done, no harm, no foul.

However, it was right around the year 2014 when we started to see the industry coming to a consensus about the clear need to move away from manual, human-driven CLIs toward an automatic, computer-centric automation API. Make no mistake, we still need to directly communicate with the device when making network designs, bringing up an initial proof of concept, and deploying the topology for the first time. However, once the network is deployed, the network management requirement is now to consistently make the same changes reliably across all network devices.

These changes need to be error-free, and the engineers need to repeat the steps without being distracted or feeling tired. This requirement sounds like an ideal job for computers and our favorite programming language, Python.

Of course, if the network devices can only be managed with the command line, the main challenge becomes how we can replicate the previous manual interactions between the router and the administrator automatically with a computer program. In the command line, the router will output a series of information and will expect the administrator to enter a series of manual commands based on the engineer’s interpretation of the output. For example, in a Cisco Internetwork Operating System (IOS) device, you have to type in enable to get into a privileged mode, and upon receiving the returned prompt with the # sign, you then type in configure terminal in order to go into the configuration mode. The same process can further be expanded into the interface configuration mode and routing protocol configuration mode. This is in sharp contrast to a computer-driven, programmatic mindset. When the computer wants to accomplish a single task, say, put an IP address on an interface, it wants to structurally give all the information to the router at once, and it would expect a single yes or no answer from the router to indicate the success or failure of the task.

The solution, as implemented by both Pexpect and Paramiko, is to treat the interactive process as a child process and watch over the interaction between the child process and the destination device. Based on the returned value, the parent process will decide the subsequent action, if any.

I am sure we are all anxious to get started on using the Python libraries, but first, we will need to construct our network lab in order to have a network to test our code against. We will begin by looking at different ways we can build our network labs.