Introduction
There are some customs and practices that experienced network engineers do that may not be obvious and are not in the manuals. I need to let you know about a few of these before we begin. There are at least three ways to configure network equipment.
For my entire career, the command line interface (CLI) has been the main way to do configurations. It is hard to use, obscure, obsolete; pick an adjective with negative connotations! However, every competent engineer can use the CLI. In some ways this keeps this easy. Every experienced administrator has previous configurations they can keep in a text file. Extracting a configuration is a copy-and-paste and so is restoring a configuration. However, automation is difficult and inconsistent; we screen-scrape systems by sending commands to them and parsing text from the responses. This is a truly terrible technique, but one we have honed over twenty years or more. I have some of the most terrible Python scripts…….! I want to give some more detail here, because this sequence of practical work is based on the CLI. When I am working on a network device, it is normally through a terminal. I have an editor like NotePad++ running as well. I type my commands into the editor, make sure I’m happy with them and then paste them to the device. My commands are thus documented and repeatable. There are complex scenarios where a device may have hundreds of lines of configuration. I do them nice and tidily in the editor, correcting as I’m going along, adding comments. At the end of a sequence, my text file is my documentation and my backup; I can cut and paste the configuration into a replacement device if I need to. I recommend you adopt this approach very early on. Beware, there may be many stages of input to a CLI. Some devices/vendors allow you to enter commands, verify or parse them, and allow you to make corrections before you commit them. Familiarize yourself with the workings of a new CLI before you must use it in action!
The graphical user interface (GUI) does exist! It is good for visualization, management and monitoring. It is less good for configuration. Documenting a GUI configuration may require many screenshots and the moment the vendor changes the GUI for something even more gaudy (which requires a non-supported version of Java and an insecure version of Flash), all the previous training, procedures and configurations need to be updated. Very often the GUI is via a specific web browser with Flash, Java and a range of other vulnerable, potentially incompatible pre-requisites. It is not unknown to keep a Jump Server VM (which can never be updated!!!!) specifically for one type of equipment. There may be governance issues……
There are reasons we use a GUI for configuration but on almost all modern equipment, if possible, I will extract the CLI commands which result from my actions at the GUI. I am going to look harshly at any equipment which requires a GUI with Java, Flash or any other non-standard kludge. If something must use a browser, it had better use HTML5.
The future is one where we will have well defined interfaces to interact with equipment, where we can send commands and configurations which are unambiguous, where instrumentation and telemetry have a powerful and easy to use command set. And no doubt I will have retired long before any of that becomes a reality. Progress is patchy and proprietary even with the most advanced equipment available.
I am going to suggest you do some background reading on the italicized terms;
The term Software Defined Networks (SDN) has morphed since it was introduced. To me it still means a separation of data from management and control. It is more commonly now understood to mean programmability in networking. In a CISCO environment, find out what Application Centric Infrastructure (ACI) is.
One of the academic aspirations is of building a network model and then configuring equipment based on that model. Yang models are a hot research topic, as is the NETCONF protocol, however, it can be hard to find equipment which supports it.
The ultimate aspiration is network configuration based on what you want, without you having to know the details. Intent based networking is another major research topic.
The content of these notes are (c) John ORaw 2023.
Last updated