cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Caught between CLI and SNMP!

Level 9

My first experience in the IP domain was that of a shock!

I had moved from the optical transport domain in an operator to the IP department.

As an optical guy, I used Network Management system (NMS) for all tasks including configuration, fault and performance measurements. Above all, I liked the nice Graphical User Interface (GUI) of NMS.

However, I found that in the IP world, Command Line (CLI) is used for everything; from provisioning to troubleshooting. CLI rules in the IP domain.

“CLI is the tool for Engineers”, I was told.

OK fine! This may have something to do with my personal preference that I do not like the user interface of CLI or because I came from optical background, that this stuff seemed strange to me.

Irrespective of the user interface, and with all functionality that CLI provides,from my perspective, CLI is not the ideal tool for configuration. First, it focuses on a single box i.e. configuring box by box, which is cumbersome.  Second, it is to prone to human error and because of errors sometimes troubleshooting takes considerable time. And lastly, it is vendor specific so changing a vendor box needs a totally different skill-set to configure a box.

Therefore, as an operator, in my view, there is a need for a more flexible way of configuring/ service provisioning. The focus should move out from “box configuration” towards “network configuration”. Also, in this age of emerging technologies like SDN and NFV, where NMS is the primary focus; CLI will simply block the innovation.

Network configuration is a major part of the operators' OPEX. Studies put it around 45% of the total TCO of the network.

CLI has a place today because the management protocol -SNMP itself is not ideal for service provisioning. That is why operators are using SNMP primarily for monitoring purpose, not for configuration purposes.

Both CLI and SNMP, also, do not support one another important requirement for large complex service provider networks. That is they do not support transactional mode for network configuration.

Transaction enables multiple configurations to take place as one transaction or fail completely (All or none). To clarify this very important point, take an example of IPTV service that involves configuring one router, two switches, two firewalls and a billing system.  A transactional protocol   enables configurations on all involved network elements or NONE. This is beneficial because if there is any problem of configuration validation on even one network element, the configuration would fail on all other network elements.  This means that configuration would never be implemented partially on some network elements. This is the essence of “network configuration” as we talked earlier.

So do we have to live with SNMP and CLI for network configuration, forever?

No!

The NETCONF YANG protocol, developed by IETF for network management, has a single focus and that is configuring network as easy as possible. IETF learned from the experience of SNMP on what can be improved and approached the new protocol in ground up fashion. It is purpose built for configuring network.

NETCONF is the management protocol primarily for network configuration while Yang is text based modeling language designed to be used with NETCONF. Both are needed for a complete flexible service provisioning in IP networks.

There are FOUR main features of NETCONF YANG:

  1. Support of Transactionality:  Configurations can be applied to multiple network elements as one transaction to either succeed or otherwise.
  2. Get configuration feature. This is distinct advantage compared to SNMP. With SNMP backup config. is available but it is polluted with operational data ( Alarms, statistics); with NETCONF one can just have the configuration data.
  3. Vendor device independence. NETCONF can be used as standard configuration protocol for any vendor. The vendor’s box will sequence the configurations and execute them. This sequencing is internal to the vendor’s box and NETCONF does not need to be aware of it.
  4. Multiple network elements can be configured at one time thus saving time, configuring the network.

Therefore in summary, NETCONF is the right solution to solve network management issues in standard way. It is the next generation of network management protocol, which will reduce the time to provision services for an operator and will help in applying multiple configurations to multiple network elements at one time.

Now it is your turn to tell me:

  1. How do you feel about CLI as a network configuration tool, would you like to live with it forever?
  2. What issues do you face, using CLI? If there are any.
  3. Do you think NETCONF can deliver better than SNMP/CLI?

Would love to hear your opinion!

31 Comments
Level 13

I've always thought of CLI as a necessary evil. Evil because it's finicky and difficult to work with; necessary because there aren't really any tools that do the job better in most cases.

I think it will be interesting to see how well the major players support NETCONF; for example, whether companies like Cisco decide it is in their best interest to support standard-based configuration processes.

