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

Après moi, le déluge

Normally, the way a switch finds out where devices on the network are located is by "flooding". This is a packet sent to every port on every switch on the network. (Network nerds: put VLANs to one side for a later discussion, please).

If the device addressed in the flood is connected to the network it will respond, and the switch (and all intermediate switches) will know how to send packets to get them from A to B.

The problem is that if packets are supposed to be forwarded throughout the entire network, you can't have two cables connecting switches. If you do this, you get a loop. Looking at the fully connected network map, if Switch 1 were to emit a packet towards Switch 3, that packet will then be forwarded from Switch 3 to Switch 2 and then back on to Switch 1. This would get sent to Switch 3 again, which would get forwarded to Switch 2 – and we have our loop.

To counter this, technologies such as Spanning Tree Protocol (STP) were developed to detect loops and shut off redundant links. In theory, good STP implementations would detect when a link that causes a loop is down and bring up the redundant link so that packets will keep flowing. In practice, STP never quite seems to work as advertised.

And here we're at the heart of it. STP has been around for more than 15 years and it has been broken since before it was standardised. Networking engineers have been talking about alternatives to STP since before STP was formalised as a standard.

Alternatives to STP include Shortest Path Bridging (SPB) and Transparent Interconnect of Lots of Links (TRILL). There are also proprietary approaches and approaches involving making everything Layer 3 and cranking up the dollar value of all the bits involved. There are no clear winners yet, and with SDN we're already on to the next chapter before the saga is even finished.

For additional fun, after you sort out the physical connectivity between switch issues, you need switches to be able to exchange information about VLANs. Here we could go down rabbit holes like GARP, MRP, VTP, etc. and start holy wars in the comments.

A human has no trouble looking at the network map and saying "when the link between Switch 1 and Switch 3 is down, then to get to Switch 3 go via Switch 2". The switches, on the other hand, can get all manner of confused – and this diagram only has four switches.

Kicking complexity up a notch

To make modern networking more frightening, in addition to switches having some difficulty keeping who's who and what's where straight, those irritating server admins have virtualisation technology. Now they can move workloads from one server to another at will.

A VM that was on port 15 on Switch 3 can suddenly appear on port 2 on Switch 4. Not only is the server team not going to file a change request with networking before moving VMs around, there are automated systems built right into the hypervisor that move VMs around based on server load. There is no chance whatsoever that network admins can manually configure the interconnects between switches in a modern environment.

Some of the successor protocols to STP can be used to do this in an automated fashion. Unfortunately, they aren't all evenly supported across switch vendors. Worse, the various major vendors have picked their sides and spread pointless FUD about "the enemy's protocols". And you still then have to configure each switch to play nice with the protocol and so on and so forth*.

Cisco, Juniper, Hewlett Packard, Dell, Arista and any of the other big switch manufacturers can solve this problem for you. If you would kindly pay them the sum of exactly enough to make you say "uncle", they can make all of this go away.

Oh, you'll still have to do an awful lot of configuring, but they have handy certification courses and management tools that make it just easy enough that companies which already use their solutions won't look elsewhere.

SDN takes a different approach. In an SDN world, you register a switch with the control plane in a manner not fundamentally different from connecting an ESXi host to vSphere, or back-up agent to the back-up server. Once registered, the switch is instructed to discover all of the devices connected to it and report back. The control servers then calculate the new topology of the network and update every device with the new information.

If a link drops, this is detected and reported to the central servers. The central servers calculate the new topology and distribute it to all devices. Did you add a cable between two switches or move a VM? Recalculate and distribute.

Forget complicated protocols and configuration. Building the "index" of who's who and what's where is done centrally and pushed out to all devices with each change. Detecting, calculating and distributing this information is called reconvergence. Even though SDN does it in a different way to older protocols, the goal and the result are (mostly) the same.

Next page: NFV on top of SDN

More about

More about

More about


Send us news

Other stories you might like