EoIP Tunnels

EoIP Tunnels

EoIP (Ethernet over IP) is a MikroTik-proprietary Layer 2 tunnel protocol built into RouterOS. It encapsulates full Ethernet frames inside a GRE header (IP protocol 47), creating a virtual Ethernet interface that you can bridge with local switch ports to extend a LAN transparently across an IP network.

Key characteristics:

• Layer 2 — carries raw Ethernet frames including broadcasts, multicast, and unknown unicast, just like a physical cable.
• Proprietary — both endpoints must be MikroTik routers. EoIP will not interoperate with Cisco, Juniper, Linux, or other vendors.
• No encryption — traffic is unencrypted by default. Use IPsec to secure it.
• tunnel-id — a 16-bit identifier (0–65535) that must match on both endpoints. Multiple EoIP tunnels between the same pair of IPs are distinguished by their tunnel-id.

---

Prerequisites

• RouterOS 6.x or later on both endpoints
• IP connectivity between the two endpoint addresses (public or routable)
• Firewall input rules permitting GRE (IP protocol 47) between endpoints

---

Concepts

How EoIP works

EoIP wraps each Ethernet frame in a GRE header and sends it as an IP packet. The receiving router strips the GRE header and delivers the inner Ethernet frame to the local bridge. From the perspective of any device connected to the bridge, the remote site’s ports appear to be directly connected — same broadcast domain, same subnet.

[ Local Ethernet frame ]
        ↓ encapsulate
[ IP | GRE | EoIP header | Ethernet frame ]
        ↓ IP network
[ IP | GRE | EoIP header | Ethernet frame ]
        ↓ decapsulate
[ Local Ethernet frame ]

tunnel-id

Every EoIP interface has a tunnel-id (0–65535). Both endpoints must configure the same tunnel-id. This allows multiple independent EoIP tunnels between the same pair of IP addresses — each with a different tunnel-id.

Choose tunnel-id values that are unique within your network. Conflicting tunnel-id values between the same endpoints will cause duplicate bridge ports and forwarding loops.

Overhead

EoIP uses GRE (24 bytes) plus a 4-byte EoIP header, totalling 28 bytes of overhead per packet. On a standard 1500-byte Ethernet path:

Outer MTU	EoIP overhead	Inner payload (L2MTU)
1500 bytes	28 bytes	1472 bytes

The tunnel interface mtu is set to 1500 by default (the inner payload MTU), but the physical interface carrying the outer packets needs to accommodate the full 1528-byte frame. If the uplink MTU is exactly 1500, reduce the EoIP mtu to 1472.

---

Creating an EoIP Interface

/interface eoip add \
    name=eoip-to-branch \
    remote-address=203.0.113.2 \
    tunnel-id=1

Interface properties:

Property	Default	Description
name	—	Interface name
remote-address	—	Remote transport IP (the other endpoint)
local-address	0.0.0.0	Local transport IP. Use 0.0.0.0 to bind to any outbound address, or set explicitly to control the source
tunnel-id	0	Tunnel identifier (0–65535). Must match on both endpoints
mac-address	auto	MAC address of the EoIP interface. Auto-generated if not specified
mtu	1500	Inner payload MTU. Reduce if the uplink MTU is 1500
l2mtu	65535	Layer 2 MTU reported to the bridge
ipsec-secret	—	Pre-shared key to automatically create an IPsec transport policy
keepalive	10s,10	Keepalive interval and retry count
clamp-tcp-mss	yes	Clamp TCP MSS to prevent fragmentation
allow-fast-path	yes	Enable fast-path acceleration
disabled	no	Whether the interface is disabled

---

Bridging EoIP for L2 Extension

The typical EoIP use case is transparent LAN extension: both sites share one IP subnet and the same broadcast domain. To achieve this, add the EoIP interface and the local Ethernet port to a bridge on each router.

Site A — bridge configuration

Site A has local subnet 192.168.10.0/24, public IP 198.51.100.1, local port ether2.

# Create EoIP tunnel to Site B
/interface eoip add \
    name=eoip-to-b \
    remote-address=203.0.113.2 \
    tunnel-id=10

# Create a bridge
/interface bridge add name=br-lan

# Add local port and EoIP to the bridge
/interface bridge port add interface=ether2 bridge=br-lan
/interface bridge port add interface=eoip-to-b bridge=br-lan

# Assign IP to the bridge (not to ether2 directly)
/ip address add address=192.168.10.1/24 interface=br-lan

