VXLAN (Virtual Extensible LAN) is an open-standard Layer 2 overlay protocol defined in RFC 7348. It encapsulates Ethernet frames inside UDP packets (destination port 4789), allowing Layer 2 networks to be extended across an IP underlay. RouterOS implements VXLAN as a virtual interface that can be bridged with local ports to create transparent L2 segments spanning multiple sites or routers.
Key characteristics:
Layer 2 — carries raw Ethernet frames, preserving broadcast domains across IP networks.
Open standard — interoperates with Linux, Cisco, Juniper, and any RFC 7348-compliant device. Both endpoints do not need to be MikroTik.
UDP encapsulation — uses UDP port 4789, which traverses NAT and most firewalls more easily than GRE (IP protocol 47).
24-bit VNI — the VXLAN Network Identifier supports up to 16,777,215 isolated segments, far exceeding EoIP’s 65,535 tunnel IDs.
No built-in encryption — traffic is unencrypted by default. Combine with WireGuard or IPsec for security.
VXLAN wraps each Ethernet frame in a VXLAN header, UDP header, and outer IP header, then sends it as a normal UDP packet. The receiving VTEP (VXLAN Tunnel Endpoint) strips the headers and delivers the inner Ethernet frame to the local bridge. Devices behind the bridge see a flat Ethernet network — same broadcast domain, same subnet — regardless of physical location.
The VNI is a 24-bit field (1–16,777,215) that identifies the L2 segment. All VTEPs participating in the same segment must use the same VNI. Traffic with different VNIs is isolated — VMs on VNI 100 cannot communicate with VMs on VNI 200 without a router (or L3 gateway) between them.
A VTEP is the endpoint that performs encapsulation and decapsulation. In RouterOS, a VXLAN interface is itself a VTEP. VTEPs must be able to reach each other over the IP underlay. Each VXLAN interface has a local-address (the source IP used in outer packets) and a list of remote VTEPs configured via /interface vxlan vteps.
Add a remote VTEP entry for each peer. BUM traffic is unicast to each listed VTEP. This is the simplest mode and works without multicast in the underlay.
Site A (local IP 198.51.100.1):
/interface vxlan add \
name=vxlan1 \
vni=10 \
local-address=198.51.100.1
/interface vxlan vteps add \
interface=vxlan1 \
remote-ip=203.0.113.1
Site B (local IP 203.0.113.1):
/interface vxlan add \
name=vxlan1 \
vni=10 \
local-address=203.0.113.1
/interface vxlan vteps add \
interface=vxlan1 \
remote-ip=198.51.100.1
For three or more sites, add a VTEP entry for every other site on each router.
Set a multicast group address as the remote-ip in a VTEP entry. BUM traffic is sent to that multicast group; all VTEPs subscribed to the group receive it. The underlay network must support IP multicast routing (PIM or similar).
/interface vxlan add \
name=vxlan1 \
vni=10 \
local-address=198.51.100.1
/interface vxlan vteps add \
interface=vxlan1 \
remote-ip=239.1.1.10
All routers in the same VXLAN segment add a VTEP entry with the same multicast remote-ip. RouterOS accepts any address in the multicast range (224.0.0.0/4) as a remote-ip value.
Note: The multicast group address must be in the 224.0.0.0/4 range. Ensure your underlay routers have PIM-SM or IGMP snooping configured.
Without multicast, BUM traffic can be unicast-replicated to each known VTEP. This is functionally equivalent to point-to-point with multiple VTEP entries. Add all remote VTEPs to each router; RouterOS replicates BUM packets individually to each.
# Three-site ingress replication on Site A (198.51.100.1)
To extend a LAN across sites, add the VXLAN interface and local Ethernet ports to a bridge. The VXLAN interface acts as a virtual wire to the remote site.
Once both sides are up, hosts at Site A and Site B share the 10.10.10.0/24 subnet. ARP, DHCP broadcasts, and unknown unicast cross the VXLAN tunnel transparently.
Warning: Bridging two sites at L2 merges their broadcast domains. A broadcast storm at one site floods across the tunnel. Enable RSTP to prevent loops if there are redundant paths:
You should see UDP port 4789 packets between the two public IPs. If you see none, the firewall is blocking UDP 4789 or there is a routing issue in the underlay.
