EoIP Over an LTE VPN Link: Building a Small RouterOS Lab

EoIP takes a complete Ethernet frame, wraps it in GRE and sends it to a configured remote address, which is why the result behaves like a cable rather than like a route. What leaves the router is IP protocol 47 with the original frame as payload, so broadcasts, ARP and non-IP protocols all cross. GRE adds no confidentiality of its own, and the frame stays readable to anything that can see the outer packet. That single fact decides the order of this lab: build the encrypted path first, then carry Ethernet inside it.

What EoIP wraps, and what it does not

The encapsulation is the whole mechanism. A frame arrives on a bridged port, gets a GRE header and an outer IP header, and is delivered to the peer router, which strips both and injects the frame into its own bridge. The receiving bridge learns the source MAC exactly as it would from a local port. Nothing in that process authenticates the frame or hides it.

Confidentiality therefore has to come from the path the GRE packet travels over. In this design the underlay is a WireGuard or IPsec tunnel between the two routers, and EoIP is carried inside it. MikroTik also exposes an automatic-IPsec option on the EoIP interface itself, which is a different arrangement and is not what this lab configures.

For routed IP services a routed VPN is the smaller design and the one to prefer. Reach for layer two only when a device genuinely needs to see Ethernet frames from the other site.

Prerequisites: an encrypted underlay and two unused ports

Both routers need an established encrypted link and an address on it that the peer can reach. The LTE side initiates the outer connection, so the hub never dials the mobile network, and the LTE router maintains whatever NAT state the operator requires. Confirm that tunnel is up before adding anything on top of it, because an EoIP interface that cannot reach its remote address looks identical to a misconfigured one.

Each router also needs one port that is not already a bridge member, a VLAN trunk, a management interface or a production link. A lab that borrows a live port is not a lab, and the failure mode is a broadcast storm on a working network. Move administration to another interface or to the console before you start.

Hub tunnel address:    10.44.7.1/32
LTE tunnel address:    10.44.7.2/32
Lab ports:             ether7 on both routers, unused
Test hosts:            192.168.77.11/24 and 192.168.77.12/24

Those values are an example rather than a requirement. They must sit on the tunnel interfaces and be routed through the protected path. Firewall policy on both routers must permit GRE between the two tunnel addresses, and GRE is IP protocol 47 rather than a TCP or UDP port numbered 47. This design never exposes raw GRE to either WAN.

Create the tunnel pair with matching IDs

The two ends are one logical interface defined twice, so every identifying field has to agree. On the hub:

/interface eoip add name=eoip-lab local-address=10.44.7.1 remote-address=10.44.7.2 tunnel-id=37 mac-address=02:1A:2B:00:00:01

On the LTE router the addresses reverse and the MAC differs:

/interface eoip add name=eoip-lab local-address=10.44.7.2 remote-address=10.44.7.1 tunnel-id=37 mac-address=02:1A:2B:00:00:02

The tunnel ID must match on both ends and must not collide with another pair already configured on either router. The MAC addresses are locally administered values that have to be unique inside the layer-two domain you are joining, so do not reuse a value from a vendor example. Interface names are local to each router and only need to be consistent for your own scripts.

The current EoIP manual documents the endpoint and tunnel-ID fields, and it states plainly that EoIP is Ethernet over GRE. Nothing in that command encrypts anything, which is why the underlay check comes first.

Bridge only the test ports

A bridge is what turns the tunnel into a segment, and its membership is the entire safety boundary. On the hub:

/interface bridge add name=br-eoiphub protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:01
/interface bridge port add bridge=br-eoiphub interface=ether7
/interface bridge port add bridge=br-eoiphub interface=eoip-lab

On the LTE router:

/interface bridge add name=br-eoiplte protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:02
/interface bridge port add bridge=br-eoiplte interface=ether7
/interface bridge port add bridge=br-eoiplte interface=eoip-lab

These commands create new bridges and add exactly two ports to each. The EoIP interface is the layer-two member; the encrypted tunnel stays a routed transport and must never be added as a bridge port. Do not add a production port, and do not start a DHCP server on the lab bridge.

Give the two test hosts addresses in an unused subnet with no competing DHCP server, such as 192.168.77.11/24 and 192.168.77.12/24. They need no default gateway to reach each other inside that subnet, and a router interface address is not required for the frames to cross.

Budget the overhead before you extend a LAN

EoIP over IPv4 adds Ethernet, GRE and outer IP headers around the carried payload. For the untagged case MikroTik documents 42 bytes, so an underlay with 1400 bytes of usable IP MTU leaves 1358 bytes for the inner frame. That figure is a budget rather than a universal MSS value, and it does not force a bridged host to emit smaller frames.

Verify the real limits on the path, then test with the largest frame the appliance actually sends. A 1500-byte frame that must be fragmented inside the protected path behaves differently from one that fits, and the difference shows up as an application stall rather than as a link failure.

/interface eoip print detail where name=eoip-lab
/interface bridge host print where bridge=br-eoiphub
/ping 192.168.77.12 count=4 interface=br-eoiphub

RSTP handles loops, not arbitrary parallel paths, so keep the pilot topology simple. Extending a bridge also extends broadcast, multicast and DHCP behaviour across the mobile link, and that traffic consumes capacity whether or not any useful frame is moving.

Plan a production attachment only once the lab meets the frame size and the application behaviour you actually need. Before that cutover, agree on addressing, VLAN membership, DHCP authority, loop prevention and how someone reaches the routers when the link itself is down. An Ethernet extension joins failure domains as well as devices, so it deserves a change window rather than one more port on a working bridge.