10 January 2017

Network Virtualization with VXLAN and Linux

VXLAN stands for “Virtual eXtensible Local Area Network”. Standardized in RFC 7348 in August 2014, VXLAN is also available today as a virtual network interface in current Linux kernels. But what is VXLAN?

What is VXLAN?

When one reads the keywords “Virtual” and “LAN”, most rightly think of VLAN. Here, a large physical network is logically divided into smaller networks. For this purpose, the corresponding connections are marked with VLAN tags. This can be done either at the sending host (tagged VLAN) or, for example, by the switch (port-based VLAN). These markings are already made at Layer 2, the Data Link Layer in the OSI model. This allows them to be effectively evaluated at a very low network level, thereby suppressing unwanted communication in the network. The IEEE 802.1Q standard defines a 12-bit width for the VLAN tag, thus fundamentally resulting in 4096 possible VLAN networks on an Ethernet installation.

VXLAN was developed to circumvent this limitation. With VXLAN, a transmission technology based on OSI Layer 3 or Layer 4 is introduced, which creates virtual Layer 2 environments. With VXLAN logic, approximately 16 million (2 to the power of 24) VXLAN Layer 2 networks are possible, which in turn can map 4096 VLAN network segments. This should initially be sufficient even for very large Ethernet installations.

How can one set up such a VXLAN?

A VXLAN interface can then be set up, for example, with

ip link add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0

available. This command creates the device “vxlan0” as a VXLAN with ID 42 on the physical interface “eth0”. Multiple VXLANs are distinguished based on their ID. The instruction “group ” sets the transmission to multicast and defines the associated multicast group. Alternatively, an IP of the target host could also be provided here using the “remote” command, based on the underlying network (eth0) (unicast operation). Further instructions can also be used to define the source and destination ports for the underlying IP network on “eth0”. The IANA standard is UDP port 4789.

Using the command line

ip addr add 10.0.0.1/24 dev vxlan0

one assigns a fixed IP address to the newly created VXLAN network interface, here in the example 10.0.0.1

The command

ip link set up dev vxlan0

activates the newly created network interface “vxlan0”. This creates a virtual network based on IP multicast on the physical interface “eth0”.

The interface “vxlan0” now behaves in principle exactly like an Ethernet interface. All other computers that select VXLAN ID 42 and multicast group 239.1.1.1 will thus become part of this virtual Ethernet. On this, one could now again set up various VLANs, for example, with

ip link add link vxlan0 name vlan1 type vlan id 1

set up a new VLAN on the VXLAN interface. In this case, one would not need to assign an IP address to the VXLAN interface.

What are its practical applications?

Fundamentally, VXLAN is suitable for use cases in very large Ethernets, such as in cloud environments, to overcome the 4096 VLAN limit.

Use as a Test Environment for Network Services

Alternatively, VXLAN can be very effectively used in test environments or virtualized environments where full control over the Layer 2 network to be used is required. If one wishes to test network infrastructure components or their configuration, such a completely isolated network is ideal. This also allows one to bypass control structures introduced by virtualization environments, which are particularly obstructive for such tests. My first practical experience with VXLAN was during the testing of a more complex DHCP setup on several virtual machines in OpenStack. On the network interfaces provided by OpenStack, the test was impossible for me, as I had only limited access to the network configurations on the virtualization host side, and OpenStack filters out DHCP packets from the network stream. This problem could be elegantly circumvented by setting up the test network on VXLAN. At the same time, this ensured that the DHCP test had no impact on other parts of the OpenStack network. Furthermore, the Ethernet connection provided by OpenStack remained permanently usable for maintenance and monitoring purposes.

For example, in unicast operation, scenarios are also conceivable where a Layer 2 network spanned over VXLAN is transported across multiple locations. There are switches or routers that support VXLAN and can serve as VTEPs (VXLAN Tunnel Endpoints). These can be used, for example, to connect two multicast VXLAN networks via unicast between the VTEPs, thereby transparently spanning a large VXLAN.

Is VXLAN secure?

VXLAN adds another Layer 2 infrastructure on top of an existing Ethernet infrastructure. This operates with UDP packets in unicast or multicast. Encryption at the VXLAN level is not provided and would need to be handled by higher protocol layers if required. IPSec solutions or, for example, TLS are options here. Fundamentally, VXLAN is at a comparable security level to most other Layer 2 network protocols.

Possible Issues?

With VXLAN, users may encounter a “familiar acquaintance” in the form of MTU issues. A standard Ethernet frame has a length of 1,518 bytes. After deducting the Ethernet header, 1,500 bytes remain for payload. VXLAN extends the Ethernet header by 50 bytes, which reduces the available payload to 1,450 bytes. This should be considered when setting the MTU. So-called Jumbo Frames are affected accordingly. Here, the additional 50 bytes must also be taken into account.

What does credativ offer?

We are pleased to support and advise you on the design and operation of your network environment. Among other things, we work in the areas of DevOps, network infrastructure, and network design. credativ GmbH has employees with expertise in highly complex network setups for data centers on real hardware as well as in virtual environments. Our focus is on implementation with open-source software.

Categories: HowTos
Tags: Virtualization

PD

About the author

Peter Dreuw

Head of Sales & Marketing

about the person

Peter Dreuw arbeitet seit 2016 für die credativ GmbH und ist seit 2017 Teamleiter. Seit 2021 ist er Teil des Management-Teams als VP Services der Instaclustr. Mit der Übernahme durch die NetApp wurde seine neue Rolle "Senior Manager Open Source Professional Services". Im Rahmen der Ausgründung wurde er Mitglied der Geschäftsleitung als Prokurist. Sein Aufgabenfeld ist die Leitung des Vertriebs und des Marketings. Er ist Linux-Nutzer der ersten Stunden und betreibt Linux-Systeme seit Kernel 0.97. Trotz umfangreicher Erfahrung im operativen Bereich ist er leidenschaftlicher Softwareentwickler und kennt sich auch mit hardwarenahen Systemen gut aus.

View posts


Beitrag teilen: