OpenFlow applications work where network management tools fail
Published: 17 Nov 2011
I've heard some say that software-defined networking (SDN) and OpenFlow applications are "just another" network management solution, and I understand their doubts. After all, most network monitoring and management technologies have fallen flat.
But OpenFlow applications go well beyond the abilities of network monitoring or management tools by enabling a centralized view of the entire network configuration along with control even in a dynamic virtual environment. (Read an explanation of OpenFlow applications and controllers.)
OpenFlow provides protocols and a platform for monitoring the network, but it also provides a powerful toolset for configuring the network in a positively controlled system with multiple feedback loops for accuracy and confirmation. Not a single traditional network monitoring and management tool offers this capability.
Where network monitoring tools fail: Polling, pulling and logging
All three basic network monitoring/data collection methods used today -- Simple Network Management Protocol (SNMP),command line interface (CLI) and Syslog -- fall short.
All three basic network monitoring/data collection methods used today -- Simple Network Management Protocol (SNMP),command line interface (CLI) and Syslog -- fall short.
SNMP: SNMP was intended to be the universal method for exposing data to external applications for remote monitoring. The technology includes "trap" capabilities so that devices can push information about their status or conditions to the management console. But SNMP has many shortcomings, including being limited in the number of data types it can handle. While vendors can extend the SNMP OID in their own numbering scheme, this doesn't solve the whole problem.
CLI problems: Scraping the CLI (or CLI scripting) has been effective for single-vendor solutions where they control the software and where the CLI does not change often. But CLI scripting is unreliable, slow and not robust.
Syslog problems: Many have turned to Syslog and log monitoring solutions to extend their toolsets, and this has led to some interesting software in recent years. Software from Splunk and SolarWinds, for example, mine logs for information and status. Again, the content available in logs is somewhat limited and misses a lot of information about the device and its status.
CLI problems: Scraping the CLI (or CLI scripting) has been effective for single-vendor solutions where they control the software and where the CLI does not change often. But CLI scripting is unreliable, slow and not robust.
Syslog problems: Many have turned to Syslog and log monitoring solutions to extend their toolsets, and this has led to some interesting software in recent years. Software from Splunk and SolarWinds, for example, mine logs for information and status. Again, the content available in logs is somewhat limited and misses a lot of information about the device and its status.
With OpenFlow, one can reference the overall network configuration to handle the migration of servers. The old methods of network management, SNMP and Syslog, were acceptable for static networks, but they don't work well in dynamic environments. OpenFlow applications offer an alternative
Perhaps the greatest limitation of these management systems is the lack of control -- or the limited capability to configure and manage the device itself. We often want to make a configuration change to address a specific problem or event. OpenFlow applications enable network engineers to do just that.
Perhaps the greatest limitation of these management systems is the lack of control -- or the limited capability to configure and manage the device itself. We often want to make a configuration change to address a specific problem or event. OpenFlow applications enable network engineers to do just that.
Companies or engineers that dismiss OpenFlow/SDN as just another network management tool aren't taking the time to do the research -- or they may even be hoping that OpenFlow will not cross the adoption gap because it will change the fundamentals of the networking marketplace.
