Category: Overlay Networks

TL&DR Summary: It depends on your business model

With the explosion of overlay virtual networking solutions (with every single reasonably-serious vendor having at least one) one might get the feeling that it doesn't make sense to build greenfield IaaS cloud networks with VLANs. As usual, there's significant difference between theory and practice.

You should always consider the business requirements before launching on a technology crusade. IaaS networking solutions are no exception.

2013 was definitely the year of overlay virtual networks, with every major networking and virtualization vendor launching a new product or adding significant functionality to an existing one. Here’s a brief overview of what they’re currently offering:

After my Clouds, Overlays and SDN: What really matters keynote presentation @ MENOG 12 a few attendees asked me for a recording; one of them said “I want everyone in my organization to watch it.” Alas, wishes don’t always come true: the video team was streaming the presentations, but not recording them.

Fortunately I had the same presentation @ PLNOG 11 and like always the PLNOG organizers did a marvelous job. The video has just been posted on YouTube. Enjoy!

Got a really interesting question from A. Reader: “When and how does VXLAN use IGMP and PIM in transport (underlay) networks?”

Obviously you need IGMP and PIM in multicast environments only (vCNS 5.x, Nexus 1000V in multicast mode).

Packet forwarding behavior of VMware NSX and Hyper-V Network Virtualization is well documented; no such documentation exists for Amazon VPC. However, even though Amazon uses a proprietary solution (heavily modified Xen hypervisor with homemade virtual switch), it’s pretty easy to figure out the basics from the observed network behavior and extensive user documentation.

Gateways between overlay virtual world and (VLAN-based) physical reality are a crucial component in every design using overlay virtual networks. Ideally one could use virtual appliances, but sometimes the users keep asking for layer-2 gateways.

The VMware NSX Layer-2 Gateways video from the VMware NSX Architecture webinar describes the use cases for layer-2 gateways and the VMware NSX implementations.

Initial release of Hyper-V Network Virtualization (HNV) was an add-on to the Hyper-V Extensible Switch, resulting in an interesting mixture of bridging and routing. In Windows Server 2012 R2 the two components became tightly integrated, resulting in a pure layer-3 solution.

Every time I talk about small (per-application) virtual appliances, someone inevitably cries “And who will manage thousands of appliances?” Guess what – I’ve heard similar cries from the mainframe engineers when we started introducing Windows and Unix servers. In the meantime, some sysadmins manage more than 10.000 servers, and we’re still discussing the “benefits” of humongous monolithic firewalls.

Last week I explained how layer-2 and layer-3 packet forwarding works in VMware NSX – a solution that closely emulates traditional L2 and L3 networks. Hyper-V Network Virtualization (HNV) is different – it’s almost a layer-3-only solution with only a few ties to layer-2.

The easiest way of connecting overlay virtual networks implemented with VMware NSX for vSphere to the outside world is NSX Edge Services Router. It’s a much improved version of vShield Edge and provides way more than just layer-3 forwarding services – it’s also a firewall, load balancer, DHCP server, DNS forwarder, NAT and VPN termination device.