Why a difficult-to-operate box is in the interest of Cisco !


Well, my last blog generated quite an interest and discussion on the use of CLI for box configuration.

As a follow up I want to write on a related topic although it may generate some difference of opinion here but this is my goal to generate a wider discussion on this topic.

OK, in my last post I said that CLI is cumbersome; it takes a while to get used to and the worst thing is that if something goes wrong, the troubleshooting takes ages, sometimes.

I also said that protocols like NETCON and YANG would really make the configuration easier, more intelligent and move the focus from the box configuration to the network configuration in addition to making the configuration GUI friendly.

I want to bring a new dimension to this discussion.

Let’s see if Cisco would really like to give you a better user interface and a better configuration tool.

Although I write Cisco here, but it can mean any vendor that gives CLI experience, for example Juniper etc. ( I specifically mean any CLI which is propriety and vendor specific )

Ok to start with; let’s agree on a fact that using CLI is a skill; rather an expert skill. This skill is required to configure a box and additionally to troubleshoot networking issues. Not only do you need how to move around with CLI, but you should be able to do it with speed. Isn’t it?

This skill requires training and certification. If one has expert certification, it means that he is not only intelligent but he is a command guru. Correct?

Cisco certification is a big money making industry. If not a billion dollar, it must be generating hundreds of million dollars of revenue for Cisco ( I contacted Cisco to get real figures, but seems these are not public figures). Cisco makes money by making one pay for exams and selling them trainings. Then there is a whole echo-system of Cisco learning partners, where Cisco makes money by combining their products with training services and selling through them.

It costs to get expert level certifications. There is a cost if one passes, and there is more cost, if one fails.

An engineer may end up paying thousands of dollars on trainings and exams. We are talking about huge profits for Cisco here just because of the popularity of certifications. There is one for everyone; for a beginner to expert; for an operation guy to architects.

Besides creating experts, Cisco is winning here from three angles:

  1. It is making its customers used to CLI as customers feel at home using the codes they are trained on.
  2. It is creating loyal users and customers as they would recommend products they already know very well.
  3. It is generating big revenue. ( and big margins as it is a service)

For sure the It is win-win for Cisco here.

In my perspective, therefore, a difficult to operate switch and router is in the direct interest of Cisco, as Cisco needs experts to run their products and the experts need certifications.

Cisco, therefore, would NOT be very encouraged to make networks easy to operate and configured. Even I have seen the GUI of one of Cisco products; it simply sucks. It seems to me it is not one of their focuses.

Thus, this raises an important question here:

Why would Cisco take steps to make the network more programmable, easy to operate with newer tools and take CLI out of their central focus? Wouldn’t it like to stick around with difficult to operate products and keep on making more money?

Would you agree with me?

I like to hear, both if you agree or disagree and why?


After publishing this article, the majority of comments only focused on CLI versus GUI. For sure GUI is more user-friendly but CLI has delivered well because of not having good competition either from good GUI or SNMP, uptill now.

However the main message was to talk about “vendor specific CLI” NOT command line in general. In programmable age, tools like NETCONF and YANG offer a standard way to configure network elements. Whether you use it with GUI or with command line, the benefits far exceed compared to vendor “CLI”. NETCONF/YANG is a standard way to configure any vendor equipment. The protocol leaves it to the vendor to determine how to apply configuration instructions and in what order within their devices. This means this puts pressure on the vendors to do additional development on their products to execute the user configuration in whatever order he ordered. This removes pressure from the user to learn configuration for multiple vendors and learn multiple CLIs. This is the future, NOT CLI.

  • In many ways I have to agree... if Cisco has done one thing it's mostly kept much of the basis in their CLI consistent.  It's not like it totally changes all the time per se.  Many of the same way I did things in the late 90's I'm still doing today with Cisco CLI... yes I'm from the old school wr mem family... not that copy run to start isn't legit too... hehe!

  • Whew, read through all of this. I'm a Cisco guy for the last 21 years with loads of experience in other equipment. IMHO you will never build an affordable working product that can cover the what 2000+ commands that are available on a single Cisco unit can do. Cisco can't even do it. Time and time again we run into issues with SW where its like why doesn't it monitor this or that. Well it does, if you know the OID and can program the box to look at it or display it or your SQL founded and can pull it out of the database. Etc Etc Etc. Or I can keystroke for a sec and see it on the CLI.

    A lot of this is like DOS vs Apple. one OS lets you see everything and the other tells you it works but you don't know why. On the CLI I can see every aspect of my system down to the bit buffer to troubleshoot a problem. All this talk of GUI NETCONF etc goes out the window when you use it to blow up a box and have to have someone on site.

    We have enterprise licensing on several SW components, add that up for years. A lot of the benefit is what we get from SAM but as far as the core network gear not so much. For all that money I have a CLI that comes free, with the price of the box.

  • Something that my brain keeps coming back to with all this NETCONF and YANG and SDN and "unspecified open-source interface" is The Who's song, "Won't Get Fooled Again."

    It's in Cisco's best interest to have a "difficult" to operate box. Let's accept all the spoken and unspoken premises there... they apply to any/all concerns involved in the alternatives as well. SDN? You're talking about programming. That's actually significantly more difficult than the refined limitations that the CLI provides.  NETCONF, YANG? OK, we'll see you after your training course in how to use those, which we paid for out of the training budget (hmmmm...), or after a few weeks of digging through documentation, blog posts, and tense changes if there's no training budget.

    I dunno, man. I'm not sold that it's difficult in the first place, and I'm not sold that the alternative is significantly different. I've heard it's essentially the same, in fact, but I don't know many using the alternatives, so maybe I just know the wrong people.

    Meet the new boss?

  • I think the drive by Cisco, not sure about other vendors, is to continue developing their product line.  This currently comes in the form of new command structures, primarily in their newer devices and occasionally in older devices that are still supported.  One shift they have made recently is to implement a licenses feature set model where you pay for the features you need up front or as you need them.  Without getting into the politics of the cost of said licenses, or the accessories needed to implement them, do you think this revenue source shift might be a precursor to a possible shift to NETCONF and YANG, or just another source of income?

  • I have quite  "allergy" to vendors owen E/NMS software ..

    Any how NETCONF support is the what I miss from NCM  to flush out Juniper  "service-now" permanently from my net

    so  "please with suger on the top" vote

    Happy days!!

THWACK - Symbolize TM, R, and C