I recently had the opportunity to catch up with well-known fellow networking fanatic Greg Ferro for a conversation about the intersection of network monitoring and software-defined networking (SDN).
The point of our conversation wasn't to hash out the pros and cons of particular SDN monitoring toolsets. After all, the playing field, so to speak, is still far too unstable. The AstroTurf, if you will, was only laid out a few hours ago in Internet time, and the players barely know what color jerseys they're wearing.
Instead, our talk was to discuss why networking pros should care about SDN right now and how today's network monitoring techniques fit in, if at all. And if they don't fit in, what types of monitoring techniques will be required to manage the networks of tomorrow.
The transition to a network that knows what to do
I think most of us have at least a rudimentary sense of what SDN is -- the path data takes through a network is managed by a software-based controller rather than proprietary hardware. With a controller, devices across the network dynamically change elements like best path, quality of service (QoS) and permitted data types. All well and good, but most of us also probably think to ourselves, "Why would I want to go down this path that will undoubtedly include a steep cost increase and learning curve just for this new capability?"
Why go down the SDN path? The answer, in short, is that the speed of business won't allow anything less.
The answer, in short, is that the speed of business won't allow anything less. To keep doing things the old way (and by "old" I mean current) will not work in a world where everything else -- from servers to storage to the applications themselves -- is virtualized.
The other reason we should care about SDN today was put quite eloquently by Ferro during our talk. He suggested that if a CEO walked into a 100-person accounting department and saw 50 employees just sitting around, he would demand to know why they weren't working.
"But boss," the chief accountant might say, "those are our backup accountants in case the first 50 are unavailable. Pretty smart plan, huh?"
And that would be the end of the chief accountant's time at that company. Yet, don't we often do something very similar by having backup circuits all over the place? And, in a world where we already have redundant paths and multiple routes, backup circuits really are just money thrown into the /dev/null bit bucket.
Network monitoring and SDN monitoring have a symbiotic relationship
Enter network monitoring. How might today's network monitoring shape SDN? Perhaps even more important, how might SDN impact the network monitoring techniques of the future?
(Side note: I say "might" because SDN is still nascent. Standards, implementation options and vendors remain an amorphous mass of marketing hype, theory, vendor-specific flavors, dreams and specification revision.)
One of the main takeaways from my conversation with Ferro was that monitoring, by and large, is about listening -- waiting for event-type messages like traps and syslog, polling systems for values via SNMP and Windows management implementation, connecting to terminal sessions and scraping values off the screen or using vendor-provided APIs. Meanwhile, SDN is more about acting -- dynamically changing routes for all or some of the traffic, updating QoS statements and more.
It should be obvious that SDN relies on monitoring. Some of that will come from new features like NetCONF and YANG. But we in the IT industry, and especially in networking as a specific discipline, abhor abandoning the past -- particularly when it is functional, scalable and already understood. So, with all this in mind, you can hopefully sleep a little easier at night knowing nothing is really going away. Indeed, no SNMP object identifiers have been harmed in the making of this networking standard. Syslog will not be deprecated as a result. Traps are here to stay.
New protocols always add new twists
Will they be extended? Certainly. Will they be enhanced? Most definitely. But this is no different than the same way that every new protocol and even new hardware platforms add new twists. What is different here from, say, the introduction of NetFlow, is that SDN monitoring data will now be part of a feedback loop on the network: sense a change in data patterns, initiate a change; sense how that change alters data flow patterns, possibly initiate another change, and so on.
That's pretty powerful stuff.
What should you take from all of this? It's pretty simple. Despite today's hype and the fog of marketing, SDN is on its way and it's coming to a data center near you. It's a good thing (can I trademark that?) and it means networking and network monitoring is only going to get better from here.
