One of the major talking points of the SDN Hype Crusade was the CLI bashing. That’s total nonsense (ask anyone who had the privilege to suffer through a GUI-based deployment), but the myth refuses to die. I wrote more than a dozen follow-up posts focusing on REST API versus CLI.

Fallacies of GUI

I love Greg Ferro’s characterization of CLI:

We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.

However, you do know that most devices’ GUI offers nothing more than what CLI does, don’t you? Where’s the catch?

For whatever reason, people find colorful screens full of clickable items less intimidating than a blinking cursor on black background. Makes sense – after all, you can see all the options you have; you can try pulling down things to explore possible values, and commit the changes once you think you enabled the right set of options. Does that make a product easier to use? Probably. Will it result in better-performing product? Hardly.

Have you ever tried to configure OSPF through GUI? How about trying to configure usernames and passwords for individual wireless users? In both cases you’re left with the same options as you’d have in CLI (because most vendors implement GUI as eye candy in front of the CLI or API). If you know how to configure OSPF or RADIUS server, GUI helps you break the language barrier (example: moving from Cisco IOS to Junos), if you don’t know what OSPF is, GUI still won’t save the day ... or it might, if you try clicking all the possible options until you get one that seems to work (expect a few meltdowns on the way if you’re practicing your clicking skills on a live network).

What the casual network admins need are GUI wizards – a tool that helps you achieve a goal while keeping your involvement to a minimum. For example: “I need IP routing between these three boxes. Go do it!” should translate into “Configure OSPF in area 0 on all transit interfaces.” When you see a GUI offering this level of abstraction please let me know. In the meantime, I’m positive that the engineers who have to get a job done quickly prefer using CLI over clickety-click GUI (and I’m not the only one), regardless of whether they have to configure a network device, Linux server, Apache, MySQL, MongoDB or a zillion other products. Why do you think Microsoft invested so heavily in PowerShell?

