Ethernet over IP (EoIP) on MikroTik: A Complete Guide for Network Engineers

Byadmin
Share
Tweet
Share
Pin
0 Shares

Ethernet over IP (EoIP) is a MikroTik RouterOS tunneling protocol that encapsulates Ethernet frames inside GRE packets, letting you bridge two Layer 2 networks across any IP path — including the public internet. This guide covers how EoIP actually works at the packet level, real RouterOS v7 configuration, the loop and MTU issues that break tunnels in production, and when EoIP is the wrong tool for the job.

Important up front: EoIP is a MikroTik-specific implementation, not an industry-standard protocol. Both tunnel endpoints need to run RouterOS (or a compatible open-source implementation) — you cannot build an EoIP tunnel to a Cisco, Juniper, or generic Linux router without a specific compatibility module.

Table of Contents

  1. What EoIP Is and When to Use It
  2. How EoIP Works at the Packet Level
  3. Overhead, MTU, and Fragmentation
  4. Key Benefits of EoIP
  5. Common Use Cases
  6. EoIP vs. Other Tunneling Protocols
  7. Step-by-Step Configuration (RouterOS v7)
  8. Bridging Loops and Loop Protection
  9. Performance Optimization and Best Practices
  10. Security: EoIP Has No Encryption
  11. Securing EoIP with IPsec — Configuration
  12. Troubleshooting EoIP with Real Commands
  13. Quick-Reference Configuration Cheat Sheet
  14. Conclusion

1. What EoIP Is and When to Use It

  • Definition: EoIP wraps full Ethernet frames — not just IP packets — inside GRE, creating a virtual Ethernet cable between two RouterOS devices over any routed IP path.
  • Why it exists: Some traffic needs Layer 2 adjacency — broadcast, ARP, non-IP protocols, or applications that assume a shared LAN — even when the two ends sit on different networks entirely.
  • What makes it different from GRE: Plain GRE carries IP and IPv6 packets only. EoIP carries entire Ethernet frames, so it can bridge two remote sites into one broadcast domain — something GRE alone cannot do.

2. How EoIP Works at the Packet Level

  • Encapsulation: RouterOS wraps each Ethernet frame in a GRE-style header and an outer IP header, then sends it as IP protocol 47 — the same protocol number plain GRE uses.
  • Tunnel identification: Every EoIP tunnel has a tunnel-id. Both ends of the same tunnel must use the same tunnel-id — this is not a per-side unique value, it is a shared identifier for that specific tunnel. If you build multiple EoIP tunnels between the same two routers, each separate tunnel needs its own distinct ID so RouterOS can tell them apart.
  • Stateless by design: Like GRE and IPIP, EoIP has no built-in session state. If the remote router disappears, traffic keeps flowing into the tunnel and gets silently dropped unless keepalive is configured.
  • Bridging makes it Layer 2: An EoIP interface by itself is just a tunnel. Add it to a bridge alongside a physical LAN interface, and RouterOS bridges all Ethernet traffic across the tunnel exactly as if a cable connected the two sites.

3. Overhead, MTU, and Fragmentation

This is the detail most guides skip, and the one that causes the most “it works for small packets but breaks for big transfers” tickets:

  • EoIP overhead is 42 bytes — a 20-byte outer IP header, an 8-byte GRE header, and a 14-byte Ethernet header. This is larger than plain GRE’s 24-byte overhead, since EoIP also carries the Ethernet header itself.
  • Default behavior: RouterOS sets the EoIP interface MTU to auto by default, which typically resolves to an actual-mtu of 1458 on a standard 1500-byte path (1500 − 42 = 1458).
  • Why this matters: If the underlying path cannot carry the full 1500-byte encapsulated packet — a PPPoE WAN link, an additional VPN layer, a lower-MTU carrier network — packets fragment or drop, and large transfers stall while small pings succeed.
  • MSS clamping is on by default. RouterOS ships EoIP interfaces with clamp-tcp-mss=yes, which automatically reduces the TCP MSS for traffic crossing the tunnel to avoid fragmentation on TCP sessions specifically — non-TCP traffic still needs the MTU sized correctly.

4. Key Benefits of EoIP

  • True Layer 2 extension: Broadcast, ARP, DHCP, and non-IP protocols all cross the tunnel exactly as they would on a physical LAN.
  • No dedicated circuit required: Runs over any IP path — internet, MPLS, wireless backhaul — without provisioning a dedicated Layer 2 line.
  • Simple to configure: A working tunnel is two commands per side, far less setup than MPLS or a full VPLS deployment.
  • Works over unconventional links: EoIP can run inside another tunnel (IPIP, PPTP, or any IP-capable connection), which is how it solves bridging over wireless links that cannot be bridged directly.

