Ethan Banks Not writing about IT.

Abstract All The Things -or- Why CLIs Are In My Way


Network engineers tend to live at the command line interface (CLI). We learn them. We know them. After a long while of using them, the commands required to get certain tasks done are second nature. I’ve configured so many access-lists, interfaces, routing protocols, VLANs, link aggregation groups, QoS policies, and spanning-tree topologies on Cisco gear that my fingers are on auto-pilot most of the time. While I can blame the CCIE program for some of that, the fact is that after nearly a decade and a half of banging away at various Cisco IOS CLIs, many commands have become ingrained in my had, and apparently my fingers.

That said, the CLI (whether Cisco’s or someone else’s) is a means to an end. I didn’t get involved in networking to learn how to use a CLI. I just want to build networks. Building networks is the goal…not banging my fingers into a keyboard until a BGP peer relationship is established.

“Well, yes,” you might say, “the CLI is just a tool, but it’s the best tool we’ve got for the job. The CLI is where the magic happens.” In a general sense, I can’t argue against that point. Some vendors, Juniper most notably, have capitalized on this fact by trying to build a better CLI than what Cisco typically offers. But I must point out that understanding the technology I want to use to bring a design to life is the real magic. Think about it this way: the IETF doesn’t codify the commands that should be typed to implement a standard. So the CLI, no matter how competent of a tool it might be, is merely an exercise in syntax.

I accomplished nothing different in my last post than I would have done building the same functional configuration on some competing Cisco platform. Yet, it took me several hours of reading a variety of documents to arrive at that Juniper configuration. Did I have to learn what LACP was? No. Did I lack comprehension of 802.1q? No. Was I unfamiliar with OSPF? No. Were the concepts of routing & bridging new ideas? No. Was I struggling to get a handle on VRFs and routing instances? Not as such. So why all the time spent? Because I needed to learn the Junos syntax to accomplish my design.

This is no slight on Junos. The more I use the Junos CLI, the more I like it. From the standpoint of a configuration tool, the Junos CLI has many features to commend it over IOS. And that isn’t really a slight on the IOS CLI, to be frank. They’re just tools. Let’s stop arguing about the wrenches we’re using to build a car.

So if not the CLI, what would I prefer? I want a configuration solution that I can use to build a configuration ONE TIME and apply it to any network device, independent of vendor. I recognize that different platforms have different capabilities. I understand that vendors extend standards to their own ends. I’m not naive enough to think that one configuration tool or abstraction library would ever be able to manage every aspect of every network device. But I do think a very significant number of network functions common to various classes of network devices can be abstracted in a common way. A layer of abstraction would allow me to consume network resources predictably, using whatever methodology I see fit. That could be a script, a CLI, a web interface, an agent/package driven tool like Puppet, an integrated orchestration system, a custom in-house software package, etc.

I see abstractions as a way forward for the networking industry. Certainly, software defined networking (SDN) is leading the drive here, as controllers such as OpenDaylight’s offer abstraction at various layers. Tail-f, who will be presenting at Networking Field Day 7 next week, is also in the abstraction business. And many others in the SDN market are offering products that abstract some part of networking, making it easier and more flexible to consume. While the industry hasn’t settled on exactly how all abstractions are going to work (lots and lots of discussions in this area), the models are shaping up. Network consumption will never be the same. And I think that’s a good thing.


  • The Tail-f NCS product is amazing the ability to use one cli or interface from their product and its ability to learn products and make changes end to end, their demos show you the way ahead and the path to SDN…

    Of course that is just another vendor doing what vendors do, making value add products that work…

    One could do the same thing but in house production and programmers to do it would be a huge cost, but the end game appears as just with Cisco CLI vs Junos CLI you will have to make a decision and invest in people that know and understand “A” product or language otherwise the learning curve on it all is just way too much on top of understanding the protocols that run the network…

  • Perhaps little OT, but still somewhat in the area of this :)

    Have you guys played anything with capirca?
    Looking for something that can manage access list on multiple routers in a good fashion.

    We are still using version-ed templates, than cut’n paste solution..

    It should be nice to have some linting, syntax abstraction and so forth..

    Regards Falk

  • I agree, and since we may only use 20% of the functionIlty of any given box, creating a multi-vendor configuration tool is probably attainable. But it could be even easier if you focus on the most time consuming error prone and least value added tasks.

    You could build it in house, but you really need to look at the TCO, the whole life cycle cost.
    People naively, and I was one of them, that open-source is costless. There are a lot of assumptions implicit going the build in house route, such as you picked the right project, you found the right developers, you have the right people guiding and explaining to the developers the nuances of what they want done.

    In my experience go with a commercial vendor like tail-f and others, you’ll have less headaches,someone to provide support and you won’t have to explain to mgmt why your little project got no where.

By Ethan Banks
Ethan Banks Not writing about IT.

You probably know Ethan Banks because he writes & podcasts about IT. This site is his, but covers other stuff.

Get the details on his about page.