Site B — bridge configuration

Site B has local subnet 192.168.10.0/24 (same subnet), public IP 203.0.113.2, local port ether2.

# Create EoIP tunnel to Site A
/interface eoip add \
    name=eoip-to-a \
    remote-address=198.51.100.1 \
    tunnel-id=10

# Create a bridge
/interface bridge add name=br-lan

# Add local port and EoIP to the bridge
/interface bridge port add interface=ether2 bridge=br-lan
/interface bridge port add interface=eoip-to-a bridge=br-lan

# Assign IP to the bridge
/ip address add address=192.168.10.2/24 interface=br-lan

Once both sides are up, hosts at Site A and Site B are on the same 192.168.10.0/24 subnet and can communicate directly — ARP requests and DHCP broadcasts cross the tunnel transparently.

Warning: Bridging two sites at L2 merges their broadcast domains. A broadcast storm at one site will flood across the tunnel. Enable STP (/interface bridge set br-lan protocol-mode=rstp) to prevent forwarding loops if there are redundant paths.

Firewall — allow GRE traffic

EoIP uses IP protocol 47 (same as GRE). Add input accept rules on both routers:

/ip firewall filter add \
    chain=input \
    protocol=gre \
    src-address=203.0.113.2 \
    action=accept \
    comment="Allow EoIP from Site B"

Place this rule before any default drop rule.

---

MTU Considerations

EoIP adds 28 bytes of overhead (24 GRE + 4 EoIP). If the physical path between endpoints has an MTU of 1500 bytes:

1500 (path MTU) - 28 (EoIP overhead) = 1472 bytes maximum inner payload

If devices behind the bridge send full 1500-byte frames, the outer packet will exceed the path MTU and be fragmented or dropped. Mitigate this with one of the following approaches:

Option 1 — Reduce EoIP MTU (recommended):

/interface eoip set eoip-to-branch mtu=1472

With clamp-tcp-mss=yes (the default), RouterOS also rewrites the TCP MSS in SYN packets to match the reduced MTU, preventing black-hole issues for TCP traffic.

Option 2 — Increase uplink MTU (jumbo frames):

If you control both endpoints and the intermediate network, configure jumbo frames (mtu=9000) on the physical interfaces so the 28-byte overhead does not cause fragmentation.

Option 3 — Enable path MTU discovery:

Ensure ICMP type 3 code 4 (fragmentation needed) is not blocked by your firewall. Hosts use this to discover the correct PMTU.

---

VLAN Extension over EoIP

Because EoIP operates at Layer 2, it passes 802.1Q-tagged frames transparently. You can use a VLAN-aware bridge to extend multiple VLANs across a single EoIP tunnel without creating one tunnel per VLAN.

How it works

Add the EoIP interface as a tagged (trunk) port in a VLAN-aware bridge. Local switch ports are added as access or tagged ports per VLAN. 802.1Q tags are preserved as they traverse the tunnel.

Site A                                    Site B
[ether2 VLAN10 access] ─┐            ┌─ [ether2 VLAN10 access]
[ether3 VLAN20 access] ─┤ br-vlans   ├─ [ether3 VLAN20 access]
                         │ (VLAN-aware)│
                         └─ eoip-to-b ─┘  (trunk: VLAN10, VLAN20)

Site A — VLAN-aware bridge with EoIP trunk

# EoIP tunnel to Site B
/interface eoip add name=eoip-to-b remote-address=203.0.113.2 tunnel-id=20

# VLAN-aware bridge
/interface bridge add name=br-vlans vlan-filtering=yes

# Local access ports
/interface bridge port add interface=ether2 bridge=br-vlans pvid=10
/interface bridge port add interface=ether3 bridge=br-vlans pvid=20

# EoIP as a tagged trunk port carrying both VLANs
/interface bridge port add interface=eoip-to-b bridge=br-vlans

# Declare VLANs on the bridge
/interface bridge vlan add bridge=br-vlans vlan-ids=10 tagged=eoip-to-b untagged=ether2
/interface bridge vlan add bridge=br-vlans vlan-ids=20 tagged=eoip-to-b untagged=ether3

# Router IP on each VLAN (optional — only if the router needs an address on each VLAN)
/interface vlan add name=vlan10 interface=br-vlans vlan-id=10
/interface vlan add name=vlan20 interface=br-vlans vlan-id=20
/ip address add address=192.168.10.1/24 interface=vlan10
/ip address add address=192.168.20.1/24 interface=vlan20

