back to article Cisco says CLI becoming interface of last resort

Cisco thinks the command line interface (CLI) should be the interface “of last resort”, according to Dave West, the company's chief technology officer for systems engineering and architectures across Asia. CLIs won't disappear from Cisco products any time soon and West doesn't expect networking pros to stop using them. But he …

  1. Pascal Monett Silver badge

    I doubt the CLI will ever disappear

    The CLI is indispensable as a surgical tool to quickly and efficiently cut through the layers of GUI obfuscation and deal with the issue at hand.

    But I do think that all the virtualization and hypervisor-level management means that it is likely to be less used in the future.

    "Interface of last resort" is a perfectly apt name. Sometimes the CLI is the last line of defence.

  2. steamrunner

    Interface of "last resort"? The interface that "actually works" more like...

    1. Phil O'Sophical Silver badge

      And the one that's secure...

      1. This post has been deleted by its author

    2. Doctor_Wibble
      Gimp

      > Interface of "last resort"?

      I think we are being told that technical things of the modern era are to be done by swishing away on a tablet* and not with those quaint keyboard things*. That's also because they don't want you to do anything interesting or complicated which might show up bugs, and in any case if you have a GUI it's easier for that to get 'accidentallly' 'upgraded' to use their via-the-cloud config management instead of being under your control. Not that I'm paranoid or anything.

      .

      * add 'keyboard in cold dead hands' icon here

      ** or 'prodding and fondling a slab' if you're a peasant, obv.

      1. Doctor_Wibble
        Facepalm

        P.S. Aargh [6bB][0oO][lL1]{2}[Oo0]ck[5sS] I can't count asterisks correctly though on the other hand after reading it again, either footnote could potentially fit at either point...

  3. Alister

    “The 'greybeards' are still going to be there to build the automation and build the interfaces and the programmatic ways that they want to interact, because they know their networks better than anybody,” West told El Reg at Cisco Live in Melbourne this week. “They have grown and lived in those things.”

    Now Cisco thinks those greybeards, even the experts holding high level certifications like CCIE and CCNE, will spend less time rummaging around under the hood and more time talking to business people.

    Speaking as someone who has a beard of the requisite colour, I don't think the second paragraph is true at all, given that it is recognised that we of the hirsute persuasion are the ones who make it possible for the clever automation and scripting to work.

    In West's view, sublimating the CLI therefore means NetAdmins can make their other skills more prominent and profit as a result. That's a story plenty of Sysadmins were told as server virtualisation took away the need for server-related drudgery.

    In my experience server virtualisation doesn't take away the need for server-related drudgery, it just adds an extra layer of complexity which also requires managing.

    Whether a server is virtual or physical, it still has the same management requirements, and although individually a virtual server may no longer have the associated hardware management requirements, those just transfer to the host hardware - you still have to replace broken bits, just not on a per server level.

    1. nematoad Silver badge
      WTF?

      Can't see this working.

      "...even the experts holding high level certifications like CCIE and CCNE, will spend less time rummaging around under the hood and more time talking to business people."

      And what pray tell will the "greybeards" have to say to the suits?

      On the one hand we have experts at wrangling the network into what is required, on the other we have masters of doublespeak and PR bullshit. They may both speak the same language i.e. English but comprehension between the two parties is going to be fraught with difficulty.

      1. Rafael 1

        Re: And what pray tell will the "greybeards" have to say to the suits?

        "Here's a nickel, kid. Get yourself a better computer."

  4. Uberseehandel

    History repeats itself

    Not so long ago there was a hugely significant network system called Netware. A great many people built careers out of being Netware Engineers. It could be obscure at the limits, and it appealed greatly to computer oriented individuals. Eventually Netware's market share diminished much faster than expected. I don't recall a Netware GUI, but there could have been one but it wouldn't have been "professional" to rely on it.

    Today, network engineers are proud of their CLI skills and many shun GUI tools. And from their view point they are behaving optimally. The CLI is part of the network admin's employment protection mechanism.

    However, GUIs don't make spelling mistakes, they are capable of processing a high level function change and making all the required sub-system amendments, all without mistyping, and, when well designed and developed, it can be easier to align desired reconfigurations with the original intentions. On the other hand a GUI designed by those unfamiliar with network processes is usually pretty dire.

    In my own experience,the introduction of GUIs for use by DBAs has reduced costs, shortened development time, increased flexibility and improved reliability.Getting there wasn't always easy. The development of reliable network configuration, management and BI tools will be equally lengthy and controversial.

    1. hplasm
      Facepalm

      Re: History repeats itself

      "In my own experience,the introduction of GUIs for use by DBAs ..."

      DBAs aren't network engineers...

      1. Uberseehandel

        Re: History repeats itself

        No, they are not network engineers.

        By being excessively literal you have neatly missed my point, I'm guessing you are a CLI aficionado.

        DBA's use DDL and DML to configure and manage DBMS and increasingly GUIs, which is analogous to Network Administrators using the CLI to configure network devices as opposed to GUIs.

        1. Flocke Kroes Silver badge

          Re: History repeats itself

          Install:

          CLI: write script, debug script, document script.

          GUI: click on things until it works. Attempt to document what you remember of the correct sequence of clicks missing out the miss-steps made while learning the GUI interface.

          Rebuild after disaster:

          CLI: type one word and press enter.

          GUI: One of the miss-steps you didn't document is required to get the right option to appear on the GUI. Someone re-organised the GUI to make it more intuitive and all your notes are now useless. Fart about for ten minutes until you think you got it right then find out next week what you got wrong.

          With practice, you might restore one service with a dozen clicks on a GUI. A dozen services means 144 clicks - or a script with twelve words in it. There are tasks that are better handled by a GUI - like copping one image. As soon as you have to do something repeatedly, (or if someone else may have to do it after you leave) the CLI is the right choice and anyone who says GUI can suffer the death of a thousand clicks.

      2. J__M__M

        Re: History repeats itself

        "In my own experience,the introduction of GUIs for use by DBAs ..."

        DBAs aren't network engineers...

        And even if they were, this take would be totally and completely wrong. GUI's on network equipment just flat out sucks it, so help me God.

    2. Rob Crawford

      Re: History repeats itself

      Considering the number of products where the GUI gets things wrong or functions are simply not implemented in the GUI (Aruba and Citrix comes immediately to mind)

      Couples with the additional joy an fun that web interfaces bring either through security concerns (hello all vendors) or that require you to use ancient versions of browsers to work (hello Cisco ACS) or insist that you must have a particular browser plugin to view the statistics pages (would you install THAT Adobe plugin?)

      Nope I think I will stick with the CLI thank you very much

      Oh BTW I do very much like the Meraki Dashboard as it actually works and does let you implement a lot of stuff very quickly and they have actually paid attention as to how it should be done.

      But I don't see it adopted for datacentres any time soon (well at all) even though Cisco are trying to incoroporate it into Prime

    3. Chris King
      Mushroom

      Re: History repeats itself

      The CLI is part of the network admin's employment protection mechanism.

      Usually because the GUI is broken, deficient or requires a specific version of JRE, Flash or some obscure browser plug-in to even work.

      And that's just the DBA tools, the ones on network kit are WORSE.

    4. Salts

      Re: History repeats itself

      Reminds me of a quote

      the gui making simple things easy and difficult things impossible

  5. MrBlack

    Tried to re-configure an (eol) Cisco 1552 just yesterday using the GUI alone - hair losing experience, ssh'd on and bingo, can grab some bits out into notepad, re-configure and paste back in. Try to do that on any current business edition GUI only Cisco device without losing hair.

    1. theblackhand

      A bad GUI doesn't make GUI's a bad thing...

      Many of Cisco's GUI's suffer from being terrible or running on underpowered hardware for some of the tasks the GUI is trying to do (looks at standalone AP's and switches in particular...).

  6. Anonymous Coward
    Anonymous Coward

    CLI is still useful and taught as part of the CCNA, CCNP and CCIE exams, however tools such as the Tivoli Netcool suite offer admins a form to push command changes.

    Linux has shiny XWindow shells, but most users still fire up a terminal.

  7. RonWheeler

    Overpaid arrogant gits

    promoting job security through obscurity.

    1. sjiveson

      Re: Overpaid arrogant gits

      Funny then, that even today most vendor products don't offer an alternative at all and where they do, it's very often unusable (ditto for their APIs). Even the CLIs themselves are rubbish, particularly where Cisco's is concerned.

      This is a vendor issue that's a long way from being solved, whatever the interface.

    2. Rob Crawford

      Re: Overpaid arrogant gits

      Or perhaps you simply havn't a clue?

      It's a bit like UNIX boxes vs windows in the 90s.

      You want the job done properly use a UNIX box, you want a machine where anybody can make changes get a Windows server so the less skilled person can click on something in the GUI.

      The UNIX box, restore the OS, run the install scripts, create the mount points, copy your scripts back on to the machine, get your startup scripts in place, get your cron jobs and it's fine.

      OK so it's a few hours of hell but it's back to the original state (that is supposing you do not have a proper backup)

      When the Windows box dies or the monkey pressed the wrong button, dear God it was awful and a restoration was never managed in less than a day and the fallout lasted for a week or so.

      Needless to say windows boxes are used almost everywhere because you don't have to pay for arrogant gits protecting their jobs because a monkey is cheaper most of the time

  8. Sooty

    The benefits of a CLI

    are that it's scriptable and auditable.

    If you're doing something with a GUI, it's easy to click the wrong thing and potentially take down a production system, especially if it's a complex procedure with multiple steps.

    If it's all scripted, you can have people review it first and make sure it's right, you can run the same thing exactly on multiple different systems. Ideally one being a test before you go near production with it, in the knowledge that exactly the same thing will be run again and again, without the possibility of deviation.

    1. Anonymous Coward
      Anonymous Coward

      Re: The benefits of a CLI

      Absolutely. I'll give them a bye if the GUI has a web services layer exposing an API.

    2. P. Lee

      Re: The benefits of a CLI

      So perhaps a two tier system- gui generates scripts which can be reviewed and deployed.

      Abstraction trades resources for admin/Dev time. It also often results in unintelligible cli configurations.

      Guis work best when there are few parameters. That's not great for Cisco. If it's hard to represent the problem or solution visually, a gui probably isn't the best option.

  9. Steve Davies 3 Silver badge

    Oh the memories

    I was at a sales pitch for a product when I asked this question

    So I've configured the device using this snazzy GUI and it is running. How do I get the config out so that the Auditors can approve it and we can put it under source control?

    The Tech Guy giving the pitch calmly said,

    "We don't allow that. It is a security feature."

    They were shown the door a few minutes later with the boss saying,

    "Come back when you can provide us with the functionality we need to even begin to consider using your devices."

    They never did.

  10. Toltec

    Both CLI and GUI have their uses, I still use a CMD prompt on a PC because certain operations suit it.

    1. Tim Russell

      I agree, show me the GUI for nbtstat -R .... yes I know probably there somewhere but, CMD right click, run as admin and done... sound complicated but it is far less blood pressure raising!

  11. IanCa
    Flame

    nurses running the network now ?

    CCNE ??? I have a CCIE, but never done a nursing test...and I don't have a beard, sandals strictly for the beach... I do wear a suit. are you going to call us boffins next?

    Guis are great for bulk provide of "customer ports", similarly related automated activities, anything that fits with "orchestration" view of things, Newer network architectures that underlay SDN spine-leaf (e.g cisco ACI) autoprovisions a lot of interconnect links without human involvement. however, when your building kit on console port in a DC, fixing something remotely on a GPRS link, or troubleshooting a major network down situation in 3 mins flat with the PHB standing over you, the CLI is all you ever ever want to rely on. And trusting developers who barely know what a default gateway is to software provision the network? don't get me started..

  12. Fortycoats

    Does a CLI need Java, Flash, etc.?

    And some GUIs only work properly with a certain version of Browser or Java. UGH!

    Not to mention browsers pestering about security settings.

    OK, a well-designed and properly thought out GUI doesn't do any of those things, it just works. But I've come across way too many horrible GUIs. Or GUIs where you can't actually do everything and you need the CLI to perform certain actions (Brocade and EMC, I'm looking at you here!).

    Also strongly agree with Sooty's comment on scripting and auditing. Very important, especially if you're performing changes to a production environment.

  13. e^iπ+1=0

    CLI vs GUI

    I always think, if I'm going to do something only _once_ and I'm fairly confident that I'm not going to repeat it then I can equally well use a CLI or a GUI.

    If it's a task that I might possibly repeat 2 or more times, then I program it via a script.

    I just hate repeating things.

    Maybe I end up having to tweak the script repeatedly as the scope widens.

    If it's a task that I need to demonstrate how it was planned / performed then it's definitely _worse_ with the GUI: bit of random clickety recorded here and there.

  14. Nate Amsden

    nice to have both

    As someone who used to use Cisco from time to time any time I saw their CLI I wanted to gouge my eyes out with an ice pik, it is soo overly complex for the most basic tasks. Same with Juniper (and others that try to clone the user experience because it's the most common). I'm sure that's fine for folks that are dedicated in that field but for others not so much.

    I've been a happy Extreme Networks customer for about 15 years now, their CLI is much easier to manage, one of the main reasons I have stuck with them for so long. If you google "techopsguys simple network management" you can see a blog post I wrote several years ago with a couple good comparisons. Not only is the number of commands massively reduced, but in almost all cases the commands you are typing actually make sense in english (e.g. "create vlan" , and "configure vlan" or "config vlan" for short or "config <vlan name>" for shorter). The OS on the switches is entirely API driven(has been for 13 years). So much so that even on the command line when you run commands it submits API requests to the OS to do things. I learned that 5-6 years ago. To person doing the management it's transparent but I was surprised to see that level of abstraction(?). There is a GUI as well though I believe it is severely limited compared to CLI. I have never really used the GUI.

    I remember one incident with the GUI of Cisco PIX many years ago, my manager at the time set it up as I had no PIX experience prior and he used the GUI for everything. I needed to add a rule to allow OUTBOUND traceroute. He said use the GUI. So I did. And the result was the PIX started blocking ALL OUTBOUND TRAFFIC. I was at a loss for words. I later discovered what the problem was, there was no default policy(?) applied to the external interface, so when I made that rule it thought to add a policy, that policy was DENY and so all traffic was dropped, took about 1-2 hours to figure it out and fix. The following weekend I took it upon myself to rip that firewall apart and rebuild it from the ground up, with the CLI so I had total control (and closer to total understanding). The firewalls ran pretty decently after that.

    Next company had some issues with their ASA firewalls but that turned out to be the fault of an idiot network engineer who set session timeouts for network connections to a WEEK. The firewalls would max out their session/state count at around 500k and stop passing new traffic. They had this problem for more than a year(happened once every 1-3 months and solution was to reboot both firewalls at the same time) before I joined(Cisco support was not helpful apparently) and I was able to resolve it within minutes(which is when they told me the week timeout, we set it to something like 4 hrs after that and never saw session counts go above about 20k after that).

    Some CLIs are bad, some are good. For me the SonicWall CLI is bad, but the GUI is really good(html), so I use the GUI 99.9% of the time there(though Sonicwall Global Management GUI is terrible, the UI directly on the devices is good at least NSA3500/NSA3600). I am still a very happy SonicWall customer for what my org uses them for they work great, very few issues.

    With Citrix Netscaler, on the 9.x release at least they used java, and needed an old version of the JVM. At first I didn't like it, but then I saw what they did to the new UI in 10.x with html5. Both myself and the rest of my team would rather keep the older UI, faster, easier, and just better in all areas. We have a dedicated XenApp server for internal management apps like netscaler with an older java version so it works flawlessly. Nobody browses the internet with that system so not much of a security risk. The speed is improved even more over XenApp because of the "chattiness" of the app over a WAN connection slows it to a crawl, but XenApp executes firefox in the data center so that communication is very fast.

    Netscaler 10.5 has driven most of our management to the CLI because the html5 interface is so bad. Couldn't even use Netscaler 10.0 or 10.1 because of stupid Netscaler Datastream licensing restrictions which were eliminated in 10.5(and never present on 9.x).

    Back when I used F5 BigIP(v10 and earlier) the GUI there was pretty good, the CLI was OK, though I remember several occasions when we used what was it, "bigpipe" to bulk load configuration and config entries would get randomly dropped without notice and it would take some time to figure out what happened, maybe the process we were using was wrong at the time I don't know, I wasn't the designated network engineer.

    My favorite kind of UI though is one that can/will show you what underlying commands will be executed for various tasks, though I can't recall the last time I came across one that did that.

  15. John Doe 6

    I'm still looking for...

    ...any other UI than the CLI for a Cisco Catalyst 65xx switch.

  16. doke

    GUIs don't scale

    I've got over 1000 switches, and 60+ routers, firewalls, and load balancers from 5 different vendors. I've never seen a GUI that comes close to handling all that. We used to have CiscoWorks, but it only applied to our Cisco devices, only did a few things, and didn't do those well. I don't have time to repeat a gui action on hundreds of devices. I _need_ to use APIs, and scriptable CLIs.

  17. Gene Cash Silver badge

    "because they know their networks"

    There ya go. In a world of mostly copying & pasting from StackOverflow, nobody knows shit, much less how to script a CLI.

  18. J__M__M

    the real reason

    People don't like CLI's because they can't fake it. You know it or you don't.

  19. PyLETS

    Linguistic User Interfaces

    Use of linguistics in communication will never die, particularly when the agents on both side of a conversation are getting better at this kind of thing. Hand waving won't go away any time soon either. Take your pick. It's nice sometimes for hand waving to be able to achieve some imprecise things due to these not being fully understood when you haven't been able to learn the language. I've ordered meals in restaurants using hand waving when there was no common language, but you have to go into the kitchen to point at what you want.

  20. Vulture@C64

    CLI is indispensable for batch changes, in a GUI you have to poke around in all sorts of different menus and sub menus for each function, eg, creating a VPN you might need to create access lists, natting, policy and routing entries - all over the place in a GUI but in the CLI you can do it all in one batch.

    For CLI to be replaced we need a global replacement which works on all Cisco products, not just Nexus.

  21. F0ul

    CLI won't disappear - but its got its place.

    I don't play much with Cisco stuff anymore, but I do use Powershell and Azure - your modern day CLI and GUI - and the rules stay the same, use the tool that makes most sense at the time.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like