Level 9

Thanks,

Cisco is very intersted in NETCONF, they even acquired the company TAIL-F that standardized the protocol in IETF.

Level 17

Any protocol that is easy to put to use is preferred over one that is only simple to setup!

Level 12

As networks grow to mass proportions in todays IT centric world, CLI ("box configuration") is not practically feasible.  Something has to change and you can see it with the interest in SDN, OpenFlow, and NETCONF.  NETCONF being vendor agnostic, I believe support of NETCONF would be a beneficial and evolutionary change necessary for Solarwinds products.

Level 9

aaswi‌, correct!  SDN and NFV will need more flexibility which is not possible with CLI !

Level 15

For a 30+ year IT veteran.  The CLI has always been a powerful tool and highly utilized.  The need for transactional processing is accomplished through script writing including audit logs.  I have always thought that graphical utilize too many system resources.  I find that I am ten times faster making configurations from the CLI than from any GUI. 

Level 9

Thanks for sharing perspective. There would always be people disagreeing with the point. But I can understand that with your 30 years of experience with CLI, you will feel more at home with the CLI........

Though I feel disagree on the point that one can be more faster on CLI....

Level 15

I recently had the need to configure multiple Nexus 5500 switches as part of a SAN configuration.  To use the graphical tool, required running a java GUI for each switch, working through several layers of menus, and finally editing the interfaces, and the save and apply those changes.  After the 4th switch, I had figured out what was needed for changes.  I SSH'd into the remaining switches, and configured by CLI.  Total time in the GUI was 30 minutes.  Total time at the CLI was 7 minutes.  This is just a simple example, but after many years of the CLI, it is must quicker. 

This is a great discussion post!  Thanks!

MVP
MVP
  1. How do you feel about CLI as a network configuration tool, would you like to live with it forever?

That depends on what CLI I guess.  The Cisco CLI I'm quite comfortable with and I think its simplicity and intuitiveness are a big part of how its lasted for so long.  Other CLI's vary in their usefulness to me.   ScreenOS I never liked, JunOS isn't that bad.  Fortigate's CLI is horrid, etc. etc...   On the other hand, Cisco's GUI's are usually less than optimal while others might have better GUI's.   However, let's take Fortinet for example, they kind of have two GUI's, the one on the box itself, and the Fortimanager.  I don't see much correlation between the two, which is bad, very bad.   To make matters worse, you HAVE to use the CLI for some "advanced" tasks, which might be something as simple as assigning the source IP for communicating with your TACACS server.

However, you're forgetting one big thing that you can have a major advantage with in the CLI.  The ability to script your changes.   You can plan out in advance the steps that you're going to take and do them when needed.  I've even gone to the point of creating spreadsheets for repetitive complex changes that allow even a contractor to plug in a few variables and 99% of the time are able to do in minutes what might have taken hours otherwise.

That, and the use of NMS systems like Solarwinds NCM and more specifically their "compliance" part to find and fix things that aren't standardized.   I don't think enough organizations put enough emphasis on creating good standards and following them.   When you get a large # of devices having big deviations in configurations just becomes unwieldy...

  1. What issues do you face, using CLI? If there are any.

Even with Cisco you do need to be careful when your working in the CLI, esp. if you are scripting.   Simply cutting and pasting doesn't always work, you have to learn that its much more reliable to FTP in your changes so you not only get them all done at once, but get them in reliably without any drop offs.  Backing out of changes, not sure what I would do without a "reload in 5:00" command!!  Essential if you're doing things that might otherwise cut you off.   Sometimes it can be tricky seeing your debug messages come across while you're typing, which can confuse things.

  1. Do you think NETCONF can deliver better than SNMP/CLI?

While I'm sure there is bound to be some way better than the CLI, I have yet to see it.   After looking through a presentation on NETCONF and Yang, it doesn't show me nearly enough to interest me at this point.  I'll keep my eyes on it, but I don't want a systems like this to cause more problems than it solves.  I've seen systems that were supposed to make things easier, but instead just helped to hide where there were problems by providing a layer of obfuscation between the meat of things (ie: the "running-config") and some GUI that is supposed to make everything look much clearer.

