Monitoring an SDN is going to be an interesting proposition. I wrote about the first part of monitoring and management in Monitoring a Software Defined Network, Part 1. I talk about monitoring stuff that happens on the network (i.e. switch or data plane) side of an SDN. Many of the low-level errors that we monitor today in traditional networks are also important in an SDN.
But there’s also the need to monitor the controller, just as there has been a need to monitor the CPU and processes in a traditional router or switch. I talk about monitoring the SDN controller in the second post of the series: Monitoring a Software Defined Network, Part 2. How are developers and network operators supposed to know when a controller is experiencing problems? How will the staff know about loss of connectivity between multiple controllers? Will we be able to detect DoS attacks against controllers? Is the SDN controller having problems communicating with some of the switches, possibly affecting the network’s optimally route new flows?
These types of questions should be addressed by SDN controller designers before the systems get deployed. Let’s hope that the developers don’t decide to add management after the fact, as has happened so frequently with traditional networking equipment.
-Terry