The CWX EVPN fabric interconnects four geographically distributed sites using an EVPN-VXLAN overlay transported over a WireGuard full‑mesh underlay. The fabric includes two MikroTik RouterOS sites that host physical VLANs, and two VyOS-based datacenter locations that extend these VLANs without hosting them locally.
This document describes the exact behavior, topology, bridging model, and routing logic used across all locations.
Role: EVPN/VXLAN edge, physical VLAN host
Physical VLANs hosted here:
Bridge model:
A single central bridge br-core that contains:
vlan11 (physical)vlan14 (physical)vxlan10, vxlan11, vxlan14, vxlan30, vxlan200, vxlan600)EVPN behavior:
Role: EVPN/VXLAN edge, physical VLAN host
Physical VLANs hosted here:
Bridge model:
A single central bridge br-core with:
vlan10, vlan30, vlan200, vlan600 (physical)vxlan10, vxlan11, vxlan14, vxlan30, vxlan200, vxlan600)EVPN behavior:
Role: EVPN transit / remote VLAN extension
Physical VLANs hosted: None
Bridge model:
VyOS uses per‑VLAN bridges, for example:
br10 = vxlan10 + eth2 (vmbr10)
br11 = vxlan11 + eth2 (vmbr11)
br14 = vxlan14 + eth2 (vmbr14)
br30 = vxlan30 + eth2 (vmbr30)
br200 = vxlan200 + eth2 (vmbr200)
br600 = vxlan600 + eth2 (vmbr600)
EVPN behavior:
Role: Same as RBX**
| VLAN | VNI | Hosted At |
|---|---|---|
| 10 | 10 | Vukomerec (MTK) |
| 11 | 11 | Dugave (MTK) |
| 14 | 14 | Dugave (MTK) |
| 30 | 30 | Vukomerec (MTK) |
| 200 | 200 | Vukomerec (MTK) |
| 600 | 600 | Vukomerec (MTK) |
All EVPN/BGP sessions run over loopback‑to‑loopback (10.100.255.x/32) via WireGuard tunnels between all sites.
WireGuard is NOT the source address.
Loopbacks are used as:
This ensures stable overlay behavior even if physical links flap.
All 4 routers are connected in a full-mesh eBGP EVPN topology:
Dugave ↔ Vukomerec
Dugave ↔ RBX
Dugave ↔ Hetzner2
Vukomerec ↔ RBX
Vukomerec ↔ Hetzner2
RBX ↔ Hetzner2
Each peer exchanges EVPN address-family routes:
Effectively a “superbridge” that handles all L2 traffic.
This is the ideal EVPN architecture.
Only MikroTik sites originate:
VyOS sites only forward and re-advertise learned EVPN routes.
A VNI behaves as “local” only on the MikroTik router that hosts its physical VLAN.
Example:
All other sites treat those VNIs as VXLAN extensions.
The CWX EVPN fabric spans four sites interconnected by WireGuard tunnels using a full‑mesh eBGP EVPN control plane. Two MikroTik sites (Dugave, Vukomerec) host physical VLANs and use a unified br-core bridge containing all VLAN and VXLAN interfaces. Two VyOS sites (RBX, Hetzner2) host no VLANs and implement a per‑VLAN bridging architecture that cleanly maps VXLAN VNIs to Proxmox bridge interfaces.
MikroTik sites originate EVPN Type‑2 and Type‑3 routes for the VLANs they physically host, while VyOS sites dynamically learn all MAC and IMET routes and extend them to their respective local bridges. This design enables a consistent, multi-site L2 fabric with correct VLAN-to-VNI mapping across all locations.
In the future, the CWX EVPN network will incorporate a distributed anycast gateway design to provide redundant first‑hop routing for all VLANs stretched across the EVPN fabric.
An anycast gateway allows multiple routers across multiple sites to share the same default gateway IP/MAC for a given VLAN.
The EVPN control plane ensures that:
For each VLAN (e.g., 10, 11, 14, 30, 200, 600):
Example (future):
Gateway IP: 10.10.0.1
Gateway MAC: 00:00:5E:00:01:01 (or vendor-agnostic MAC)
Routers participating in gateway forwarding for VLAN10:
As long as each router attaches br10 (VyOS) or vlan10 (MTK) with an IRB interface, all can serve as L3 go-to points.
Anycast Gateway (shared IP/MAC)
/ | Dugave Vukomerec RBX Hetzner2
\ | /
EVPN Type-2/3 Control Plane
This ensures host default gateway remains available from any site and supports live VM mobility and cross-site redundancy.
This section is future-facing and can be implemented when MikroTik gains stable IRB functionality or if IRB is selectively done on VyOS sites first.