That being said I am always looking for newer, better and more reliable ways of doing things.   I would love to see a consistent way to program things across multiple vendors devices, heck, even the same vendor sometimes.  But, with the big differences in how some devices work, I'm not overly optimistic on this...

Level 9

1. Some vendors are not doing good when it comes to GUI. I know a big vendor who boasted that he has latest and greatest GUI on one of his products.For one of the tests, the vendor clicked a button on GUI which opened a mini CLI window inside the GUI from where he started typing CLI commands

2. Yes, one needs to be expert to use CLI.

3.NETCONF and YANG  would provide a consistent way across the vendors. That is the goal.

Level 9

Agreed cahunt

Level 14

mfaisalk‌,

Thanks very much for your posting, which I find quite interesting and enlightening.  Until today, I never heard of NETCONF and YANG, SDN, etc.  We can all agree that using CLI (or NETCONF and YANG, or SDN) will always be much faster that via web GUI.  However, for me, and perhaps many others, there are a few limiting factors, when it comes to adopting any configuration protocol besides CLI:

  1. As some have already stated here, the main limiting factor is vendor support.  Since CLI has been around for such a long time, it has dramatically larger vendor support. 
  2. The second one, also as can be sensed here, might be willingness to change by the network professionals to use multiple methods for configuring devices.  That is, since they can already configure their devices via CLI, some network engineers may want to keep using CLI. 
  3. The third limiting factor, I believe would be availability of network tools that use NETCONF and YANG, SDN, etc.  There are many third-party tools for configuring devices via CLI (i.e. SecureCRT, PuTTY).  And the cost of those tools may, at times, be very low. 
  4. The fourth, and last limiting factor is $$$. Many companies may already have invested a great deal of $$$ in licensing for CLI tools.  So, why would they turn around and spend many $$$ more in getting yet another network configuration tool? 

Again, I am very much new to this topic -- having never heard of NETCONF and YANG, SD and the others.  In any event, I would be interested in alternatives.  You learn can indeed something every day.  Thanks!!!

Level 14

It just occurred to me that this sounds a whole lot like the question of what came first, the chicken or the egg. 2000-05-19.gif

That is...,

  • Most vendors won't rush to create third party alternatives to CLI until they know there's a market for those.
  • Most network device vendors won't also rush to modify their devices until there are many tools and many clients interested in these.
  • Very few companies may rush at looking for third party alternatives to CLI for managing their devices until most network devices support those.
Level 15

I believe you are correct!

Level 9

mr.e

All I can say is that they have to...because more and more operators are asking for it and the market requirements are changing in terms of a more centralized control of network.................either they join are they are left behind.

Level 9

NETCON and YANG are new buzz words in the town.....I understand that many people here are too used to CLI....they cannot think beyond that....let me ask you, have you ever faced problem with extended troubleshooting in the network just because there was a simple mistake that you did in the code ?

Level 14

mfaisalk‌,

Yes, I have indeed run into troubleshooting nightmares due to errors I've made (or my teammates.).    BTW, I am not disagreeing w/you on the need for alternatives to SNMP and CLI.  I am just saying that I don't think change won't come as quickly as we'd hope. 

                  

Level 14

By the way, this thread got me curious about NETCONF and YANG, which I never heard about (as I stated in my first reply). Below are a couple of link to a YouTube training sessions on NETCONF and YANG. 

I have to say that I am most impressed by what I saw. I can see why mfaisalk‌ created this Blog posting. You got my vote!!! 

Level 15

Appreciate the links.  I will go take a look at them.  Got my curiosity up now.

Level 14

