Some SDN proponents claim that the way we configure networking devices (using CLI) is the biggest networking problem we’re facing today. They also conveniently forget that every scalable IT solution uses automation, text files and CLI… because they work, and allow experienced operators to work faster.

Since I wrote this blog post, the debate shifted to API is better than CLI, and I had a few choice things to say about that fake dilemma.

Published on , commented on July 10, 2022

Is CLI In My Way … or Is It Just a Symptom of a Bigger Problem?

My good friend Ethan recently published a blog post rightfully complaining how various vendor CLIs hamper our productivity. He’s absolutely correct from the productivity standpoint, and I agree with his conclusions (we need a layer of abstraction), but there’s more behind the scenes.

We’re all sick of CLI. I don’t think anyone would disagree. However, CLI is not our biggest problem. We happen to be exposed to the CLI on a daily basis due to lack of automation tools and lack of abstraction layer; occasional fights with the usual brown substance flowing down the application stack don’t help either.

The CLI problem is mostly hype. The “we need to replace CLI with (insert-your-favorite-gizmo)” hype was generated by SDN startups (one in particular) who want to sell their “disruptive” way of doing things to the venture capitalists. BTW, the best way to configure their tools is through CLI.

CLI is still the most effective way of doing things – ask any really proficient sysadmin, web server admin or database admin how they manage their environment. It’s not through point-and-click GUI, it’s through automation tools coupled with simple CLI commands (because automation tools don’t work that well when they have to simulate mouse clicks).

CLI generates vendor lock-in. Another pile of startup hype – in this case coming from startups that want to replace the network device lock-in with controller lock-in (here’s a similar story).

We’re Not Unique

Startups and pundits would like to persuade you how broken “traditional” networking is, but every other field in IT has to deal with the same problems – just try to manage Windows server with Linux commands, or create tables on Microsoft SQL server with MySQL or Oracle syntax … even Linux distributions don’t have the same command set.

The true difference between other IT fields and networking is that the other people did something to solve their problems while we keep complaining. Networking is no worse than any other IT discipline; we just have to start moving forward, create community tools (because vendors' track record isn't exactly stellar), and vote with our wallets.

Whenever you have a choice between two comparable products from different vendors, buy the one that offers greater flexibility and programmability1. Don’t know what to look for? Talk with your server- and virtualization buddies (I hope you’re on speaking term with them, or it’s high time you buy them a beer or two). If they happen to use Puppet or Chef to manage servers, you might try to use the same tools to manage your routers and switches. Your favorite boxes don’t support the tools used by the rest of your IT? Maybe it’s time to change the vendor.

  1. For more details, read the Network Automation RFP Requirements blog post. ↩︎

Latest blog posts in What Is SDN? series

More blog posts in this series

Recent posts in the same categories