Site B — mirror configuration

/interface eoip add name=eoip-to-a remote-address=198.51.100.1 tunnel-id=20

/interface bridge add name=br-vlans vlan-filtering=yes

/interface bridge port add interface=ether2 bridge=br-vlans pvid=10
/interface bridge port add interface=ether3 bridge=br-vlans pvid=20
/interface bridge port add interface=eoip-to-a bridge=br-vlans

/interface bridge vlan add bridge=br-vlans vlan-ids=10 tagged=eoip-to-a untagged=ether2
/interface bridge vlan add bridge=br-vlans vlan-ids=20 tagged=eoip-to-a untagged=ether3

/interface vlan add name=vlan10 interface=br-vlans vlan-id=10
/interface vlan add name=vlan20 interface=br-vlans vlan-id=20
/ip address add address=192.168.10.2/24 interface=vlan10
/ip address add address=192.168.20.2/24 interface=vlan20

With this setup, VLAN 10 and VLAN 20 traffic crosses the tunnel tagged, keeping each VLAN isolated while sharing one EoIP interface.

MTU with 802.1Q tags

802.1Q adds 4 bytes to each frame. Combined with the 28-byte EoIP overhead, the effective overhead for tagged frames is 32 bytes:

1500 (path MTU) - 28 (EoIP) - 4 (802.1Q) = 1468 bytes maximum tagged payload

If the uplink MTU is 1500, set EoIP MTU to 1468 when carrying tagged frames:

/interface eoip set eoip-to-b mtu=1468

---

Performance Considerations

Fast-path acceleration

EoIP supports RouterOS fast-path when allow-fast-path=yes (the default). Fast-path bypasses the main CPU routing engine and processes packets directly in the driver layer, significantly increasing throughput on capable hardware.

Check whether fast-path is active:

/interface print detail where name=eoip-to-b

Look for the F (fast-path) flag in the interface flags. If it is absent, the tunnel is processing in slow path.

Fast-path is disabled when:

• IPsec (ipsec-secret) is enabled on the EoIP interface — encryption requires the main CPU.
• Bridge firewall rules or bridge-filter are applied to the bridge containing the EoIP port.
• The interface runs over a PPPoE or VLAN sub-interface that itself does not support fast-path.

CPU impact

Without fast-path, all EoIP-encapsulated traffic passes through the main CPU. On high-throughput links or low-end hardware (e.g., hAP series), this can saturate the CPU before the link is fully utilised. Symptoms: high CPU usage (/system resource print), increased latency, and packet drops.

Reduce CPU load by:

1. Ensuring fast-path is active (avoid IPsec via ipsec-secret on high-throughput tunnels; use hardware IPsec offload where available instead).
2. Setting clamp-tcp-mss=yes (default) to avoid CPU-intensive fragmentation.
3. Keeping the number of EoIP tunnels proportional to the router’s CPU capacity — each tunnel adds a bridge port and increases bridge forwarding table size.

IPsec overhead

Enabling ipsec-secret on an EoIP interface adds AES encryption and SHA HMAC processing to every packet. This:

• Disables fast-path on the EoIP interface.
• Increases per-packet CPU time by the cost of AES + HMAC operations.
• Adds approximately 50–70 bytes of ESP overhead per packet (ESP header, IV, auth tag, padding), reducing effective throughput further.

On routers with hardware crypto acceleration (CCR series, RB4011), IPsec overhead is substantially lower. Check whether hardware offload is available:

/ip ipsec statistics print

If hw-aead-* counters increment, the hardware engine is offloading encryption.

Keepalive overhead

The default keepalive=10s,10 sends a probe every 10 seconds and declares the tunnel down after 10 missed probes (100 seconds). This adds negligible overhead. Increase the interval on metered WAN links if keepalive traffic is a concern:

/interface eoip set eoip-to-b keepalive=30s,5

Multiple tunnels

Each EoIP tunnel is a separate bridge port. RouterOS scales to hundreds of EoIP interfaces on capable hardware. However, every additional tunnel:

• Increases bridge MAC table size (one entry per learned MAC per port).
• Increases bridge flooding scope if unknown unicast is present.
• Adds CPU overhead proportional to traffic volume when fast-path is inactive.

For large-scale L2 overlays (many sites, many VLANs), consider VXLAN instead — it uses a single UDP socket and scales more efficiently than per-site EoIP tunnels.

---

IPsec Encryption

