VXLAN is becoming de-facto encapsulation standard for overlay virtual networks (at least according to industry pundits and marketing gurus working for companies with VXLAN-based products) – even Juniper Contrail, which was traditionally a pure MPLS/VPN architecture uses it.
Juniper Contrail is still a pure MPLS/VPN solution, using L3VPN (RFC 4364) for routed traffic and EVPN for bridged traffic. Every packet forwarded between Contrail end nodes (hypervisors and/or PE-routers) has an MPLS label.
Contrail can use various encapsulation mechanisms to carry labeled customer traffic across the underlying IP transport network (they decided to use IP-based transport fabric instead of MPLS-based transport fabric):
- MPLS-over-GRE – the traditional encapsulation mechanism supported by several router vendors, including Cisco and Juniper;
- MPLS-over-UDP – a variation of MPLS-over-GRE that replaces GRE header with UDP header. A hash of the payload (entropy) is stored in the source UDP port to enhance ECMP load balancing across the underlying IP fabric;
- MPLS-over-VXLAN, which uses VXLAN packet format but stores MPLS label in the VNI (Virtual Network Identifier) field.
In all three cases, the traffic within the current Contrail implementation never uses more than a single MPLS label (VPN label). The LDP or MPLS TE label is not needed due to end-to-end IP transport, and multi-label MPLS/VPN architectures (Carrier’s Carrier) aren’t supported.
Why would you need VXLAN?
By now you should be thoroughly confused and asking “why would anyone want to bastardize VXLAN to make it work like MPLS label stack?”
The answer is very simple: imagine you have a hardware platform with third-party merchant silicon that supports VXLAN encapsulation but not MPLS-over-GRE encapsulation (or that supports VXLAN encapsulation way better than MPLS labels).
The only reasonable way forward is to use the encapsulation supported by hardware platform (VXLAN) and adjust the meaning of the VNI to whatever your control plane needs are. Does that make sense? It probably does to the engineers trying to squeeze out the last drops of performance from the chipset – but I wouldn’t want to be the one trying to troubleshoot the whole thing.
Looking for a bigger picture?
I briefly covered Contrail and Nuage VSP in the Following Packets across Overlay Virtual Networks part of the Overlay Virtual Networking webinar. For additional virtual networking and cloud networking architecture webinars, check out the cloud networking resources on ipSpace.net.