I hear what you are saying, but the jury is still out on whether this will be the future in network management.  NMSs will have to support this new "standard".  If they don't support it, it will go nowhere fast.  I also have not seen anything out there about many management software vendors supporting NETCONF YANG, much less hardware vendors like Juniper and Cisco actually implementing support for it.  This is nothing new.  It has been thrown around for around 5 years now, but it hasn't really gained any ground yet.  If users are not asking for it, it won't be supported.  It makes no sense for vendors to support something that the end-users are not asking for.  And when/if they do start asking for it, it will need to be tested by actual end-users.  If the software utilizing this protocol aren't very good with it, users will get discouraged quickly.  Just because it is out there doesn't mean it will materialize.  There is still a long way to go with this.  If this doesn't gain any ground in the next  say 5 years, I'm afraid it may become obsolete to the "next generation" network protocol.  I'm not saying that it won't either.  I am just a realist that understands the ever-changing IT world.  I don't believe in the "next big thing" until I actually see it out there in mainstream use.

Level 14

I have to agree with mr.e‌.  If there is no market for it, no one will be left behind.  Vendors don't support protocols just to support them.  They are asked to or "forced" to by their end users or defined standards.  If these don't exist, they don't get support.  It is the money game.  Why invest money into something just because it is "cool" or supposedly the "next generation"?  If all these operators are asking for it, we would all know more about it.  This community is mostly made up of these operators and I would venture to say that 75% of the community has not heard of this protocol, much less seen it in use.  Wanting to try it/see it and wanting it supported by vendors are 2 different things.  When users actually start playing with it, then we will see where it goes.  Stating that they will be left behind is a long shot.  I am positive that SNMP will be supported for the next 5-10 years.  That is a long time for vendors to "catch-up".  This is if they have to at all.  I am not saying that this protocol won't go somewhere, but it sure won't happen as quick as you expect or want it to.

Level 14

Well, the SolarWinds folks take much pride in being pioneers. 

history-man_bag-men_s_fashion-handbag-pioneer-pioneering-tmen21_low.jpg

So, here's another great opportunity for SolarWinds to do some serious pioneering. 

Level 14

mfaisalk‌,

I think this would be a great Feature Request for NCM.  Since it is your idea, you deserve the honor -- and the credit. 

Level 9

Yeah it would be a good idea to get Solarwinds to think seriously about it....thanks for throwing in weight....

Level 7

Thanks for the post Faisal.  I am also an optical guy, but came at it from a traditional IP background.  Seems odd, but it is true.

How do you feel about CLI as a network configuration tool, would you like to live with it forever?

     I have worked with many CLI interfaces and am comfortable using most.  I think CLI will be around as long as customers keep using it.  Like anything else we are comfortable using, if you take it away there will be a fight.  All the justification in the world will not convince the true CLI advocate.

What issues do you face, using CLI? If there are any.

     The biggest issue is lack of conformity between vendors.  As much as everyone tries, it is "illegal" to do a true copy of the CLI from one vendor to another.  However, that would make it harder to give up.  I think the greater issue is accuracy.  One false move and the network is dead!

Do you think NETCONF can deliver better than SNMP/CLI?

     I am afraid I do not know much about the NETCONF offering but I did hear about Tail-F.  I will take a look at some of the suggested sites provided in this post.

I think mr.e might be on to something with the man bag theory.

Level 9

thanks hefthwack

I liked when you said....one false move and the network is dead

And yes you are right, one of the major issues is the conformity among different vendors.

Level 7

If nothing else, I have a sense of humor.

Thank you,

Harold Fritts

303-887-7629

(sent from my Etch-a-Sketch, so please excuse typos and auto correction of words I did not mean to type)

Level 7

Thanks for the great article!  I'm just getting into NMS from an IP background and this article is a welcome insight into possible future trends. 

Level 12

nice one.............

Level 7

You are welcome. I enjoyed the post and I certainly share your vision as

we head full steam towards SDN and NFV. Looking forward to more posts from

you.

Kind regards

Darren

On Tue, May 26, 2015 at 12:41 PM, muwale <

Level 7

Thanks for nice post.

About the Author
I work for Saudi Arabian Mobile Operator Mobily. I work in planning team for Converged IP and Optics domain. I have more than 15 years of experience working in Optical transport, access, MPLS-TP, DWDM, IP/MPLS.