VXLAN is Now RFC 7348

In the last August, the Internet Engineering Task Force (IETF) galvanized the work of roughly 3 years in a Request for Comments (RFC) document. Although it can be considered a young virtualization technology, Virtual eXtensible Local Area Networks (VXLANs) are already molding how Cloud networks function and are quickly becoming a fundamental building block of Software-Defined Networking (SDN).

As per the book (“Data Center Virtualization Fundamentals”), VXLANs were at first invented to provide Layer 2 communication between Virtual Machines (VMs) over IP networks. Nevertheless, its flexibility can be used to implement specialized data center fabrics such as Cisco Application Centric Infrastructure (ACI).

The document was written by employees from Cisco Systems, Storvisor, Cumulus Networks, Arista, Broadcom, VMware, Intel and Red Hat and can be downloaded here: https://datatracker.ietf.org/doc/rfc7348/?include_text=1

Here are some of its highlights:

• The RFC has achieved informational status, meaning that it should not be considered a mandatory standard but simply the publishing of an experience. IETF´s motto in these cases is “rather document than ignore” according to RFC 1796 (“Not All RFCs are Standards”), which funnily is also informational.
• According to the RFC, VXLAN overcomes the following challenges: STP limitations, VLAN range size, multi-tenant environments in cloud computing environments, and inadequate table sizes at Top-of-Rack switches.
• The document focuses on data plane learning scheme as control plane for VXLAN, meaning that the association of MAC to VTEP´s IP address is discovered via source MAC address learning.
• Multicast is used of carrying unknown destination, broadcast, and multicast frames. VTEPs use (*,G) joins for that objective.
• The RFC does not discard that other control plane options for MAC/VTEP learning may exist, such as Nexus 1000V´s Enhanced VXLAN.
• To ensure traffic delivery without fragmentation, it is recommended that the MTUs across the physical network are set to a value that accommodates the larger frame size due to the VXLAN encapsulation.
• The Internet Assigned number Authority (IANA) assigned the value of 4789 for the VXLAN´s destination UDP port. It is recommended that the source port is calculated using a hash of the inner Ethernet frame´s headers to leverage entropy on networks that deploy traffic load-balancing methods such as ECMP. Also, the UDP source port range should be within the dynamic/private port range of 49152-65535).
• VXLAN gateways are defined as elements that can forward traffic between VXLAN and non-VXLAN environments.

Even under information status, the publishing of VXLAN as a RFC will surely help the convergence of distinct vendor research and development. These are exciting news indeed for network engineers, server virtualization admins, and cloud architects.