VXLAN Encapsulation in Juniper Contrail

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.

Not so fast – Contrail is using VXLAN packet format to carry MPLS labels between hypervisors and ToR switches.

Juniper Contrail is still a pure MPLS/VPN solution, using L3VPN 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 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.

Network Architect | CCIEx3 #29824 JNCIE #2197 VCIX-NV

Leave a Comment