This article is more than 1 year old

SDN's dream: Use what you've got, not what you're promised

Hardware acceleration – busted

Opendaylight lacking support

Q: Are there standards?

For now. Openflow is the standard for allowing SDN controller software to control a switch, regardless of whether that switch is physical or virtual. OpenvSwitch is a critical project that has become a standard reference implementation of a server-spanning vSwitch.

Opendaylight was a standard and at one point had broad industry support. Then Opendaylight started producing working code and looked like it was going to actually work. As soon as it became more than a PR exercise the big names promptly wet themselves in terror and all their shiny new stuff stopped interoperating with Opendaylight.

Hmmm. I wonder why.

Q: Are we growing in the dark?

Not at all! Everyone involved in SDN is perfectly aware of what they – and everyone else – is doing. They are all trying to kill each other off via lock-in and monopoly with extreme prejudice and the bloodbath that is about to occur in the networking sector will make the whole software defined storage wars seems like a Care Bears picnic by comparison.

At this point, SDN and NFV – though in their infancy – have been around for long enough that any seeming chaos in the industry is anything but. It is coldly calculated backstabbing, betrayal, politics, threats, partnerships, and blackmail.

Everyone is jockeying for position and the name of the game is to create optics that say you're open, friendly and supportive of your customers' business needs while quietly working to kill off anyone that threatens your lock-in. Even the new players in the market are playing by this rulebook.

Q: What are the particular requirements

For SDN you need an SDN controller, a switch that is compatible with that controller. Cisco, Juniper and others will gladly sell you such things.

For those interested in the "open" side of SDN this usually means Openflow based switches and Opendaylight as your SDN controller. In practice, SDN usually means Cumulus or Pica8-based switches, but there are plenty of other switches that support Openflow.

Q: How do service and performance levels change? Isn't hardware is always faster than a software-based thing?

Cisco – and every other proprietary networking vendor on the planet – would really like you to know that the best networking is clearly done in hardware. Their hardware. Preferably managed by their software. To be perfectly clear: with the exception of some fringe workloads that push even the best of the best to the redline, this whole "better in hardware" thing is rubbish.

NFV works just fine when provided by VMs. It even works fine at ridiculously high network throughput. We could argue latency, but the beauty of NFV is that you can try before you buy. Of course, if you try, you'll probably spend a lot less when you buy, so if you like your switch vendor don't give these newfangled things a try, hmm?

My first introduction to SDN was an early Juniper Contrail setup working in tandem with Puppet and Openstack. Push one button and you had database servers on two sites, set up for replication, with multiple layers of application servers, front-end web servers, load balancers, firewalls, security layers, access control lists, and WAN optimisation all spawned and ready in under 30 seconds.

You could move any element around the network, across sites — it didn't matter, the networking Just Worked. It was impressive.

I have since seen this reproduced on Dell switches running Cumulus Networks' switch operating system, married to Opendaylight's SDN controller connected to Openstack Neutron. The "open" demo included backups, DR and monitoring pre-configured as part of the service spawn.

SDN and NFV are important parts of my Software Defined Infrastructure concept. Indeed, what's on the table today can get us quite close.

An all-hardware approach may be theoretically more efficient than all these layers of abstraction, but that efficiency doesn't really matter all that much when we simply don't use the full processing power or capabilities of our switches, routers, servers and other data centre equipment as it is.

I argue – and apparently a whole lot of people with money agree – that a few percentage points of efficiency is a small price to pay for the level of automation and ease of use SDN and NFV enable. ®

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like