711 Words. Plan about 4 minute(s) to read this.
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.