This article is more than 1 year old

Software-defined freedom: A liberating experience for YOU

Breaking through the hardware barricades to a new network state

NFV on top of SDN

Consider for a moment that in a "cloud" environment, nobody cares about the switches. Nobody wants to know if the link between a switch is down and there is zero tolerance for any downtime required to fix it.

None of this matters to the end users, to the server admins, the storage admins or anyone else who has to actually use the network. It's all impediment and distraction. In fact, in addition to not caring about how packets get from A to B, they want to push all sorts of things off on to "the network" for automation.

Firewalls, intrusion detection and so much more were often part of network oversight. Traditionally these functions were performed by routers, Layer 3 switches or network appliances.

Increasingly these functions are simply spun up on demand as VMs. Getting this right requires complicated network flows operating in an automated fashion that no human-mediated change-control system could ever hope to cope with.

Spawning a "virtual service" in your corporate private cloud will not only light up a series of VMs handing an application, database, storage and analytics. It will also fire up network security VMs, trigger the creation of access control lists, add things to back-up and disaster recovery regimens and more.

All this will need to be added to monitoring packages and all of it has to happen at the push of a button.

The point of SDN is not merely to replace some protocols for network reconvergence with yet another way of doing the same thing. That's a critical part, but it is only the most basic building block. SDN's entire purpose is to plug into advanced infrastructure management stacks to combine the low-level networking stuff with the high-level stuff, so that all of what has been discussed here is seamless.

SDN blurs into NFV. NFV at scale needs SDN, because of the sheer number and speed of changes. SDN at scale need NFV because simply automating reconvergence isn't enough. All those network functions that used to be in hardware need to be put into VMs and automated away in software.

Once upon a time, the internet was mostly computers with humans using them, talking to other computers with other humans using them. Today, the internet is mostly computers talking to other computers without humans involved. Those computers are the new user, and they need services to be created and destroyed faster than we puny fleshies can react.

Fortunately, most of us are doing at least some of the above already. Now we just need to get better at automating it. Welcome to SDN, NFV and the future. ®


*Chris Whal points out the following: "this shouldn't impact STP as the edge ports connected to hypervisors should have STP disabled. And the hypervisor will use RARPs to flood source MACs upstream for quick address learning if a link fails. And in NSX, for example, ARPs and other BUM traffic are absorbed by the VTEP and responded to in-line."

He has a point; properly configured, your hypervisor-facing points should have STP disabled, and NSX does handle flooding back to the switches rather nicely. Of course, NSX is proper SDN and thus is handling some of the problems of today's networks on its own.

NSX is perfectly capable of handling flooding issues even on switches that aren't configured correctly, or which have a binary "enabled on all ports/disabled on all ports" option for STP. This reinforces the point: the days of the edge device trusting the network entirely are over. Edge devices like hypervisors are full participants in the network.

More about

More about

More about


Send us news

Other stories you might like