15 comments:

  1. Ethan Banks 18 February 2014 21:26
    I'll argue that what I'd like to get to in the industry is some state of consistency. I don't want to relearn how to do the same thing again, just because the platform is different. I don't disagree that the best way to configure network services these days is still the CLI. That's why I'm at one almost always. More choices are coming, but they are as disparate as the vendor.

    As you say, perhaps its time for us to come up with our own answers, and stop asking the vendors to homogenize what they've traditionally sold as differentiators.

    There's a longer conversation to be had here.
    Replies
    1. Ivan Pepelnjak 19 February 2014 10:00
      We'd all like to get some state of consistency; I'm just saying that there's consistently no consistency across the whole IT industry, and most other areas of IT evolved to deal with that fact.

      Also, here's a nice summary of why we are where we are ;)

      http://www.ietf.org/mail-archive/web/v6ops/current/msg18631.html
    2. Ivan Pepelnjak 19 February 2014 10:54
      Also, here's one way of "doing it right":

      http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf

      Obviously this particular solution is not publicly available because it's considered a secret sauce, but imagine what would happen if all the brainpower focusing on ODL would decide to do something like this.
    3. Simon Knight 19 February 2014 14:11
      Excellent discussion.
      My talk at Conext last year had some ideas in this space that might be interesting: https://www.dropbox.com/s/ud59gtxw1hk5dwc/conext_13_slides.pdf and http://conferences.sigcomm.org/co-next/2013/program/p235.pdf
    4. Anonymous 08 March 2014 16:53
      I don't mean to sound like a naysayer, but asking for platform-agnostic api to vendors is a bit too much, isn't it?
      Isn't it somewhat like asking for common api to do instrucitons to both Windows and Mac PCs? My understanding is that in the PC world, the Java VM has accomplished abstractions to some extent, but I'm not sure it will happen with our network devices. As a datacenter guy I do automations often, without expecting it'll happen in the foreseeable future. Most of my batch configuration tools first check sysdescr with each device, then call functions that are specific to the model, which I see is is a necessary evil. That said, some vendors sometimes fail to keep consistency across their own firmware versions and architectures, be it CLI, SNMP oids, or syslog message formats... which is not cool. -tami
  2. Andrew 'anetnerd' Hrycaj 19 February 2014 01:52
    I believe this is just another example of how the networking industry is evolving. As we demand more from the devices we are deploying in customer networks, we need more efficient ways to gather the data we need, analyze it, and react appropriately. I have always said, like in programming, the logic can be learned through understanding the standards and then the rest is just syntactical differences. I agree with Ethan that maybe it's time we demand a common configuration experience so we spend less time learning how to tell a box to do XYZ protocol correctly which is a huge waste of time in my opinion!

    I will say that I don't have much faith in the common network engineer to come up with clever ways of creating a great automation script to make their command line experience easier. Creating templates to solve repeating problems in the networking industry takes a lot of time in itself, but to see a network engineer take the time to say "Hey, maybe I can write a script in ABC language" is even more difficult to find. The command line is far from dead. If we want to make our command line experience better, we need to figure out WHAT problems we are facing, HOW we can fix them with automation, and DEMAND that these tools be built into future software versions.
    Replies
    1. Jason Edelman (@jedelman8) 20 February 2014 13:33
      Because it's relevant to this topic, how about a frame work as described here for a common CLI leveraging Python? ;)

      http://www.jedelman.com/1/post/2014/02/the-power-of-a-programmable-abstraction-layer.html
    2. Ivan Pepelnjak 20 February 2014 19:14
      It seems to be a great starting point. When are you going on Kickstarter as Steven suggested?
    3. Simon Knight 20 February 2014 22:50
      @Jason: nice blog post. It's great that we're moving forward in libraries that allow us to read/write native data structures to network devices.

      The next challenge is working with those data structures: the elements in them have network-wide context, so we need network-wide abstractions to express this. I think this is where networking is trickier than DevOps - the config of a device depends much more on its role in a network than a server, for instance.

      Python is a great choice - I covered some of the libraries we're using in AutoNetkit at PyCon AU: http://www.youtube.com/watch?v=EGK5jjyUBCQ

      @Ivan: I'm not sure we even need Kickstarter. Most of the pieces are already there, and we can engage the academic community to help out. With the right architecture, a lot of the tasks map well to honors or masters projects.
  3. Anonymous 19 February 2014 17:20
    I'd forget the vendors here. What's required here is tool that can talk to every device regardless of vendor via API and translate what you want to do accordingly from a single interface, GUI or CLI. This is very possible as long as the configuration doesn't relate to non-standard extensions and enhancements. Add in device groups and such like and its even more useful. Let's get on Kickstarter.

    Steven Iveson
  4. DRL 19 February 2014 19:10
    The way we managed networks at modest scale was embarrassing compared to technology designed to be intuitive and accessible to non-geeks. At web-scale its a disgrace (Mike Dvorkin nailed it when he called it a crime against humanity at ODL summit) and unacceptable. Imagine if cars could only be driven by auto mechanics or mechanical engineers. Just because this broken model is still the only one available doesn't mean its good or that this won't change. People not invested in the status quo are going to fix this. Disruption refuses to be denied.All the people defending buggy whips might want to start learning about the steering wheel.
    Replies
    1. Jason Edelman (@jedelman8) 20 February 2014 13:37
      Maybe this wouldn't be so bad. There would be low level mechanics that doubled as taxi drivers and high level that were the specialists. In either case, 1) we would have to budget for rentals/taxi's and maybe not own a car and 2) we would be more productive since we would be able to sit in the back seat and get more work done :)

      Of course, I'm only semi-joking!
  5. Anonymous 19 February 2014 19:54
    What we need is an open source functional clone of Tail-F's ConfD and NCS.
  6. Anonymous 20 February 2014 12:38
    Thinking back when I first started in this world in Networking I saw someone entering command in CLI and the IT guy looked cool. The problem is more of a human thing than a technical problem. I had a interview a couple months back I told the VP imagine if we had to use CLI in the webpage. For every discussion and for every post on twitter or facebook or any social media you have to but a command that would put a picture or a comment or a tag. Imagine if you go to your iPhone/Windows phone/Android and you would have to use a cli to open an app. People would not use this.
  7. Asbjorn Hojmark 20 February 2014 20:57
    I'm not sick of the CLI. To me, the CLI makes little difference.

    I've worked with many different versions of IOS, XR, NX-OS, PIX/ASA, WebNS, XDI/CatOS, Stratacom OS (whatever that was called), Kalpana OS, etc. etc. ad infinitum. And that's just Cisco... Plus other vendors’ OSs, including XOS and JunOS.

    The hard part, to me, has *never* been the CLI. The hard part has always been understanding the task, understanding the technology, and making the right design. After that, it’s just commands... and who cares if that OSPF command is under the interface, under the process, or configured with a 'set' command? Meh.

    I totally agree that some fundamental things in networking need to change. That includes stuff like locator/ID separation (not necessarily through LISP), policies based on address or physical port, troubleshooting larger setups (beyond ping, traceroute, commands to show mac address tables, connecting sniffers multiple places etc.), layer 2 adjacency ‘needs’, and tons of other things.

    Most of the significant problems in networking is far closer to the top of the list than the CLI. Really.
Add comment
Home
Sidebar