Latest blog posts in The OpenFlow/SDN Hype series


  1. "“I need IP routing between these three boxes. Go do it!” , somebody can use these words to market a new magic product that promise to get rid of expensive engineers :D

    After all, I think I remember correctly, some product line manager from HP already claim that SDN will cure the world from pesky network engineers.

    In the end, everybody is free to use whatever they want to get the job done (CLI or GUI). The problem appears when somebody has the idea that using GUI instead of CLI means cost cut and quick import of know-how.
  2. That sounds to me less like a case for a better GUI on the network devices themselves, and more for a halfway decent network-wide orchestration system. SDN is relevant in this context, but only as an alias for "configuration API" - someone out there still needs to write a decent big-picture system to tie all of the pieces together.

    Personally, I'd put my money on a more generic configuration framework, something like what you can do with ansible on Junos, allowing admins to define their *own* tools and workflows becoming useful long before another "Enterprise Ready!" 8,000lb gorilla turnkey solution can do more than the top 10 workflows of the top 5 customers.
  3. Well, I think there is some value to GUIs, but not because they happen to be graphical.

    For whatever reason, GUIs tend to have more abstraction than CLI. There is nothing inherent in the interface that suggests that has to be the case, but I think the mindset is different. "I am making this GUI to make it easier, therefore I will think through how to simplify."

    Where the GUI just exposes knobs, it is usually built on the same underlying config, so the GUI and CLI will be necessarily the same. But where the GUI provides the abstraction you talk about, that can be powerful.

    The question we ought to be asking is if that abstraction is available from the GUI, why not make it available in the CLI as well? I know it is not entirely apples-to-apples, but the point is that there are ways to do it in both.

    -Mike Bushong (@mbushong)
  4. Vague statements about a "GUI" making things better are based on the felonious assumption that GUIs are inherently better than CLI. Anyone who has been breathing in the IT space longer than a few years will have long since grown past such assumptions.

    That doesn't mean some great tool with a great GUI that takes care of some hard bits won't ever exist. I'm just saying "GUI" doesn't automatically mean "better."
  5. GUI provides density of information that can hardly be implemented in CLI. A live traffic graph on an interface or a queue is far more natural than a stream of numbers in a terminal because it immediately communicates both the amount of traffic and percentage of link utilization - something very difficult to do with text only. I find tweaking QoS queues while at the same time looking at the live traffic graph to see the result raises my productiviy significantly.

    GUI wizards help make sure one doesn't forget to set any important parameters in the first run. Hence, I can be sure my apprentice will configure a PPPoE server without forgetting to set DNS parameters - GUI will not let her click Next before filling out these fields. After doing this a dozen times she will figure out that it's faster to copy&paste CLI config for new deployments which is a nice side benefit.

    We use IOS for core routing, but a lot of Mikrotik stuff for access and PE. Mikrotik is surely not suitable for heavy-duty core stuff, but their Windows GUI is a great example of how a useful GUI should be developed.
  6. We have both Cisco ASA and Checkpoint Firewalls. I love the Checkpoint GUI for rule base administration and log analysis. It's the only reason to buy Checkpoint in my opinion, not the reliability, not the hardware, not the support, not the value for the money. But down in the weeds - the CLI of a checkpoint, things get sticky and that's where the real CP cowboys play.

    ASA's on the other hand - the GUI is a poor attempt at making an ASA as friendly as a Checkpoint. The GUI is NOT intuitive, frustrating, and basically nothing more than a Graphic interpreter of CLI commands (you can even turn on the option of looking at the CLI that the GUI is about to enter for you). Most telling is when calling TAC for an ASA, the TAC engineers NEVER use the GUI for analysis and troubleshooting.

    I think GUIs are nice and have their place (Windows) but CLI is where the real power is.
  7. > “I need IP routing between these three boxes. Go do it!” should translate into “Configure OSPF in area 0 on all transit interfaces.”

    Why not EIGRP? How do you know those boxes are in area 0?
    1. ... and this is exactly why we never get anything done. For every simplistic solution (how complex do you think a N-node network configured with a wizard could get) there's someone saying "but then it won't work under scenario X".

      If you want to have a simple network that can be configured with a wizard, you have to start with the simplest possible design.
  8. Juniper partially did this years ago with NSM. I was able to select 5 SSGs and create a mesh VPN through a GUI. In 10 minutes all sites could route between each internal LAN.

    I believe the bigger issue is that if network management is simplified, the cost will drop. No longer will Cisco/CCIE be billable at the current rate. How hard can it be to register all devices to a central system, provide a graphical layout of the environment, and then define routes, ACL, QOS, etc. The answer, job/pay protection (like lawyers).

    SDN is seeking to address this. If we can build physical servers and storage, databases, email systems, content management systems, customer relationship management systems, and much more at the click of a button...

  9. Beginners could benefit of a GUI under the very strict requirements that such will produce exclusively CLIs for them to use, rather than "applying" the change on the system (semi-ASA implementation). It would be like a notepad++ for a CLI veteran, who preps his work offline, but with the added benefit of ability of checking syntax against a real system which the GUI fronte ends, thus has access to verifying validity of changes needed to be applied. So the GUI would be a *sort of* front end network OS IDE ... with the latter term, come to think about it, possibly becoming relevant, when moving to SDN ;-)
  10. Check out Cisco's Prime Infrastructure for IP NGN. Watched a demo at Live2013 in London and was bowled over by the sexiness :)

    Certain assumptions are made, of course, but it's a start.
  11. If you only know how to wield a hammer, every problem will look like a nail. There are benefits of using both. OR try and combine both based on the task at hand.

    My 2 cents.
    1. You know what's best of both worlds? Extracting config section and opening it in a text editor.

      F5 does that (not sure about Junos) and it's absolutely fantastic. Imagine doing that for ACL or FW ruleset.
  12. This post is only 20 years late...
Add comment