How to Create and Configure Layer-2 GRETAP Tunnel Interfaces in Linux Using ip link

In complex cloud architectures, branch-office interconnects, and container overlay networks, engineers frequently need to extend a flat layer-2 broadcast domain across routed layer-3 IP infrastructure. While standard Generic Routing Encapsulation (GRE) tunnels encapsulate layer-3 IP packets within an outer IP header, they cannot carry raw Ethernet frames, ARP requests, DHCP broadcasts, or VLAN tags. To bridge Ethernet segments transparently across WAN or internet links without the overhead of heavy cryptographic VPNs, the Linux kernel provides GRETAP (GRE Tap) virtual network interfaces. By combining ip link commands with Linux software bridging, systems administrators can encapsulate layer-2 frames directly over IPv4 or IPv6 underlays.

Understanding GRETAP vs Standard GRE Tunnels

The Linux kernel’s tunneling subsystem distinguishes between two fundamental GRE interface types:

• GRE (Point-to-Point L3): Created via type gre. Represents a layer-3 point-to-point interface that strips the Ethernet header and transmits purely IP datagrams. Because it lacks MAC address handling and broadcast forwarding, it cannot be attached to a Linux software bridge (br0).
• GRETAP (Ethernet over GRE L2): Created via type gretap. Synthesizes a virtual Ethernet device complete with its own MAC address. It encapsulates complete layer-2 Ethernet frames—including source/destination MAC addresses, payload data, and optional 802.1Q VLAN tags—inside outer GRE/IP packets. GRETAP interfaces can be enslaved directly to software bridges, enabling seamless layer-2 extension.

Verifying Kernel GRETAP Module Support

Before creating a tunnel interface, ensure the Linux kernel has loaded the necessary tunneling drivers:

sudo modprobe ip_gre
lsmod | grep gre

The module ip_gre (and its dependency gre) will appear in the active module list.

Creating a Layer-2 GRETAP Interface with ip link

To provision a GRETAP interface between two endpoints, identify the local IP address on your primary network interface and the remote public or private underlay IP address of the peer host.

Assume Host A operates on local IP 198.51.100.10 and connects to Host B on remote IP 203.0.113.20.

To create the GRETAP tunnel interface on Host A:

sudo ip link add name gretap0 type gretap \
    local 198.51.100.10 \
    remote 203.0.113.20 \
    ttl 64

Key configuration attributes:

• name gretap0: The name of the virtual Ethernet interface.
• type gretap: Instructs the kernel to synthesize a layer-2 tap device rather than a layer-3 gre device.
• local <IP>: The source IP address binding the outer GRE tunnel wrapper.
• remote <IP>: The destination IP address of the remote peer endpoint.
• ttl 64: Sets the Time-To-Live counter on outgoing outer GRE packets.

Configuring MTU Adjustments for GRE Overhead

Standard Ethernet has a Maximum Transmission Unit (MTU) of 1500 bytes. Because outer IPv4 headers consume 20 bytes and GRE headers consume 4 to 8 bytes, encapsulating a full 1500-byte frame causes IP fragmentation. To prevent packet fragmentation and latency spikes, adjust the tunnel MTU appropriately:

# Set GRETAP MTU to accommodate outer header overhead
sudo ip link set dev gretap0 mtu 1462

# Bring the interface up
sudo ip link set dev gretap0 up

Verify that the interface is operational and has generated a virtual MAC address:

ip link show dev gretap0

Enslaving the GRETAP Tunnel to a Linux Software Bridge

To transparently bridge local virtual machines, physical ethernet ports, or container veth pairs across the GRETAP tunnel:

# Create a new Linux bridge if not already existing
sudo ip link add name br0 type bridge
sudo ip link set dev br0 up

# Enslave the GRETAP tunnel to the bridge
sudo ip link set dev gretap0 master br0

# Enslave an internal interface (e.g. veth or tap device)
sudo ip link set dev tap0 master br0

To inspect bridge port memberships and forwarding database states:

bridge link show

Now, any ARP request or broadcast packet emitted by tap0 passes through br0, enters gretap0, and is encapsulated over the WAN to the remote host without intermediate routing.

Mirroring Configuration on the Remote Peer

On the remote peer (Host B at 203.0.113.20), configure the complementary tunnel pointing back to Host A:

# Load module
sudo modprobe ip_gre

# Create matching tunnel on Host B
sudo ip link add name gretap0 type gretap \
    local 203.0.113.20 \
    remote 198.51.100.10 \
    ttl 64

# Configure MTU and activate
sudo ip link set dev gretap0 mtu 1462
sudo ip link set dev gretap0 up

# Attach to local bridge
sudo ip link set dev gretap0 master br0

Testing Layer-2 Connectivity and Packet Encapsulation

Assign IP addresses within the same subnet (e.g. 10.50.0.1/24 and 10.50.0.2/24) to the bridge interfaces on each host and test end-to-end communication:

ping -c 4 10.50.0.2

To verify that packets are actively encapsulated in GRE on the underlying physical interface, capture packets using tcpdump:

sudo tcpdump -n -i eth0 proto gre

The dump displays GRE-encapsulated frames travelling between 198.51.100.10 and 203.0.113.20.

Tearing Down the GRETAP Interface

To dismantle the tunnel cleanly when testing concludes:

sudo ip link set dev gretap0 down
sudo ip link delete dev gretap0

Deploying GRETAP tunnels via ip link gives Linux engineers an agile, lightweight layer-2 extension mechanism that simplifies cross-datacenter bridging, container connectivity, and testing across disparate cloud environments.