Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Control-Plane Protocols for Overlay Virtual Networking – the Madness Continues

You might remember all the fuss about various encapsulations used in overlay virtual networking… just because one wouldn’t be good enough (according to Andrew Lerner “we provide users with choice” actually means “we can’t decide which product to offer you”).

Not surprisingly, with everyone converging on VXLAN (because that’s what the chip/device vendors decided to support), the madness has moved to the control plane.

There are at least four different protocols pushed by major networking or virtualization vendors that achieve a very simple task: downloading the IP-to-MAC-to-VTEP mapping into the hypervisor hosts in OpenStack/KVM environment:

  • OpenFlow, which isn’t good enough unless you implement non-standard extensions for multi-access tunnels, or combine it with OVSDB (VMware NSX, Nuage VSP, Open Daylight);
  • XMPP, because chatting between hypervisors makes perfect sense (Juniper Contrail);

On a more serious note, implementing the information transfer via a scalable and well-tested pub-sub protocol does make perfect sense.

  • OVN schema for OVSDB, because the people who wrote Open vSwitch realized how broken (oops, functionally incomplete) OpenFlow is;
  • OpFlex (details) because ACI.

Digging deep into the bowels of various versions of OVS Neutron plugins would reveal even more “interesting” approaches, like configuring OpenFlow flows through CLI commands.

Yeah, it makes perfect sense to fork an external program – hopefully through shell for improved overhead – for every flow that needs to be installed in OVS.

Ah, and then there are at least three ways to configure VXLAN gateways: OVSDB, EVPN/NETCONF and OpFlex.

Obviously it would be totally impossible to use the same protocols in proprietary solutions, so Hyper-V uses PowerShell commandlets, and VMware NSX uses whatever (documented approximately as well as all other VMware internal protocols and APIs).

I understand that each one of these protocols offers some functionality that’s not present in any other protocol. I also understand the need to experiment with various solutions, but I’m not willing to be the spaghetti wall (yet again), and I’m not alone – until this morass is sorted out, a lot of people won’t even touch it.

No comments: