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

iStock_000059460024_Small.jpg

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?

UPDATE:

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.

Parents
  • It seems to me that you have a "horrible experience" with the CLI. The CLI will always be present no matter how many tools that you put in place. Let's take for example that you use ConfD to configure the device but you make a typo in the IP address and the device becomes unreachable. If you had used the commit-confirmed action then you will be saved when the old configuration returns. In this case the engineer just used the commit action. OOPS! Box gone, dead, unreachable. If there is no CLI then you have to dispatch a technician to site (if it's remote, isn't it always when then kind of problem occurs?) to reset the device and put a basic configuration on it so that your management tool can reach it again. The smart CLI savy technician has a terminal server attached and can remote into the device and in 30 seconds or less the device is back up and running. I realize that in this example several things have to go wrong before the issue occurs but there are other scenarios where the device can lose it's configuration and you are effectively in the same scenario.

    Wow, that was wordy. I'll get to my point. The CLI will NEVER GO AWAY. It must be there for emergency purposes. If you have a well documented set of standards, a trained, professional staff, and a system to monitor that standards are adhered to then you are largely protected from this. Those of us that have been doing this for years are proud of our knowledge and can fix most anything that appears on the horizon. We have seen the types of tools that this will become and we always find issue with the implementation. It's missing the ability to configure some random setting that no one is ever supposed to need, but we do. As a result you have to hit the CLI and make the update manually. I have no illusions that this will be any different as that is the vendors work.

    Understanding the CLI leads to an understanding of the device and how and why it does what it does the way it does. This makes you a better engineer. Those engineers that have grown up on a GUI often have no clue why the command does what it does when they choose it. This can lead to serious issues and failed and unusable device. When you really know the device you can make it do what you want.

    Now that it seems that I have really come down on this topic I do see some value. Let's say that I work for an Amazon or a Google (I don't) where I am deploying multiple routers and switches every day. This type of solution is great for the deployment of this equipment and would allow you to hire low wage staff to deploy this equipment safely while learning the ropes. It can be used like HP NA to deploy a standard configuration update to every device or just certain types of devices. Say you upgrade an offices phones to Gig. You can quickly update the 1000+ switch ports to now use Gig instead of 100/Full (just an example, no comments on auto/auto please). This would be a snap with this kind of tool. Even with HP NA it would take several hours of checking and cross-checking to make the update.

    If approached from the right direction it will be wildly successful, just not at the expense of the CLI.

Comment
  • It seems to me that you have a "horrible experience" with the CLI. The CLI will always be present no matter how many tools that you put in place. Let's take for example that you use ConfD to configure the device but you make a typo in the IP address and the device becomes unreachable. If you had used the commit-confirmed action then you will be saved when the old configuration returns. In this case the engineer just used the commit action. OOPS! Box gone, dead, unreachable. If there is no CLI then you have to dispatch a technician to site (if it's remote, isn't it always when then kind of problem occurs?) to reset the device and put a basic configuration on it so that your management tool can reach it again. The smart CLI savy technician has a terminal server attached and can remote into the device and in 30 seconds or less the device is back up and running. I realize that in this example several things have to go wrong before the issue occurs but there are other scenarios where the device can lose it's configuration and you are effectively in the same scenario.

    Wow, that was wordy. I'll get to my point. The CLI will NEVER GO AWAY. It must be there for emergency purposes. If you have a well documented set of standards, a trained, professional staff, and a system to monitor that standards are adhered to then you are largely protected from this. Those of us that have been doing this for years are proud of our knowledge and can fix most anything that appears on the horizon. We have seen the types of tools that this will become and we always find issue with the implementation. It's missing the ability to configure some random setting that no one is ever supposed to need, but we do. As a result you have to hit the CLI and make the update manually. I have no illusions that this will be any different as that is the vendors work.

    Understanding the CLI leads to an understanding of the device and how and why it does what it does the way it does. This makes you a better engineer. Those engineers that have grown up on a GUI often have no clue why the command does what it does when they choose it. This can lead to serious issues and failed and unusable device. When you really know the device you can make it do what you want.

    Now that it seems that I have really come down on this topic I do see some value. Let's say that I work for an Amazon or a Google (I don't) where I am deploying multiple routers and switches every day. This type of solution is great for the deployment of this equipment and would allow you to hire low wage staff to deploy this equipment safely while learning the ropes. It can be used like HP NA to deploy a standard configuration update to every device or just certain types of devices. Say you upgrade an offices phones to Gig. You can quickly update the 1000+ switch ports to now use Gig instead of 100/Full (just an example, no comments on auto/auto please). This would be a snap with this kind of tool. Even with HP NA it would take several hours of checking and cross-checking to make the update.

    If approached from the right direction it will be wildly successful, just not at the expense of the CLI.

Children
No Data
Thwack - Symbolize TM, R, and C