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.
Monitoring An SDN Is Different
In a series of six No Jitter articles (see "Related Posts," below), I've outlined the types of things that will be different for monitoring an SDN. So far, I've not seen any vendors with anything that fulfills any of the requirements that I have identified. But those articles are not about a software-defined NMS (SDNMS).
Here are some characteristics that an SDNMS should have:
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.
For example, a mobile workstation in a hospital may be part of a patient care Virtual Network Instance (VNI), a virtual Layer 3 network. As the workstation moves from location to location (wired or wireless), the port to which it connects needs to become connected to the proper Layer 3 network. The SDN controller can make this happen, and the SDNMS needs to track that change as it occurs.
The same thing happens when a server virtual machine (VM) migrates from one hardware platform to another. The ability to track the Layer 3 network membership and end device locations (physical switch/port and perhaps even physical room location, if location services are enabled) will be valuable. Integrating location services with a UC system allows an emergency call to have location information displayed with the caller ID, potentially improving emergency response times, for example.
Merging characteristics yields even more possibilities. Let's say that we merge location services with key performance measurements. When a VM edge device moves to a new hardware platform, for example, the performance data can with it -- after all, the performance is not due to the switch port, but to the server. It will also be important to accurately track the sources of errors, which may be due to a hardware problem. In this case, the errors will continue to occur on the physical port, regardless of which end device is using that port. However, QoS drops are an example of a type of error that may follow the end device. Knowing whether to track the end device or the switch port for each type of performance metric is going to be one of the factors that makes an SDNMS stand out from a generic NMS product.
Summary
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:
I think the answer is, "Yes." NMS vendors will need to design products specifically to handle the unique functionality an SDN provides.
Related Posts:
