In A Software-Defined Network, Does the CLI Even Matter?
December 11, 2013 1 Comment
- The main benefit from SDN is that managing devices via the CLI will come to an end.
- Putting the final nail in the CLI coffin will require vendors and administrators to think differently.
Whenever I talk to Arista Networks’ Doug Gourlay, I always ask when the company is going to make a GUI manager for their networking gear. It’s something of a running joke, because Arista doesn’t have one, preferring to focus on making its products integrate with others; let someone else make a GUI manager. Other vendors such as Alcatel-Lucent, Avaya, Brocade, Cisco, Dell, Extreme, HP, IBM and Juniper have a similar strategy, which is to make their switch products controllable via APIs and make their network managers capable of much more robust command and control processes.
The CLI has hung around so long because the alternatives – such as SNMP, writing CLI shell scripts or, worse, moving entire configuration files around – are half baked, unreliable and disruptive. Network administrators could telnet to a switch, punch in a few commands and ensure the switch or router is properly configured. Little cottage industries developed to make CLI management easier, such as automating the replication of common command sets, managers that tried to maintain configuration histories and communities that shared scripts for common or not so common tasks.
If nothing else comes out of SDN, it will be that the CLI will die a fiery death.
Network management systems all tried to aggregate devices such as switches, routers, firewalls, etc. into a uniform fabric, but the management UIs quickly broke down into element managers breaking the fabric paradigm and being reduced to multi-unit management. SDN structures such as APIs are simply fancy element managers using a different method, but what changes is that a controller – nearly all SDN architectures use some type of controller – becomes the aggregation point; network administrators will express what they want via a policy and the controller will, to quote Star Trek: The Next Generation’s Jean-Luc Picard, “Make it so.”
If IT is deploying an N-tier application, administrators will not access devices via a CLI or GUI and make changes; they will tell the controller, “I have three application tiers and I need these services between them. I also need each tier to scale on demand. I need this kind of firewall policy, and any traffic leaving this location needs to be encrypted.” When the application changes, IT will describe the changes and let the controller figure out what needs to be done. Finally, when the application is no longer needed, the controller will clean up after itself. It doesn’t matter if the network is physical or virtual, whether you’re using Ethernet, OpenFlow or an overlay. More importantly, when there’s a problem, the controller will provide the instrumentation to assist in troubleshooting and resolving the problem through modeling and automation data gathering.
Of course, the death of the CLI depends heavily on network and network management vendors adopting new management paradigms that effectively abstract the details from administrators. It will also require network administrators giving up manual processes and trusting the controller. It won’t happen overnight, but it will happen. That’s the hope, anyway.