Understanding Linux Virtual Interfaces: Tunnels

Linux supports many types of tunnels. This confuses newbies who find it difficult to understand the differences in technology, and understand which tunnel is best to use in a specific situation. In the material, the translation of which we are publishing today, we will give a brief overview of the frequently used tunnel interfaces of the Linux kernel. We will not go deep into this topic, having considered only the general features of tunnels and options for their use in Linux.



The author of this material believes that what will be discussed here may be of interest to anyone who has something to do with the management of computer networks. A list of tunnel interfaces, as well as reference information about a specific configuration, can be obtained using the iproute2 ip link help command.
')
The following commonly used interfaces will be discussed here: IPIP, SIT, ip6tnl, VTI and VTI6, GRE and GRETAP, GRE6 and GRE6TAP, FOU, GUE, GENEVE, ERSPAN and IP6ERSPAN.

After reading this article, you will learn about the features of these interfaces and find out the differences between them. You will learn how to create them and learn about the situations in which they are best used.

IPIP

An IPIP tunnel, as its name suggests, is a tunnel operating in IP over IP mode ( RFC 2003 ). The IPIP tunnel packet header is as shown below.


IPIP Tunnel Packet Header

Such tunnels are commonly used to connect two internal IPv4 subnets over a public IPv4 network (Internet). The use of IPIP creates a minimal additional load on the system, but only unidirectional data transmission (unicast) can be performed through such a tunnel. That is, having built a similar tunnel, it will not be possible to use it for multicast data transmission (multicast).

IPIP tunnels support IP over IP and MPLS over IP modes.

Note that when the ipip module is loaded, or when an IPIP device is first created, the Linux kernel will create a tunl0 with the attributes local=any and remote=any in each namespace. Receiving IPIP packets, the kernel, in certain cases, will redirect them to tunl0 as the device used by default. This happens when the kernel cannot find another device whose local/remote attributes more closely match the source and destination addresses of the packets.

Here's how to create an IPIP tunnel:

On server A:

 # ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR # ip link set ipip0 up # ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0 Add a remote internal subnet route if the endpoints don't belong to the same subnet # ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0 

On server B:

 # ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR # ip link set ipip0 up # ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0 # ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0 

Note that when using this configuration, it must be aligned with real data. In particular, LOCAL_IPv4_ADDR , REMOTE_IPv4_ADDR , INTERNAL_IPV4_ADDR and REMOTE_INTERNAL_SUBNET need to be replaced with addresses used in your environment. The same is true for other examples of configurations, which we will consider further.

Sit

SIT (Simple Internet Transition) is a technology for creating tunnels, the main purpose of which is to connect isolated IPv6 networks via the Internet using the IPv4 protocol.

Initially, SIT technology could work only in the “IPv6 over IPv4” tunneling mode. However, over the years of development, it has gained the support of several more regimes. In particular, this is ipip (it was the same with the IPIP tunnel), ip6ip , mplsip and any .

The any mode is used to work with IP and IPv6 traffic, which can be useful in some situations. SIT tunnels also support ISATAP . Here is an example of using this technology.

The header of the SIT packet is as shown below.


SIT Tunnel Packet Header

When the sit module loads, the Linux kernel creates the default sit0 .

Here's how to create an SIT tunnel (these steps must be performed on servers A and B):

 # ip link add name sit1 type sit local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR mode any # ip link set sit1 up # ip addr add INTERNAL_IPV4_ADDR/24 dev sit1 

Ip6tnl

The ip6tnl interface works in IPv4 / IPv6 over IPv6 mode. It is similar to the IPv6 version of the SIT tunnel. This is what the ip6tnl header looks like.


Ip6tnl tunnel packet header

Ip6tnl tunnels support ip6ip6 , ipip6 and any modes. The ipip6 mode ipip6 represented by the “IPv4 over IPv6” scheme, the ip6ip6 mode is “IPv6 over IPv6”. The any mode supports both schemes.

When the ip6tnl module is ip6tnl , the Linux kernel creates a default device named ip6tnl0 .

Here's how to create an ip6tnl tunnel:

 # ip link add name ipip6 type ip6tnl local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR mode any 

VTI and VTI6

The Virtual Tunnel Interface (VTI) interface in Linux is similar to the Cisco VTI interface and the Juniper implementation of a secure tunnel (st.xx).

This tunneling driver implements IP encapsulation, which can be used with xfrm to create secure tunnels and then use kernel-level routing over such tunnels.

In general, VTI tunnels work almost like IPIP or SIT tunnels. The exception is that they enable fwmark and IPsec encapsulation / decapsulation.

VTI6 is the IPv6 equivalent of VTI.

Here's how to create a VTI tunnel:

 # ip link add name vti1 type vti key VTI_KEY local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR # ip link set vti1 up # ip addr add LOCAL_VIRTUAL_ADDR/24 dev vti1 # ip xfrm state add src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR spi SPI PROTO ALGR mode tunnel # ip xfrm state add src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR spi SPI PROTO ALGR mode tunnel # ip xfrm policy add dir in tmpl src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR PROTO mode tunnel mark VTI_KEY # ip xfrm policy add dir out tmpl src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR PROTO mode tunnel mark VTI_KEY 

In addition, you can configure IPsec using libreswan or strongSwan .

GRE and GRETAP

GRE (Generic Routing Encapsulation) technology is described in RFC 2784 . With GRE tunneling, an additional GRE header is added between the headers of the inner and outer IP packets.

