Monitoring a Software Defined Network, Part 4
SDN offers an opportunity to redesign network monitoring.
Note: My discussion of SDN monitoring covers several topics. Here are the prior posts:
Thoughts on SDN device monitoring
Chris Young contacted me this week to talk about this series on monitoring SDNs. Chris works for HP and is one of the few people who is involved in both networking and network management (most people gravitate to one of the two disciplines). We discussed monitoring and managing an SDN, and Chris mentioned some of the things that I had not yet addressed.
First, I want to make a distinction between monitoring and managing. I think of monitoring as a mostly passive function. Collecting, recording, and displaying interface statistics falls into this category. Management is an active function, which results in changes to the network. One might use data collected by a monitoring system to drive corrective actions, i.e., "management."
I've been using the word "monitoring" in this series of blog posts. That's because I've been focused primarily on the data to collect. Of course, collecting data and not using it is fairly pointless. I've always advocated using monitoring data to correct minor problems as well as major failures. But most organizations don't seem to make the time to address the minor problems. They tend to work in fire-fighting mode all the time. Perhaps the work with SDN will allow us to make progress in automating the correction of a lot of minor problems that hurt network performance and stability.
Monitoring Non-Flow Data
One of the topics that Chris and I discussed was monitoring device-centric data. His first reference was to power supplies and fans. I had been ignoring these items, but they are just as important (maybe more so) than flow, interface, and SDN controller data. We can lump this type of data into a "Device Health" category. SDN doesn't (yet) address this type of data because it isn't related to either the control plane or the data plane. (Is it part of the "Management Plane," or something else?)
SDN can make a large collection of switches look like one big switch/router. That's part of the advantage of SDN--it hides implementation details. But when one of the components is experiencing health problems, we need to know about it.
How should an SDN controller report on problems with devices within its infrastructure? Or should there be a separate SDN monitoring system in place that performs this task? These are good questions that I've not seen addressed in anything I've read. If we're not careful, we'll create this new SDN thing and it will be great...until something breaks. Because there is a separate monitoring system that's not well integrated, we'll have organizations that are running their networks blind simply because they are unaccustomed to effectively using a network management system.
The counterpoint to integrating the monitoring functionality is that it adds extra burden to the SDN controller. For better scalability, it would be good to run the data collection and monitoring system in a separate compute module. Perhaps a good architecture is to have the SDN user interface be within the monitoring/management platform and have the SDN controller in a separate platform.
Finally, does the SDN controller southbound interface need to include API calls to retrieve non-flow data from the devices? The current OpenFlow definition doesn't include non-flow data. It seems that we need to think about abstractions that apply to device health as well as abstractions for the data plane.
Do We Use SNMP?
Chris then made a very interesting point: Do we use SNMP (Simple Network Management Protocol) to monitor device health data? That's a very good question. Of course, we could take that approach. It minimizes the amount of work to be done.
However, I see this as an opportunity to begin experimenting with something new and improved. Several vendors have been advocating other data collection mechanisms like XML, mostly around the configuration tasks. But why not apply XML (or JSON, Java Script Object Notation) to the problem? I think it would be nice to drop ASN.1 notation from network management. It is too arcane and doesn't hide any of the details. One might argue that low-level troubleshooting and management relies on the details. There is truth to that, but let's use something that's easier for us humans to handle.
There are some things that SNMP has done well. Being able to walk the MIB (Management information base) of a device is very handy, even without the original MIB definition file. I've sometimes been able to determine useful information about a device by walking its MIB using SNMP. With good names in the XML or JSON representation, it would potentially make it easier to work with a device for which a MIB definition file is not available.
Could we also take this opportunity to improve on some of the error reporting? For example, the TTL Exceeded variable lets us know that a packet was discarded due to its Time To Live expiring. Was this due to a routing loop or due to a traceroute? Which end systems were involved (i.e., what were their IP addresses)?
In addition to the counter, include variables (e.g., TTL Error Address?) that contain the IP address of the source and destination, or perhaps a bigger variable that's an octet string containing the packet header. When an error is detected, make a copy of these variables from the packet header. The network management system can then query the TTL Error Address variable to determine the end systems that were involved. By having this variable available, it would eliminate the need to perform a packet capture. Other error counters that report routing lookup failures or ARP failures could also benefit from this treatment.
Would switching to XML or JSON cause an increase in the size of the OS image of a network device? Possibly. However, I think that the cost is worth it, if it results in better management.
Vendors working on SDN will need to think about the whole architecture and not just the separation of control and data planes. SDN contains a lot of promise. I certainly hope that we're not building a system in which monitoring and management will be a "bolt-on" afterthought.
Terry Slattery leads a half-day workshop on SDN at Enterprise Connect Orlando 2014.. Check it out!