Let me tell you a story.
Over the past six months, I've been doing my own little data collection project. Whenever I get together with a group of IT professionals, I ask them three questions:
1) How many of you are thinking about software-defined networking (SDN) as part of your infrastructure?
2) How many of you are testing some type of SDN deployment in a lab or sandbox environment?
3) How many of you are running it in production?
In every case, the results are almost the same:
1) Almost everyone is thinking about SDN
2) About 50% of every group is testing it
3) Zero are using an SDN infrastructure in production
Pause for a moment and consider that last line -- zero, nobody.
The reason isn't hard to fathom. SDN isn't just an expensive proposition, it's complex. Even if the benefits were simple to quantify for any particular organization, and they're not, it's still a technology that many IT professionals have a hard time wrapping their heads around. But failing to embrace SDN and network configuration management tools may leave organizations unprepared for the future.
A brief SDN primer
As I described previously, at its core, SDN is the ability for the network to detect changes in data flow and be able to reconfigure itself. In other words, the path data takes through a network is managed by a software-based control plane, which communicates to all devices on the network to spontaneously change elements like best path, quality of service (QoS) and permitted data types.
In addition to the obvious efficiency benefits, SDN is important because, quite frankly, the increasing speed of business won't allow network administrators to continue managing networks with current strategies -- while changes to production networks are done at least semi-manually and are fraught with risk from both mistakes and misunderstandings. The old approach simply will no longer be effective in a world where everything else from servers, to storage, to the applications themselves, is virtualized.
Enter network configuration management tools
What I've also discovered over the past six months is that almost everyone would like to implement something like SDN if they could do it in a way that wasn't so overwhelming.
Enter network configuration management (NCM) tools.
The concepts and techniques behind NCM are pretty straightforward and well-understood:
- Connect to your network devices.
- Pull down the current configuration using File Transfer Protocol, Trivial File Transfer Protocol, screen scraping, a vendor application program interface or other technique.
Once this is done, you can:
- Compare the current configuration to the previous -- or a baseline.
- Scan the configuration for violations against a set policy -- i.e., HIPPA, SOX, DSA STIG, etc.
- React to those problems by creating an alert, pushing back a default configuration, configuring other devices to quarantine the offending system, or some other response.
For anyone who's used network configuration management tools, this is old hat. If you aren't used to using an NCM product, though, run, do not walk, run. You really, really have been missing out.
How does this relate to SDN? Well, after a recent conversation with network guru Destiny Bertucci, it struck me that NCM is SDN on a smaller scale. And after pulling fellow SolarWinds head geek Patrick Hubbard into the conversation, all three of us agreed that NCM is in fact pragmatic SDN. Not only that, but it's SDN that is using tools that already exist, are well-understood and are probably already in your toolbox.
Consider the following scenario: On your network, you're probably already monitoring for bandwidth utilization, NetFlow and maybe even real-time packet inspection -- once again, if you aren't, time to get with the times, buddy! You therefore are able to notice that network utilization on a particular interface has spiked and that the majority of the usage is using the Lync-Skype protocol. Instead of just configuring an alert, you could just as easily push a config change to that box with a QoS template that prioritizes voice traffic on that circuit or maybe even routes that traffic to a separate, dedicated interface on the same box. Equally, if you set up an alert to detect low levels of voice traffic, you can push a different config that removes the QoS settings.
Now that’s just one option. Another is focused on both security and making large networks easier to manage.
Most network architects will tell you that one of the best uses for network configuration management tools, such as VLAN0, is to put unconfigured or misconfigured devices into no man's land. Now imagine that this VLAN0 no man's land is scanned frequently for new arrivals. Finding one triggers an alert action that runs a script that attempts to connect to the device using default information. Failure to connect creates a ticket for a human to intervene. But in cases when the connection attempt succeeds, a basic configuration will be pushed to the device, which adds changes to the infrastructure to allow that device on the production network. Follow-up actions would then place this new device under monitoring, possibly with a higher frequency for the first week as the device settles in.
Very little manual intervention is needed -- besides racking and stacking -- and correct configuration is virtually guaranteed.
And they all lived happily after
Where does this leave us? In short, while the time for SDN implementation could be months or years off, we IT professionals can start to test SDN ideas and concepts now without any additional investment in hardware or training in new programming languages -- as I've said, network configuration management tools should already be an existing part of almost any sized network.
It gives us a chance to see what works, what's still not feasible, and perhaps most importantly, reveals the true value of SDN.
Automated network configuration to prevent errors
Configuration for SDN deployment
Network configuration for the cloud