VXLAN is what the datacenter world settled on for stretching Layer 2 over Layer 3, and for good reason: it asks nothing of the transport except IP reachability and a slightly bigger MTU. No label distribution, no LDP sessions, no MPLS-capable core. Encapsulate the Ethernet frame in UDP, send it to the far end, decapsulate, done. Sixteen million VNIs of segmentation instead of 4094 VLANs, and it crosses any network that routes IP — including ones you don’t own.
RouterOS 7 ships a native VXLAN implementation that’s genuinely useful: static unicast VTEPs, multicast BUM handling where the transport supports it, clean bridge integration, and — since 7.18 — initial hardware offload on capable switch chips. What it doesn’t have is a full EVPN control plane like the big datacenter platforms (and VyOS — see the VXLAN article in my VyOS series for that side); more on that gap at the end.
The Pieces
A VXLAN interface on RouterOS is a virtual Ethernet port identified by a VNI (VXLAN Network Identifier). It encapsulates frames into UDP (port 4789 by default) and sends them to VTEPs — the remote endpoints. You bridge the VXLAN interface with local ports exactly like a physical interface, and the bridge’s MAC learning extends across the tunnel.
The design question is only: how does BUM traffic (broadcast, unknown unicast, multicast) find the other VTEPs? RouterOS gives you two answers: a static list of unicast VTEPs (head-end replication), or a multicast group if your transport does multicast routing. For site-to-site over routed networks — the common case — static unicast is the answer.
Two Sites, One L2 Segment
Routers R1 (transport IP 10.255.0.1, a loopback) and R2 (10.255.0.2), any routed path between them:
# R1/interface vxlan add name=vxlan100 vni=100 port=4789 \ local-address=10.255.0.1 comment="Stretched lab segment"/interface vxlan vteps add interface=vxlan100 remote-ip=10.255.0.2
# R2 — mirror/interface vxlan add name=vxlan100 vni=100 port=4789 local-address=10.255.0.2/interface vxlan vteps add interface=vxlan100 remote-ip=10.255.0.1Then bridge it with the local ports on each side:
/interface bridge add name=br-lab/interface bridge port add bridge=br-lab interface=ether5/interface bridge port add bridge=br-lab interface=vxlan100That’s the whole thing. Hosts on ether5 at both sites are now in one broadcast domain. local-address pinned to a loopback keeps the tunnel stable across path changes — the same discipline as BGP and VPLS peering in earlier articles.
With three or more sites, add every remote VTEP to the list on each router. BUM frames are replicated head-end to each VTEP — which is fine at three sites and increasingly ugly at ten; each broadcast costs you N-1 unicast copies on the WAN. Also apply the same split-horizon thinking as VPLS: RouterOS does not re-flood frames between VTEPs of the same VXLAN interface, so a full mesh of VTEP entries stays loop-free — but do build the full mesh; partial meshes leave silent black holes between sites that lack a direct VTEP entry.
For VLAN-aware setups, map VNIs per VLAN: one VXLAN interface per VNI, each bridged appropriately (or as tagged members on a VLAN-filtering bridge — the bridge VLAN article covers that model).
Multicast Mode
If — and only if — the transport network runs multicast routing (PIM), you can skip static VTEP lists:
/interface vxlan add name=vxlan200 vni=200 group=239.1.1.200 \ vteps-ip-version=ipv4 local-address=10.255.0.1With a group set, BUM traffic goes to the multicast group and VTEPs discover each other from source IPs. This is elegant and almost nobody’s WAN supports it. Across the internet or a provider L3VPN, it’s not an option; inside your own datacenter fabric it might be. Static unicast remains the deployment reality.
MTU: 50 Bytes of Tax
VXLAN overhead is the biggest of the tunnel family: outer IP (20) + UDP (8) + VXLAN header (8) + inner Ethernet (14) = 50 bytes over IPv4 (70 over IPv6, and +4 more if the inner frame carries a VLAN tag).
Two ways to pay:
Raise the transport MTU (correct): if you control the path, run the underlay at 1600+ and full 1500-byte inner frames fit untouched.
/interface ethernet set ether1 mtu=1600 l2mtu=1604Lower the inner MTU (the internet reality): clamp the VXLAN interface and let hosts learn the smaller MTU:
/interface vxlan set vxlan100 mtu=1450What you must not do is nothing. Fragmented VXLAN performs miserably, and dropped fragments produce the classic “ping works, transfers hang” ghost. Test with full-size frames end to end before declaring victory — from hosts inside the segment, ping -s 1422 -M do (1450 minus IP/ICMP headers) or your OS’s equivalent.
Over untrusted transport, VXLAN offers zero confidentiality or authentication — anyone on-path can read and inject frames. Run it inside WireGuard (subtract another 60 bytes; the WireGuard article covers the interface setup) or IPsec. VXLAN-over-WireGuard between sites is a genuinely great combination: WireGuard handles crypto and roaming, VXLAN handles the L2 semantics.
Hardware Offload
Since RouterOS 7.18, capable switch chips (recent CRS3xx/CRS5xx-class hardware) can offload VXLAN encap/decap, moving it from CPU to ASIC — with early-generation limitations around ECMP, bonds, and IPv6 VTEPs, so read the release notes for your exact platform and version before counting on wire speed. Check whether offload engaged the same way as bridge offload: look for the hardware-offload flag on the relevant interfaces and watch CPU under load. On CPU-only platforms (RB5009, hAP-class, CHR), VXLAN throughput is honest software forwarding — fine for lab and branch links, not for aggregating gigabits of east-west traffic.
Verification
/interface vxlan print detail/interface vxlan vteps print# MAC learning across the tunnel — remote MACs should appear on vxlan100/interface bridge host print where interface=vxlan100# Is encapsulated traffic actually flowing?/tool sniffer quick interface=ether1 port=4789The bridge host table is the truth serum: if remote MACs never show up on the VXLAN interface, BUM isn’t crossing — check VTEP lists on both ends (asymmetric lists are the #1 mistake), then UDP 4789 reachability between the local-addresses, then whether a firewall on the input chain is eating it (accept udp dst-port=4789 from the transport on both sides).
The EVPN Question
What’s missing versus big datacenter platforms is the control plane: proper EVPN uses BGP to advertise MAC/IP bindings so unknown-unicast flooding mostly disappears and VTEPs auto-discover. RouterOS VXLAN is data-plane-first — static VTEPs and flood-and-learn. MikroTik has been moving toward EVPN support in recent 7.x development, so check the current release notes if that’s a requirement; as of this writing I’d still build EVPN fabrics on platforms where it’s mature and use RouterOS VXLAN for what it’s excellent at today: site-to-site L2 extension, lab fabrics, and stitching segments over networks you don’t control.
Closing Thoughts
VXLAN is the pragmatic choice for L2 extension on RouterOS: two commands per site, no underlay religion, works over anything that routes. The discipline is all operational — full-mesh VTEP lists kept symmetric, the 50-byte tax paid explicitly, WireGuard underneath when the path is untrusted, and full-size-frame tests before handover. If you have an MPLS core already, weigh it against VPLS from the previous article; if you don’t, this is the one to reach for.