5. Common Use Cases

  • Bridging a wireless link. RouterOS wireless stations cannot be bridged directly in most modes — EoIP over the wireless link, then bridged locally, works around this limitation.
  • Branch office LAN extension when a remote site genuinely needs to be on the same VLAN and broadcast domain as headquarters, not just IP-routed to it.
  • Lab and test environments that need to simulate devices being on the same physical LAN segment regardless of physical location.
  • Legacy or non-IP applications that assume Layer 2 adjacency and cannot be re-architected around routed IP connectivity.

6. EoIP vs. Other Tunneling Protocols

Protocol OSI Layer Encryption Vendor Interoperability Best For
EoIP Layer 2 No (pair with IPsec) MikroTik-specific True LAN extension, bridging wireless links
GRE Layer 3 No (pair with IPsec) Industry-standard, broadly interoperable Routing protocols, BGP peering, multicast
VXLAN Layer 2 (over UDP) No Industry-standard, widely supported Data center L2 extension at scale, multi-tenant overlays
L2TP Layer 2 Optional (with IPsec) Industry-standard Remote access, ISP subscriber tunneling
IPsec (tunnel mode) Layer 3 Yes Industry-standard Encrypted site-to-site connectivity, no L2 requirement

If both sides are not RouterOS, EoIP is not on the table — reach for VXLAN or L2TPv3 instead when true Layer 2 extension needs to interoperate with other vendors.

7. Step-by-Step Configuration (RouterOS v7)

This example bridges LAN traffic between two sites, Router A (WAN 203.0.113.1) and Router B (WAN 203.0.113.2).

Router A

/interface eoip add name=eoip-to-siteb local-address=203.0.113.1 \
  remote-address=203.0.113.2 tunnel-id=1

/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=eoip-to-siteb
/interface bridge port add bridge=bridge1 interface=ether2

Router B

/interface eoip add name=eoip-to-sitea local-address=203.0.113.2 \
  remote-address=203.0.113.1 tunnel-id=1

/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=eoip-to-sitea
/interface bridge port add bridge=bridge1 interface=ether2
  • tunnel-id=1 matches on both sides — this is the same tunnel, identified consistently at both ends.
  • Bridging ether2 on both routers puts every device on those physical ports into the same Layer 2 broadcast domain, across the tunnel.
  • Once bridged, do not assign an IP address directly to the EoIP interface — the bridge itself carries the LAN’s addressing.

Enable keepalive to detect a dead tunnel

/interface eoip set eoip-to-siteb keepalive=10s,10

Without this, a dead remote router leaves the tunnel showing as running while every packet sent into it is silently dropped — RouterOS v7 sets a default of 10s,10 on new EoIP interfaces, but confirm it explicitly rather than assuming.

Verify the tunnel

/interface eoip print detail
/interface bridge port print
/ping 192.168.1.2

8. Bridging Loops and Loop Protection

Bridging two sites together creates a single broadcast domain — and a single point where a physical loop, a redundant tunnel, or a misconfigured second path can trigger a broadcast storm that takes down both sites at once.

  • RouterOS ships loop-protect enabled by default on EoIP interfaces. It sends periodic loop-detection packets and automatically disables the interface if it sees its own traffic looping back.
  • Check loop-protect status directly rather than assuming it is silently doing its job: 
    /interface eoip print detail
# look for loop-protect-status=off (healthy) vs on (loop detected, interface disabled)
  • Do not disable loop-protect to work around a flapping interface — that flapping is the protection working as intended. Find and fix the actual duplicate path instead.
  • Consider STP on the bridge if you have (or might later add) more than one path between the same two sites — loop-protect covers the EoIP interface itself, but STP protects the bridge as a whole against topology loops involving other interfaces.

9. Performance Optimization and Best Practices

  • Size the MTU deliberately rather than leaving it on auto in production — confirm the actual path MTU and set the EoIP interface to match, accounting for the 42-byte overhead.
  • Leave clamp-tcp-mss=yes enabled unless you have a specific reason to disable it — it prevents a large class of TCP fragmentation issues automatically.
  • Enable allow-fast-path=yes (the RouterOS default) for better throughput on supported hardware — verify with /interface eoip print detail if throughput seems lower than expected on capable hardware.
  • Keep broadcast traffic in mind. Every broadcast on either LAN crosses the tunnel and consumes bandwidth on both sides — EoIP is not a good fit for LANs with heavy broadcast chatter unless the tunnel has bandwidth to spare.

