Today's network management discipline has numerous problems that will affect software-defined networks (SDNs).
The trouble with network management
Most management systems require complex installation and configuration processes for a successful implementation, for example. This is the opposite of the SDN premise, which is to simplify networking. I've frequently seen popular management systems languish (I call these "shelfware," indicating that they've been installed but really do nothing more than sit on the shelf instead of providing useful visibility into network operations).
Another complaint is that most network management systems (NMS) do not provide useful or actionable information. For example, you might consider a Top-N display of interface utilization useful until you begin to wonder about the period covered by the information. Is it a Top-N from the last five minutes, the last hour, the last day, or the last week? Determining the reporting period would take some serious investigation.
In another case, I've seen a system in which the interface discard counters reported zero, while the QoS system encountered congestion and dropped packets in an oversubscribed queue. Because the problem involved dropped packets, it affected application performance. The organization hadn't set up the NMS to report QoS queue drops, so the congestion was invisible.
Configuration management of an SDN is entirely different than the configuration-per-box approach that current NMS products include. These products rarely include any type of policy definition from which configurations should be built. This approach won't work with an SDN that requires policy definitions for proper configuration and operation.
The end result is that existing network management is ill suited to monitoring and managing a modern SDN.
Here are some characteristics that an SDNMS should have:
- Auto configuration - requiring minimal administrator configuration
- Auto discovery - automatically discover the network
- Identify the infrastructure links - these are the basic links to monitor
- Identify key servers - maybe through traffic analysis (volume, QoS, administrator input)
- Automatically monitor key metrics - errors, drops, QoS drops, 95th percentile, with the reporting period selectable by the administrator (hourly, six or eight hours, daily, weekly, monthly) and report in a Top-N format (note: Statseeker's displays, fast display refresh, and Sparklines graphics make it one of my favorites for performance data display.)
- Automatic device and interface grouping - to ease administration and implementation of policies
- Policy-definition mechanism - allow the administrator to provide guidance on configuration and problem detection
- One-click drill down to the underlying data from any display, especially those showing key metrics
- Virtual network instance membership - easy identification of devices that are members of a virtual network and ability to see where they connect to the physical infrastructure
- Health of the SDN control system
Some of these characteristics are identical to non-SDN NMS requirements. But most vendors of existing products provide only basic NMS functionality, placing responsibility for configuring anything beyond the basics on the administrator. Device and interface grouping can significantly reduce the amount of effort required for monitoring and reporting configuration. This is a function that is rarely found in NMS products today. With SDNs, these functions are going to be more important because the SDN itself will be based on similar groupings.
I wish that more NMS products included good auto discovery and auto configuration. For some reason, vendors seem to think that a lot of configuration is acceptable. But this is one of the reasons that so many products become shelfware. To fit into an SDN environment, an NMS must incorporate more automatic configuration and operation. The network will be changing too quickly for manual configuration practices to succeed.
NMS vendors are going to have to get smarter about SDN technology and adapt their systems to work in the new world. The additional challenge they face is that SDN is a developing technology. I think that the vendors that move soon and learn to adapt quickly (i.e., via agile software development) are going to be winners in the world of SDN monitoring and management.
To answer my introductory question: Does software-defined networking need software-defined network management?
I think the answer is, "Yes." NMS vendors will need to design products specifically to handle the unique functionality an SDN provides.
A longer version of this article appeared on No Jitter.