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

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/blame wars between those who love CLI and those who see only API in the future of network management.

Instead of simply criticizing the existing model demonizing the new one, it makes sense to understand what are the real 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 as a detailed discussion is out of scope.

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 telnet or SSH sessions.

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 in a more efficiently.

The new CLI model

The idea about how the new CLI should be is different among vendors, IETF groups and network engineers but it’s pretty clear there will be different ways to send commands to devices with protocols like NETCONF , RESTCONF , GRPC and more.

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.

Beside the CLI vendors are developing API that are supposed to allow to manage the device with all the same features.

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

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

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

At the same level of the CLI works the GUI provided by the vendor or any other custom software for network management or abstraction.

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, 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.

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 models today 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.