Software Defined Networking (SDN) and Network Functions Virtualisation (NFV) are the future – and if you aren't already learning about them you're probably already doomed. If that strikes you as a little pessimistic then there is a bright side: most of us are already doing some of it and we all understand more about it than we think.
SDN is the ability to rapidly detect and adapt to changes in network infrastructure. This can be, say, the addition of devices or changes in topology.
NFV is the ability to stand up, tear down, automate and orchestrate network elements in some easy-to-use manner. Network elements can include switches, routers, firewalls, Intrusion Detection Systems (IDS), monitoring, port mirroring and even entire clusters of virtual or physical server instances.
NFV is frequently lumped in with SDN, as both technologies are highly complimentary. It is possible to do NFV without SDN (see: Webmin's virtual twin here). It is also entirely possible to implement SDN without layering NFV over the top.
None of this is new. The "wow" factor to SDN is that instead of having to log into each switch or router one at a time (via scripts, GUI or command line), your entire network is orchestrated by some centralised management server.
Let's consider a few practical examples.
SDN networking gear
The most colour-by-numbers type of hype-compliant SDN today involves switches that "separate the control plane from the data plane". Translated into human, this means people are finally making centralised management for switches so we don't have to log in via telnet or SSH to every switch on our network.
In practice, SDN means buying inexpensive switches where the hardware manufacturers don't make a lot of margin and installing expensive software on it. This is quite a change from the old practice of expensive hardware and terrible (or no) software.
The expensive software portion of the SDN equation allows switch configurations to be monitored in real time. When an event occurs (maybe a dead port, cable out, or switch down) the centralised control server or servers detect the issue and automatically change relevant network configurations to keep as many of the network services running as possible.
Consider for a moment a simple network with four switches. Each switch has a connection to two other switches. Two of the switches connect to the router that goes out to the internet. Cut any one connection between the switches and they would still be able to see other switches.
Basic 4 switch setup with a failed link between switches 1 and 3
Sadly, it's never that simple.
Let's say that the cable between Switch 1 and Switch 3 occupies port 4 on both switches. Every time Switch 1 is asked to find devices that are attached to Switch 3, it will fire those packets out of port 4, because that's what Switch 1's map of the network looks like.
If I cut the wire between Switch 1 and Switch 3, several things need to happen for Switch 1 to continue being able to send packets to devices located on Switch 3. The first: Switch 1 needs to know that the cable has been cut. This one's easy; even the dumbest of dumb switches knows when the cable's out.
Knowing that the cable is out, Switch 1 should now be able to understand that all those addresses it thought were available via port 4 now suddenly can't be reached there. This is where things get complicated.
Looking at the network map, we can all clearly see that to get from Switch 1 to Switch 3, packets need to be sent to Switch 2. Switch 1 is connected to Switch 2, which is in turn connected to Switch 3. For a switch, this isn't so easy to understand.