10. Security: EoIP Has No Encryption

  • EoIP encapsulates; it does not encrypt. Anyone capturing traffic on the path between the two routers can read everything inside the tunnel in plain text.
  • Firewall protocol 47 explicitly — since EoIP rides on GRE (IP protocol 47, not TCP or UDP), a standard port-based firewall rule will not catch it.
  • Restrict by source address once the tunnel is stable, rather than accepting GRE from anywhere.
  • For any tunnel crossing a public or untrusted network, pair EoIP with IPsec — covered next.

11. Securing EoIP with IPsec — Configuration

/ip ipsec profile add name=eoip-profile dh-group=modp2048 enc-algorithm=aes-256

/ip ipsec peer add name=eoip-peer address=203.0.113.2/32 \
  local-address=203.0.113.1 profile=eoip-profile exchange-mode=ike2

/ip ipsec identity add peer=eoip-peer secret=YOUR-STRONG-PSK

/ip ipsec proposal add name=eoip-proposal enc-algorithms=aes-256-cbc pfs-group=modp2048

/ip ipsec policy add src-address=203.0.113.1/32 dst-address=203.0.113.2/32 \
  protocol=gre tunnel=no sa-src-address=203.0.113.1 sa-dst-address=203.0.113.2 \
  proposal=eoip-proposal

protocol=gre with tunnel=no encrypts the EoIP-carrying GRE traffic in transport mode, since EoIP already provides the tunnel itself — this mirrors how you would encrypt a plain GRE tunnel. Confirm encryption is actually active with /tool profile under load: encrypting should show as a real CPU consumer, not just ethernet or gre.

12. Troubleshooting EoIP with Real Commands

Tunnel shows running, but no traffic crosses

/interface eoip print detail
/interface eoip monitor eoip-to-siteb
  • Confirm local-address and remote-address are correct and reachable — /ping the remote WAN IP directly before troubleshooting the tunnel itself.
  • Confirm keepalive is configured, and check whether the interface has silently gone into a loop-protect shutdown state.

Interface keeps disabling itself

  • Cause: Loop-protect has detected a loop — almost always a duplicate bridged path between the same two sites.
  • Fix: Check /interface eoip print detail for loop-protect-status=on, and audit every path — physical or tunneled — between the two bridged networks.

Small packets work, large transfers stall

  • Cause: MTU mismatch — the 42-byte EoIP overhead pushes packets past what the underlying path can carry.
  • Fix: Test with a specific packet size and compare against the tunnel’s actual-mtu: 
    /ping 203.0.113.2 size=1450 do-not-fragment

    Lower the EoIP interface MTU explicitly if the path cannot carry the default.

Tunnel works, but ARP or broadcast traffic does not cross

  • Cause: The EoIP interface was never added to the bridge, or was added to the wrong bridge — an EoIP interface with an IP address assigned directly, instead of being bridged, only carries traffic destined for that specific IP, not full Layer 2 traffic.
  • Fix: Confirm with /interface bridge port print that the EoIP interface is a bridge port, not a routed interface.

13. Quick-Reference Configuration Cheat Sheet

# Create the EoIP interface (both sides use the same tunnel-id)
/interface eoip add name=eoip-remote local-address=WAN_IP \
  remote-address=REMOTE_WAN_IP tunnel-id=1

# Enable keepalive
/interface eoip set eoip-remote keepalive=10s,10

# Bridge it with a local LAN interface
/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=eoip-remote
/interface bridge port add bridge=bridge1 interface=ether2

# Check loop protection status
/interface eoip print detail

# Test MTU
/ping REMOTE_WAN_IP size=1450 do-not-fragment

# Firewall: allow GRE (protocol 47) explicitly
/ip firewall filter add chain=input protocol=gre action=accept

Conclusion

EoIP does one thing well: it makes two RouterOS devices act like they share a physical Ethernet cable, over any IP path in between. That is genuinely useful for bridging wireless links, extending a LAN for a migration window, or connecting lab environments — but it is MikroTik-specific, unencrypted, and stateless by default. Get the tunnel-id matching, the MTU sized for the 42-byte overhead, loop-protect verified, and IPsec layered on for anything crossing a public network, and EoIP does exactly what it promises. Skip any one of those, and it fails in ways that look like an unrelated network problem.

Check our list of MikroTik guides

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *