Cisco Just Killed The CLI


Gallons of virtual ink have been committed to virtual paper in the last few days with regards to Cisco’s lawsuit against Arista Networks.  Some of it is speculating on the posturing by both companies.  Other writers talk about the old market vs. the new market.  Still others look at SDN as a driver.

I didn’t just want to talk about the lawsuit.  Given that Arista has marketed EOS as a “better IOS than IOS” for a while now, I figured Cisco finally decided to bite back.  They are fiercely protective of IOS and they have to be because of the way the trademark laws in the US work.  If you don’t go after people that infringe you lose your standing to do so and invite others to do it as well.  Is Cisco’s timing suspect? One does have to wonder.  Is this about knocking out a competitor? It’s tough to say.  But one thing is sure to me.  Cisco has effectively killed the command line interface (CLI).

“Industry Standards”

EOS is certainly IOS-like.  While it does introduce some unique features (see the NFD3 video here), the command syntax is very much IOS.  That is purposeful.  There are two broad categories of CLIs in the market:

  • IOS-like – EOS, HP Procurve, Brocade, FTOS, etc
  • Not IOS-like – Junos, FortiOS, D-Link OS, etc

What’s funny is that the IOS-like interfaces have always been marketed as such.  Sure, there’s the famous “industry standard” CLI comment, followed by a wink and a nudge.  Everyone knows what OS is being discussed.  It is a plus point for both sides.

The non-Cisco vendors can sell to networking teams by saying that their CLI won’t change.  Everything will be just as easy to configure with just a few minor syntax changes.  Almost like speaking a different dialect of a language.  Cisco gains because more and more engineers become familiar with the IOS syntax.  Down the line, those engineers may choose to buy Cisco based on familiarity with the product.

If you don’t believe that being IOS-like is a strong selling point, take a look PIX and Airespace.  The old PIX OS was transformed into something that looked a lot more like traditional IOS.  In ASA 8.2 they even changed the NAT code to look like IOS.  With Airespace it took a little longer to transform the alien CLI into something IOS-like.  They even lost functionality in doing so, simply to give networking teams an interface that is more friendly to them.  Cisco wants all their devices to run a CLI that is IOS-like.  Junos fans are probably snickering right now.

In calling out Arista for infringing on the “generic command line interface” in patent #7,047,526, Cisco has effectively said that they will start going after companies that copy the IOS interface too well.  This leaves companies in a bit of conundrum.  How can you continue to produce an OS with an “industry standard” CLI and hope that you don’t become popular enough to get noticed by Cisco?  Granted, it seems that all network switching vendors are #2 in the market somehow.  But at what point does being a big enough #2 get the legal hammer brought to bear?  Do you have to be snarky in marketing messages? Attack the 800-pound gorilla enough that you anger them?  Or do you just have to have a wildly successful quarter?

Laid To REST

Instead, what will happen is a tough choice.  Either continue to produce the same CLI year and year and hope that you don’t get noticed or overhaul the whole system.  Those that choose not to play Russian Roulette with the legal system have a further choice to make.  Should we create a new, non-infringing CLI from the ground up? Or scrap the whole idea of a CLI moving forward?  Both of those second choices are going to involve a lot of pain and effort.  One of them has a future.

Rewriting the CLI is a dead-end road.  By the time you’ve finished your Herculean task you’ll find the market has moved on to bigger and better things.  The SDN revolution is about making complex networks easier to program and manage.  Is that going to be accomplished via yet another syntax?  Or will it happen because of REST APIs and programing interfaces?  Given an equal amount of time and effort on both sides, the smart networking company will focus their efforts on scrapping the CLI and building programmability into their devices.  Sure, the 1.0 release is going to sting a little.  It’s going to require a controller and some rough interface conventions.  But building the seeds of a programmable system now means it will be growing while other CLIs are withering on the vine.

It won’t be easy.  It won’t be fun.  And it’s a risk to alienate your existing customer base.  But if your options are to get sued or spend all your effort on a project that will eventually go the way of the dodo your options don’t look all that appealing anyway.  If you’re going to have to go through the upheaval of rewriting something from the ground up, why not choose to do it with an eye to the future?

Tom’s Take

Cisco and Arista won’t be finished for a while.  There will probably be a settlement or a licensing agreement or some kind of capitulation on both sides in a few years time.  But by that point, the fallout from the legal action will have finally finished off the CLI for good.  There’s no sense in gambling that you won’t be the next target of a process server.  The solution will involve innovative thinking, blood, sweat, and tears on the part of your entire development team.  But in the end you’ll have a modern system that works with the new wave of the network.  If nothing else, you can stop relying on the “industry standard” ploy when selling your interface and start telling your customers that you are setting the new standard.


10 thoughts on “Cisco Just Killed The CLI

  1. Pingback: Cisco Just Killed The CLI - Tech Field Day

  2. I fully support your desire for more and better APIs, the lack of which is a real source of frustration for me right now. I don’t agree that should or could mean the end of the CLI as evidenced by the fact that OpenStack and ODL (amongst others) both have quite extensive ones.

    Sure, in the long term this ‘might’ happen but its way too early and customers need to move at a pace suitable for their business and the technical abilities of the staff they employ. An API isn’t really much more than an abstracted CLI, called remotely.

    I rejoice that Cisco have made this move; their’s is a poor ‘industry standard’ (as I’ve blogged about before) that has held back progress, innovation and improvement. I don’t think it’s actually such a mammoth task to rewrite a CLI or even write one from scratch. Hopefully it’ll also be an opportunity for vendors to insert some fresh thinking and new ideas into a tool that will remain invaluable for many years to come. Parallel running of old and new shouldn’t be an issue, allowing the screen scrapers and scripters time to adjust.

    One final interesting point to note is that Arista’s eAPI is probably one of the best APIs out there right now. This is one company that is well ahead of the industry and very open to the future; Cisco’s actions will only accelerate that for Arista and others and quite possibly speed the pace of change to Cisco’s detriment.

    • Changing the CLI is no big deal if OPEX = 0. If that assumption was valid none IOS-like would have never occured. “Parallel running of old and new shouldn’t be an issue”, by the by have you done it?

      • Hey Fred, even copying an existing structure and syntax costs money. A vendor that perhaps spends a little more to do something new, useful and most importantly better is one to be applauded.

        Yes, I’ve done this when F5’s TMOS changed from the bigpipe to tmsh command sets. It (and I) dual ran with TMOS v10 giving plenty of time to migrate before the old bigpipe was removed in v11.

  3. Pingback: Cumulus Networks Could Be The New Microsoft | The Networking Nerd

  4. Pingback: When, not what, defines today’s networking career | AdatoSystems

  5. Pingback: Cisco vs. Arista: Shades of Gray | The Networking Nerd

  6. This isn’t how you read a patent. It is the claims, not the description, which matter. The claims give plenty of scope for implementation of IOS-like command languages.

    If the patent did read fully upon the CLI then there are questions as to who holds that I.P. A great deal of the original IOS code was not written by cisco-employed staff, it was licensed to cisco by Stanford as part of a settlement after Stanford accused cisco of theft (Stanford was particularly concerned about this issue after the workstation design of the Stanford University Network became the first products of SUN microsystems). So it’s not clear that cisco can even assert a patent claim to the IOS command line: the ownership of that invention may be Stanford’s, cisco may merely have a license to use the invention.

    Then there is the question of prior art. The CLI is a close clone of Digital Equipment Corporation’s DECserver, an ethernet/serial terminal server. DEC is now part of HP. You see echos of this in IOS regarding as hostnames non-commands typed at the command line (“line vty 0 15/transport preferred none” still being required to disable this behaviour). The CLI also used a pre-existing non-cisco library, comnd, in IOS’s initial versions, making illustration of prior art very straightforward.

    The authors of IOS — Bosack, Lerner, Lougheed and Yeager — were variously ripped off as the router moved from a Stanford project to the VC-owned cisco Systems. Doubtless they will be eager to share their story of the origin of IOS. I can’t imagine that any cisco lawyer would want them testifying as to the muddy origins of cisco’s birth code.

    • Thanks anonymous commenter. This is actually very insightful and gives a great look into the murky history of the CLI all the back to Stanford. In fact, it appears that Cisco has not only failed to withdraw patent 7,047,526 from consideration, but they’ve also tried to strike quickly. As recently as the end of August, a judge in the case denied Cisco’s motion for summary judgement due to the fact that Cisco’s ownership of the CLI contains “disputed issues of material fact” ( That means that Cisco hasn’t proven beyond a reasonable doubt that they developed the CLI, likely for the reasons above including prior art. If they don’t drop the ‘526 patent soon, they do face the real possibility of a reexamination and possible removal of the patent.

      The question then becomes…does Stanford reassert their rights? Or does Stanford even go so far as to file their own patent to protect their work?

  7. Pingback: Is ACI Coming For The CLI? | The Networking Nerd

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s