In theory, GRE can encapsulate packets of any Layer 3 protocol with a valid Ethernet type. This distinguishes GRE technology from IPIP technology, which only supports IP encapsulation. This is what the package header looks like when using the GRE technology.


GRE Tunnel Packet Header

Note that GRE tunnels allow multicast data transfer and support IPv6.

When the gre module is loaded, the Linux kernel creates a default device, gre0 .

Here's how to create a GRE tunnel:

 # ip link add name gre1 type gre local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR [seq] key KEY 

While GRE tunnels operate at layer 3 of the OSI model, GRETAP tunnels operate at layer 2 of OSI. This means that one of the internal headers of the corresponding packets are Ethernet headers.


GRETAP tunnel packet header

Here's how to create a GRETAP tunnel:

 # ip link add name gretap1 type gretap local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR 

GRE6 and GRE6TAP

GRE6 is the IPv6 equivalent of GRE. GRE6 tunnels allow you to encapsulate any Layer 3 protocols in IPv6. This is what the GRE6 header looks like.


GRE6 Tunnel Packet Header

In GRE6TAP tunnels, as well as in GRETAP tunnels, there are Ethernet headers among the internal packet headers.


GRE6TAP Tunnel Packet Header

Here's how to create a GRE tunnel:

 # ip link add name gre1 type gre6 local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR # ip link add name gretap1 type gretap6 local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR 

FOU

Tunneling can be performed at different levels of the network stack. IPIP, SIT and GRE tunnels exist at the IP level. And FOU tunnels (they are arranged according to the “foo over UDP” scheme) operate at the UDP level.

Using UDP tunneling has some advantages over IP tunneling. The fact is that the UDP protocol works with the existing hardware infrastructure.

For example, this is RSS in network cards, ECMP in switches, these are technologies for calculating checksums without the participation of a central processor. Applying the appropriate FOU patch for developers shows a significant increase in performance for the SIT and IPIP protocols.

Currently, FOU tunnels support IPIP, SIT, and GRE based protocol encapsulation. This is what a FOU header might look like.


FOU Tunnel Packet Header

Here's how to create a FOU tunnel:

 # ip fou add port 5555 ipproto 4 # ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap fou encap-sport auto encap-dport 5555 

The first command sets up the receiving FOU port for IPIP, tied to 5555. To use GRE, you need to use ipproto 47 . The second command sets up a new IPIP virtual interface ( tun1 ), designed for FOU encapsulation, the target port of which is 5555.

Please note that FOU tunnels are not supported in Red Hat Enterprise Linux.

GUE

Another type of UDP tunneling is represented by GUE ( Generic UDP Encapsulation ) technology. The difference between FOU and GUE is that GUE has its own header, which contains protocol information and other data.

Currently, GUE tunnels support IPIP, SIT, and GRE internal encapsulation. Here’s what a GUE package header might look like.


GUE Tunnel Packet Header

Here's how to create a GUE tunnel:

 # ip fou add port 5555 gue # ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap gue encap-sport auto encap-dport 5555 

These commands will create a receiving GUE port for IPIP, tied to 5555, and an IPIP tunnel configured for GUE encapsulation.

GUE tunnels are not supported in Red Hat Enterprise Linux.

GENEVE

GENEVE (Generic Network Virtualization Encapsulation) tunnels support all XLAN, NVGRE and STT features. GENEVE technology is designed with a view to bypassing the identified limitations of these three technologies. Many believe that this technology can, in the long term, completely replace these three older formats. This is what the GENEVE tunnel packet header looks like.


GENEVE Tunnel Packet Header

This header is similar to the VXLAN packet header. The main difference between the two is that the GENEVE header is more flexible. It makes it very easy to implement new features by expanding headers with Type-Length-Value (TLV) fields.

Details about GENEVE can be found here and here .

GENEVE is used in the Open Virtual Network (OVN) SDN solution as a standard encapsulation tool. Here's how to create a GENEVE tunnel:

 # ip link add name geneve0 type geneve id VNI remote REMOTE_IPv4_ADDR 

ERSPAN and IP6ERSPAN

ERSPAN (Encapsulated Remote Switched Port Analyzer) technology uses GRE encapsulation to extend the basic port mirroring capabilities from level 2 to level 3. This allows you to forward mirrored traffic over a routed IP network. This is what the ERSPAN package header looks like.


ERSPAN Tunnel Packet Header

ERSPAN tunnels allow Linux hosts to act as an ERSPAN traffic source and send mirrored ERSPAN traffic either to a remote host or to an ERSPAN destination that receives and processes ERSPAN packets generated by Cisco switches or other ERSPAN-enabled devices. Such a system can be used to analyze and diagnose the network, to detect malicious traffic.

Linux currently supports most of the capabilities of the two versions of ERSPAN - v1 (type II) and v2 (type III).

Here's how to create ERSPAN tunnels:

 # ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 1 erspan IDX 

You can still do this:

 # ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 2 erspan_dir DIRECTION erspan_hwid HWID 

Add a tc filter to monitor traffic:

 # tc qdisc add dev MONITOR_DEV handle ffff: ingress # tc filter add dev MONITOR_DEV parent ffff: matchall skip_hw action mirred egress mirror dev erspan1 

Results

We have covered quite a few technologies for creating tunnels in Linux. Here is a summary table for them.


Please note that all the tunnels, examples of which are shown here, exist only until the server is restarted. If you want to create a tunnel that can be restored after a reboot, consider using a daemon to configure the network, like NetworkManager , or use the appropriate mechanism from your Linux distribution.

Dear readers! What kind of Linux tunnel are you using?