The cloud platforms are talking about being able to get better software control of networking with “overlay networks”. These overly networks use protocols like VXLAN, STT, NVGRE or NVO3 (and more to come, I’m sure) and run between the virtual switches.
But when you are designing and planning for overlay networks, you need to constantly refer to the features in the physical networks. The problem is that there are dozens of virtualisation features already used the physical network – things like MPLS, VLANs, Device Contexts, Switch Virtual Interfaces. This leads to some confusing names for thing. It quickly gets confusing as to what features are where – I’ve had discussions where “virtual physical” and “virtual virtual” were tried. That didn’t work.
So I’ve start using the term underlay network.
For example, the VXLAN overlay network needs to extensive IP and Ethernet multicast features enabled in the underlay network. While its possible for VMs to also use Multicast protocols in the overlay networks this may create performance problems in the underlay networks. tweet
Here is another example:
The VXLAN ID in the overlay network is hidden from the VLAN ID in the underlay network. The physical limits of the underlay network is a maximum of 4096 VLANs while VXLAN has up to 16 million identifiers (users a 24 bit tag). tweet
I’d be interested to hear of any solutions to the problems of referring to virtual features in the physical network when having discussions around the virtual features of the virtual network.
Got it ?