Networking / Beginners

---

Command Line Interfaces

The easiest management tool for a manufacturer of network equipment to write is a command line interface (CLI), sometimes known as a craft interface (CI). A CLI is a set of text-based commands issued by the operator at a terminal. The commands have specific (sometimes complex and esoteric) syntaxes specified by the manufacturer and are very specific to the hardware being managed. This means that an operator running a network of diverse nodes from different manufacturers must learn the command language for each node-no small task. Fortunately, devices from one manufacturer tend to use the same commands where there is an overlap of function, and the same syntaxes for all commands. Because devices that perform the same functions need roughly the same configuration, and because vendors recognize the difficulties of managing networks built from hardware from many different vendors, there is a tendency for CLIs to look quite similar, with convergence on the command syntaxes used by the incumbent manufacturers. This has obvious benefits, but can also be frustratingly confusing when the syntaxes are so similar as to make the differences hard to remember.

In its simplest form, the CLI requires that the operator be present at a terminal directly attached to the device being managed. This is not viable in large networks in which the routers and switches are distributed over a large geographic area and are often installed in inaccessible places. Remote console access can be achieved running a product such as a terminal server that the user connects to using Telnet and that is physically connected to the device as though it were a local terminal.

Alternatively, if the device supports TCP and runs a Telnet server, the operator can log in using Telnet and run the CLI. In either case, the user can manage the device remotely and must visit the location in which the equipment is installed only in the event of a catastrophic failure.

It is a considerable inconvenience to an operator to have to reconfigure a device each time it is restarted (that is, power cycled), so most devices store their configuration data in some form. It is not really important whether this information is on a local hard disk, in flash memory, or in a file held on a remote server and accessed through some means such as the Trivial File Transfer Protocol (TFTP). The effect is the same: The device is able to recover its configuration by reading a file and commence operation without any further management intervention. Such configuration files may be stored in any format, and could be simple binary files that are easily read into memory and have meaning only to the software that is using them, but a more sensible approach is to record the configuration commands necessary to recreate the required state and to replay the file as though it were being typed by the operator. Command-based configuration files have the advantages that they can be inspected and understood by an operator, they can be edited so that new configuration is automatically picked up on reboot, and they are more easily proofed against software version upgrades.

It should be noted that the one great benefit of a CLI is that it is easily able to give a very fine level of control over a device and allows a user to examine every last detail of the device's operation. Debug commands are rarely available in any other form.