Category: SDN

The edited videos from VMware NSX Architecture webinar are published on my demo content web site and on YouTube. Enjoy!

One of the holy grails of data center SDN evangelists is controller-driven traffic engineering (throwing more leaf-and-spine bandwidth at the problem might be cheaper, but definitely not sexier). Obviously they don’t call it traffic engineering as they don’t want to scare their audience with MPLS TE nightmares, but the idea is the same.

Interestingly, you don’t need new technologies to get as close to that holy grail as you wish; Petr Lapukhov got there with a 20 year old technology – BGP.

Tassos opened an interesting can of worms in a comment to my Management, Control and Data Planes post: Is ICMP response to a forwarded packet (TTL exceeded, fragmentation needed or destination unreachable) a control- or data-plane activity?

My keynote speech @ PLNOG11 conference was focused on (surprise, surprise) overlay virtual networks and described the usual motley crew: The Annoying Problem, The Hated VLAN, The Overlay Unicorn, The Control-Plane Wisdom and The Ever-Skeptic Use Case. You can view the presentation on my web site; PLNOG organizers promised video recording in mid-October.

Just in case you’re wondering why I keep coming back to PLNOG: they’re not only as good as ever; they’re getting even more creative.

Fast advances in networking technologies (and the pixie dust sprinkled on them) blinded us – we lost our gut feeling and rule-of-thumb. Guess what, contrary to what we love to believe, networking isn’t unique. Physicists faced the same challenge for a long time; one of them was so good that they named the whole problem category after him.

Every time someone tries to tell you what your problem is, and how their wonderful new gizmo will solve it, it’s time for another Fermi estimate.

Plexxi has an interesting problem. They have a shiny new solution that requires unorthodox approaches to network forwarding and allows them to implement potentially cool concepts like affinities (traffic engineering in disguise). They also need to sell these new concepts to the customers, and the first question I would ask after recovering from a hefty dose of cool-aid is "and how do I configure these affinities?"

The primary benefit of SDN (as claimed by its promoters) is a geek’s dream: the ability to program the network (or, more precisely, control network’s behavior through programmable tools).

Sounds great – we’ll finally be able to fix that pesky detail the vendor never wanted to implement (probably for a good reason). But should we REALLY do that?

When talking about OpenFlow and the whole idea of controller-based networking, people usually say “well, it’s nothing radically new, we’ve been using wireless controllers for years and they work well, so the OpenFlow ones will work as well.”

Unfortunately, the comparison is totally misleading.

Plexxi has an incredibly creative data center fabric solution: they paired data center switching with CWDM optics, programmable ROADMs and controller-based traffic engineering to get something that looks almost like distributed switched version of FDDI (or Token Ring for the FCoTR fans). Not surprisingly, the tools we use to build traditional networks don’t work well with their architecture.

In a recent blog post Marten Terpstra hinted at shortcomings of Shortest Path First (SPF) approach used by every single modern routing algorithm. Let’s take a closer look at why Plexxi’s engineers couldn’t use SPF.

In the previous posts I described how a typical overlay virtual networking data plane works and what technologies vendors use to implement the associated control plane that maps VM MAC addresses to transport IP addresses. Now let’s walk through the details of a particular implementation: Nicira Network Virtualization Platform (NVP), part of VMware NSX.