The future of CLI and how Network Engineers will interact with devices is a topic being discussed quite often.

ERRATA: link in tweet is broken, go HERE for the correct page

Andrew Lerner wrote on November 2016:

By 2020, only 30% of network operations teams will use the command line interface (CLI) as their primary interface, down from 85% at YE16.

Sometimes the discussion leads to flame wars between those who love the CLI and those who see only a mix of API amd GUI as tools to interact with the network equipment.

Instead of just criticizing the existing model and demonizing the new one, it would make more sense to understand what are the actual needs of network professionals and try to push $vendors to produce something that actually works. Vote with your wallet.

I put in this post a mix of what I read/heard on various blogs, tweets, podcasts and chats with fellow network engineers.

I don’t attribute to myself any of these ideas, I’m just trying to clarify the topics for my own use. Some topics are simplified because a detailed discussion is out of the scope of this humble post.

CLI today

The CLI we use today is almost the same that was available since the beginning of networking, a bunch of commands sent through a serial/telnet/SSH session.

Every vendor developed its own CLI over the years and the command syntax has been a matter of expensive discussions between legal departments (Huawei , Arista ).

Junior and experienced network engineers feel the need of something better to improve work/life balance and operate network devices more efficiently.

The new CLI model

Vendors have different ideas about how the CLI should and it’s pretty clear there will be many ways to send commands to devices with protocols like NETCONF , RESTCONF , GRPC and others.

For a better understanding of the details good starting points are Ivan's course and PacketPushers podcast .

Assuming CLI will not disappear soon, how can it evolve to be a modern tool?

Today’s CLI runs on the box itself, where the box can be any physical or virtual network appliance.

Almost all the network vendors are developing APIs that are supposed to allow to manage the device, with feature parity with CLI hopefully.

Some vendors are using an approach that seems simply wrong using API to send raw CLI commands:

Another solution is to move the CLI on top of API and make it work on the same data model to manage the device configuration:

The CLI itself runs locally as an application on the box or on a remote management workstation, it makes no difference.

The GUI works at the same level of the CLI, it can be provided by the vendor or any other custom software for network management.

Perhaps this model of CLI is already being applied or developed by some vendors, Juniper’s Junos seems the closest one to this model:

Aruba puts API aside CLI on its new 8400 switch.

CLI on top of API?

What are the advantages of putting a CLI on top of API instead of aside?

It forces the vendor to implement an API that includes all the possible commands and options, not just a subset.

It allows to build custom GUI, CLI and orchestration tools with the same features of the native tools.

It maintains the CLI as a quick and known troubleshooting tool for expert networking engineers in case of necessity. No one wants to write code to collect data for a quick troubleshoot.

Wrap up

You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. Buckminster Fuller

New management tools have a great potential to improve the lives of network engineers but in the end I think we’ll still want a CLI when something goes wrong.