EoIP carries traffic in plaintext. To encrypt the tunnel, use the ipsec-secret property. RouterOS automatically creates an IPsec transport-mode policy protecting all GRE traffic between the two transport addresses.

# Site A
/interface eoip set eoip-to-b ipsec-secret=StrongSharedSecret

# Site B (same secret)
/interface eoip set eoip-to-a ipsec-secret=StrongSharedSecret

RouterOS negotiates IKEv1 with this method. Limitations are the same as for GRE ipsec-secret:

• IKEv1 only — no control over cipher suites or DH groups
• Auto-generated IPsec peers are not editable
• Limited visibility into IPsec state

For production deployments requiring IKEv2 or specific crypto parameters, configure IPsec manually with a transport policy matching IP protocol 47 between the two public IPs, then leave ipsec-secret unset.

---

EoIP vs GRE vs VXLAN

Choose the right tunnel technology based on your layer requirements and vendor constraints.

	EoIP	GRE	VXLAN
OSI layer	L2 (Ethernet)	L3	L2 (Ethernet)
IP protocol / port	47 (GRE subtype)	47	UDP 4789
Header overhead	28 bytes	24 bytes	50 bytes (IPv4)
Carries	Ethernet frames	Any network-layer protocol	Ethernet frames
Standard	MikroTik proprietary	RFC 2784	RFC 7348
Non-MikroTik compatible	No	Yes	Yes
Multicast support	Yes (Ethernet)	Yes	Yes (underlay or ingress replication)
Keepalive	Yes	Yes	No (protocol-level)
Scalability	Per-tunnel bridge port	Per-tunnel route	16 million segments (24-bit VNI)
Typical use	L2 extension between two MikroTik sites	Routed site-to-site, dynamic routing	Multi-tenant overlays, large-scale L2 fabrics

When to use EoIP

• Both endpoints are MikroTik routers and you need a transparent L2 bridge across sites.
• You are extending a VLAN or a broadcast domain to a remote site (e.g., connecting a branch office printer to the HQ subnet).
• You need bridged wireless backhauls between MikroTik access points.

When to use GRE

• One or both endpoints are non-MikroTik (Cisco, Juniper, Linux).
• You need to run OSPF or BGP over the tunnel (GRE carries multicast; EoIP bridges it, which is less efficient for routing protocols).
• You want L3 routing between sites rather than a shared broadcast domain.

When to use VXLAN

• You need L2 extension with non-MikroTik endpoints (VXLAN is an open standard).
• You are building multi-tenant or large-scale overlay networks.
• You need more than 65535 isolated segments (VXLAN has a 24-bit VNI; EoIP is limited to 65535 tunnel-id values).

---

Troubleshooting

Check interface status

/interface eoip print detail

A healthy interface shows the R (running) flag. A disabled or down interface will be missing R.

Verify bridge membership

/interface bridge port print

Both the local port and the EoIP interface should appear as bridge ports with status=forwarding.

Ping across the tunnel

# Ping the remote router's bridge IP
/ping 192.168.10.2

# Ping a host on the remote LAN
/ping 192.168.10.100

Packet capture — verify GRE encapsulation

# Capture EoIP (GRE, protocol 47) on the WAN interface
/tool sniffer quick ip-proto=47 interface=ether1

You should see GRE packets between the two public IPs. If you see none, the firewall is likely blocking protocol 47.

Common problems

Symptom	Likely cause	Fix
Interface stays down	Firewall blocking GRE	Add chain=input protocol=gre action=accept for the remote IP
Interface up, no L2 traffic	EoIP not added to bridge	/interface bridge port add interface=eoip-to-branch bridge=br-lan
Broadcast storm	Redundant L2 path without STP	Enable RSTP: /interface bridge set br-lan protocol-mode=rstp
DHCP not crossing tunnel	Broadcast filtering	Verify bridge is forwarding broadcasts; check for bridge filter rules
High packet loss / fragmentation	MTU too large	Reduce EoIP MTU to 1472 (or match path MTU minus 28 bytes)
tunnel-id mismatch	Different tunnel-id on each end	Verify both routers use the same tunnel-id value
IPsec not encrypting	ipsec-secret mismatch	Confirm identical secret on both sides; check /ip ipsec active-peers print

---

See Also

• GRE and IPIP Tunnels — L3 tunnels for routed site-to-site connectivity
• WireGuard VPN — encrypted tunnel with modern cryptography
• IPsec — encrypt EoIP with manual IKEv2 policies