VXLAN & EVPN Masterclass

The Networking tutorial showed you how to build a VXLAN tunnel by hand — create the interface, set a remote peer, done. The BIRD/BGP Masterclass showed you how BGP distributes routes across sites. This page combines both: EVPN is what happens when you give BGP control of your VXLAN fabric. Manual tunnels disappear. Peer discovery becomes automatic. MAC addresses propagate via routing protocol. This is how every serious data center and every cloud provider builds overlay networking.

1. From Manual VXLAN to an EVPN Fabric

2. VXLAN Recap — The Data Plane

Before adding EVPN, be clear on what VXLAN does and does not do by itself.

Encapsulation

VXLAN wraps an entire Ethernet frame inside a UDP packet. The outer packet routes across the underlay network (your physical LAN or WireGuard mesh). The inner packet is the original Layer 2 frame, including the MAC header. The receiving VTEP strips the outer headers and delivers the inner frame to a local bridge interface as if it arrived on a physical cable.

[ Physical NIC ]
  Outer Ethernet header  (VTEP-A MAC → VTEP-B MAC)
  Outer IP header        (VTEP-A IP  → VTEP-B IP)
  Outer UDP header       (src port ephemeral → dst port 4789)
  VXLAN header           (8 bytes: flags + 24-bit VNI)
    Inner Ethernet header  (VM-A MAC → VM-B MAC)
    Inner IP header        (10.0.100.2 → 10.0.100.5)
    Inner payload          (TCP, UDP, ICMP ...)

The 24-bit VNI (Virtual Network Identifier) is the VXLAN equivalent of a VLAN ID. It identifies which virtual network this frame belongs to. With 24 bits you get 16,777,216 possible VNIs — compared to 4,094 for 802.1Q VLANs.

Manual VXLAN (from the networking tutorial)

# Static VXLAN — the way you learned it in the Networking tutorial
# Node A: 192.168.1.10
ip link add vxlan100 type vxlan id 100 dstport 4789 local 192.168.1.10
ip link set vxlan100 up
ip addr add 10.0.100.1/24 dev vxlan100

# Manually add the remote peer (Node B at 192.168.1.20)
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.1.20

# Node B: 192.168.1.20
ip link add vxlan100 type vxlan id 100 dstport 4789 local 192.168.1.20
ip link set vxlan100 up
ip addr add 10.0.100.2/24 dev vxlan100
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 192.168.1.10

That 00:00:00:00:00:00 entry is the "flood entry" — any frame whose destination MAC is not yet known gets sent to that remote IP. It works for two nodes. The problem emerges the moment you add a third.

The scaling problem

With static VXLAN, every node must know about every other node. In a 50-node cluster, each node has 49 flood entries. When you add node 51, you log in to all 50 existing nodes and add a new entry. When a node changes IP, you update 49 entries. When a node fails, the flood entries remain until you manually remove them — so traffic keeps going to a dead VTEP, causing timeouts.

This is N×N configuration management. It is fragile, error-prone, and has no failure detection. It is the VXLAN equivalent of static routes in a dynamic network — fine for a lab, unusable in production.

3. What EVPN Adds to VXLAN

EVPN (RFC 7432, extended for VXLAN in RFC 8365) defines a BGP address family that carries Layer 2 reachability information. The key insight: instead of learning MAC addresses by flooding frames and watching who responds, VTEPs advertise their MAC and IP bindings into BGP. Every VTEP in the fabric learns the entire MAC table via BGP route updates.

4. EVPN with FRRouting on kldload

FRRouting is the natural choice for EVPN on kldload. It originated from Cumulus Linux — the company that pioneered BGP EVPN on commodity Linux hardware and contributed the EVPN kernel integration to mainline Linux. FRR handles both the BGP control plane (advertising and receiving EVPN routes) and the kernel programming side (populating the VXLAN FDB and ARP tables via netlink). You configure BGP + EVPN in vtysh; FRR and the kernel do the rest.

Install FRRouting

# CentOS Stream 9 / Rocky / RHEL
dnf install frr frr-pythontools

# Debian 13 / Ubuntu 24.04
apt install frr

# Enable the BGP and Zebra daemons
sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
sed -i 's/zebra=no/zebra=yes/' /etc/frr/daemons

systemctl enable --now frr

Example topology

Three kldload nodes, each a VTEP. They peer in a full-mesh iBGP (or use a route reflector for larger deployments). All nodes share VNI 100 (the 10.0.100.0/24 overlay network).

Node 1: underlay 192.168.1.10, loopback 10.255.0.1  (VTEP IP)
Node 2: underlay 192.168.1.20, loopback 10.255.0.2
Node 3: underlay 192.168.1.30, loopback 10.255.0.3
BGP AS: 65000 (iBGP full mesh)
VNI:    100   (overlay 10.0.100.0/24)

Kernel setup — identical on all three nodes (adjust IPs)

# Node 1 example
# Loopback address used as the VTEP source IP
ip addr add 10.255.0.1/32 dev lo

# VXLAN interface — no remote peer, no flood entry
# FRR will populate the FDB via netlink
ip link add vxlan100 type vxlan id 100 dstport 4789 \
  local 10.255.0.1 nolearning
ip link set vxlan100 up

# Bridge the VXLAN interface
ip link add br100 type bridge
ip link set vxlan100 master br100
ip link set br100 up
ip addr add 10.0.100.1/24 dev br100

The nolearning flag on the VXLAN interface is critical. It tells the kernel to not learn MACs by snooping traffic — that job belongs to FRR/EVPN now. Without nolearning, you get a race between kernel flood-and-learn and EVPN BGP learning, which causes forwarding inconsistencies.

FRR configuration — Node 1

! /etc/frr/frr.conf — Node 1 (10.255.0.1)

frr version 9.1
frr defaults traditional
hostname node1
log syslog informational
no ipv6 forwarding

interface lo
 ip address 10.255.0.1/32
!
interface eth0
 ip address 192.168.1.10/24
!

router bgp 65000
 bgp router-id 10.255.0.1
 no bgp default ipv4-unicast
 neighbor 10.255.0.2 remote-as 65000
 neighbor 10.255.0.2 update-source lo
 neighbor 10.255.0.3 remote-as 65000
 neighbor 10.255.0.3 update-source lo

 address-family l2vpn evpn
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.3 activate
  advertise-all-vni
 exit-address-family
!
line vty
!

The key directive is advertise-all-vni. This tells FRR to scan all VXLAN interfaces on the system, discover their VNIs, and automatically generate EVPN advertisements (Type 2 for local MACs/IPs, Type 3 for BUM handling). You do not need to enumerate each VNI manually — FRR discovers them from the kernel.

FRR configuration — Node 2 (10.255.0.2) and Node 3 (10.255.0.3)

! Node 2 — change router-id and neighbor IPs accordingly
router bgp 65000
 bgp router-id 10.255.0.2
 no bgp default ipv4-unicast
 neighbor 10.255.0.1 remote-as 65000
 neighbor 10.255.0.1 update-source lo
 neighbor 10.255.0.3 remote-as 65000
 neighbor 10.255.0.3 update-source lo

 address-family l2vpn evpn
  neighbor 10.255.0.1 activate
  neighbor 10.255.0.3 activate
  advertise-all-vni
 exit-address-family

Verify the EVPN fabric is working

# Check BGP peers are up
vtysh -c "show bgp summary"

# Show all EVPN routes received
vtysh -c "show bgp l2vpn evpn"

# Show Type 2 (MAC/IP) routes for VNI 100
vtysh -c "show bgp l2vpn evpn route type macip"

# Show Type 3 (multicast/BUM) routes
vtysh -c "show bgp l2vpn evpn route type multicast"

# Show the EVPN MAC table as seen by FRR
vtysh -c "show evpn mac vni 100"

# Show the kernel VXLAN FDB (should be populated by FRR)
bridge fdb show dev vxlan100

# Ping between overlay IPs to verify end-to-end
# (run a VM or namespace on the bridge on each node)
ping 10.0.100.2 -c 3

When it is working, bridge fdb show dev vxlan100 will show entries like:

aa:bb:cc:dd:ee:ff dst 10.255.0.2 self permanent
00:00:00:00:00:00 dst 10.255.0.2 self permanent
00:00:00:00:00:00 dst 10.255.0.3 self permanent

The specific MAC entry for aa:bb:cc:dd:ee:ff was populated by FRR from the BGP Type 2 route received from Node 2. The 00:00:00:00:00:00 entries (one per remote VTEP) are the ingress replication list built from Type 3 routes — BUM traffic is unicasted to each remote VTEP individually, no multicast needed.

5. EVPN with BIRD

BIRD 2.x added L2VPN EVPN support starting in 2.0.8. The configuration is more explicit than FRRouting's — BIRD does not auto-discover VNIs, so you define each one. BIRD also does not program the kernel FDB directly; you need a helper daemon (typically evpn-helper or a custom script using birdc and bridge fdb) to translate BIRD's EVPN table into kernel FDB entries. For most deployments, FRRouting is simpler. BIRD's strength is its flexible policy language — if you need complex route filtering and manipulation in addition to EVPN, BIRD can handle both in one config file.

BIRD 2.x EVPN configuration

# /etc/bird/bird.conf — BIRD 2.x EVPN example
# Node 1: router-id 10.255.0.1

router id 10.255.0.1;
log syslog all;

protocol device { scan time 10; }
protocol direct { ipv4; }

# iBGP with EVPN address family
protocol bgp node2 {
  local 10.255.0.1 as 65000;
  neighbor 10.255.0.2 as 65000;
  hold time 90;

  l2vpn evpn {
    import all;
    export all;
  };
}

protocol bgp node3 {
  local 10.255.0.1 as 65000;
  neighbor 10.255.0.3 as 65000;
  hold time 90;

  l2vpn evpn {
    import all;
    export all;
  };
}

# EVPN instance for VNI 100
protocol evpn vni100 {
  vni 100;
  rd 10.255.0.1:100;
  rt both 65000:100;

  interface "vxlan100";

  l2vpn evpn {
    import all;
    export all;
  };
}

When to use BIRD vs FRRouting for EVPN

6. Multi-Site EVPN over WireGuard

This is the full overlay stack: WireGuard encrypts the transport between sites, VXLAN provides the virtual Layer 2, and BGP EVPN automates peer discovery and MAC learning. VMs on different sites share the same Layer 2 segment without a single static peer entry.

Topology

Site A                              Site B
192.168.1.0/24                      192.168.2.0/24
Node A1: 192.168.1.10               Node B1: 192.168.2.10
VTEP loopback: 10.255.0.1           VTEP loopback: 10.255.1.1

WireGuard tunnel:
  wg0 on A1: 10.200.0.1/30
  wg0 on B1: 10.200.0.2/30

Overlay VNI 100: 10.0.100.0/24
  A1 bridge: 10.0.100.1
  B1 bridge: 10.0.100.2
  VMs: 10.0.100.10, 10.0.100.20 (anywhere on either site)

BGP: eBGP between sites (AS 65000 on Site A, AS 65001 on Site B)
     iBGP within each site (if multiple nodes per site)

Step 1 — WireGuard tunnel between sites

# On Node A1
cat /etc/wireguard/wg0.conf
# [Interface]
# Address = 10.200.0.1/30
# PrivateKey = <A1 private key>
# ListenPort = 51820
#
# [Peer]
# PublicKey = <B1 public key>
# Endpoint = <B1 public IP>:51820
# AllowedIPs = 10.200.0.2/32, 10.255.1.0/24
# PersistentKeepalive = 25

wg-quick up wg0

# On Node B1
# [Interface]
# Address = 10.200.0.2/30
# PrivateKey = <B1 private key>
# ListenPort = 51820
#
# [Peer]
# PublicKey = <A1 public key>
# Endpoint = <A1 public IP>:51820
# AllowedIPs = 10.200.0.1/32, 10.255.0.0/24
# PersistentKeepalive = 25

wg-quick up wg0

# Verify WireGuard is up
ping 10.200.0.2 -c 3   # from A1
ping 10.200.0.1 -c 3   # from B1

The AllowedIPs entries include the remote loopback subnet (10.255.1.0/24 for Site B, 10.255.0.0/24 for Site A). This ensures the VTEP loopback addresses — which are used as BGP update-source and VXLAN tunnel endpoints — are reachable over WireGuard.

Step 2 — VXLAN interfaces (both sites)

# Node A1
ip addr add 10.255.0.1/32 dev lo
ip link add vxlan100 type vxlan id 100 dstport 4789 local 10.255.0.1 nolearning
ip link set vxlan100 up
ip link add br100 type bridge
ip link set vxlan100 master br100
ip link set br100 up
ip addr add 10.0.100.1/24 dev br100

# Node B1
ip addr add 10.255.1.1/32 dev lo
ip link add vxlan100 type vxlan id 100 dstport 4789 local 10.255.1.1 nolearning
ip link set vxlan100 up
ip link add br100 type bridge
ip link set vxlan100 master br100
ip link set br100 up
ip addr add 10.0.100.2/24 dev br100

Step 3 — FRRouting EVPN with eBGP between sites

! Node A1 — AS 65000
router bgp 65000
 bgp router-id 10.255.0.1
 no bgp default ipv4-unicast

 ! eBGP peer to Site B
 neighbor 10.200.0.2 remote-as 65001
 neighbor 10.200.0.2 update-source wg0
 neighbor 10.200.0.2 ebgp-multihop 2

 address-family l2vpn evpn
  neighbor 10.200.0.2 activate
  advertise-all-vni
 exit-address-family
!

! Node B1 — AS 65001
router bgp 65001
 bgp router-id 10.255.1.1
 no bgp default ipv4-unicast

 ! eBGP peer to Site A
 neighbor 10.200.0.1 remote-as 65000
 neighbor 10.200.0.1 update-source wg0
 neighbor 10.200.0.1 ebgp-multihop 2

 address-family l2vpn evpn
  neighbor 10.200.0.1 activate
  advertise-all-vni
 exit-address-family
!

Step 4 — Verify cross-site EVPN

# On Node A1: check BGP peer to Site B
vtysh -c "show bgp summary"

# See Type 2 routes from Site B (MAC/IP of VMs on B1)
vtysh -c "show bgp l2vpn evpn route type macip"

# Confirm kernel FDB has remote Site B VTEP
bridge fdb show dev vxlan100 | grep 10.255.1.1

# Ping a VM on Site B from a VM on Site A
# (both VMs on 10.0.100.0/24, bridged to their local br100)
ping 10.0.100.20 -c 3

7. VXLAN + EVPN + Cilium

Cilium's VXLAN mode and BGP EVPN are complementary but operate at different layers. Understanding where each lives — and when to use each — is key to building a coherent multi-site Kubernetes networking architecture.

How Cilium uses VXLAN

In VXLAN mode, Cilium creates a single VXLAN interface (cilium_vxlan) and assigns a per-cluster VNI. Every pod's traffic is encapsulated in VXLAN when it leaves the node. The Cilium agent maintains the VXLAN FDB — it programs which pod CIDRs live on which node via its own internal state (derived from Kubernetes node annotations, not BGP EVPN). This is distinct from the EVPN control plane you configured in section 4: Cilium's VXLAN is self-contained within the cluster.

# Install Cilium in VXLAN tunnel mode
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set routingMode=tunnel \
  --set tunnelProtocol=vxlan \
  --set k8sServiceHost=10.80.0.1 \
  --set k8sServicePort=6443

# Verify tunnel mode
cilium status | grep -i tunnel
# Tunnel:         vxlan

VXLAN mode vs native routing mode

Cilium VXLAN over a WireGuard mesh

# 1. Deploy your WireGuard mesh first (from the WireGuard Masterclass)
# All Kubernetes nodes have a wg0 interface and can reach each other
# via WireGuard tunnel IPs (e.g., 10.200.0.0/24)

# 2. Install Cilium with VXLAN and WireGuard transparent encryption
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set routingMode=tunnel \
  --set tunnelProtocol=vxlan \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set k8sServiceHost=10.200.0.1 \
  --set k8sServicePort=6443

# Cilium manages its own WireGuard keys (per-node, auto-rotated)
# This is SEPARATE from your host WireGuard mesh
# You end up with: host WireGuard (site-to-site) + Cilium WireGuard (pod-to-pod)

# 3. Verify WireGuard encryption is active
cilium status | grep -i wireguard
# Encryption:     Wireguard

# Check which nodes have WireGuard peerings
cilium encrypt status

8. GENEVE — VXLAN's Successor

GENEVE (Generic Network Virtualization Encapsulation, RFC 8926) is the evolution of VXLAN. The wire format is similar — UDP encapsulation, 24-bit VNI — but GENEVE's header is variable-length and carries arbitrary TLV (Type-Length-Value) metadata. This extensibility is what VXLAN's fixed 8-byte header cannot provide.

GENEVE on Linux

# Create a GENEVE interface (note: GENEVE default port is 6081, not 4789)
ip link add geneve0 type geneve id 100 remote 192.168.1.20 dstport 6081
ip link set geneve0 up
ip addr add 10.0.100.1/24 dev geneve0

# With FRRouting, GENEVE works the same as VXLAN
# Just create the geneve interface instead of vxlan interface
# FRR advertises and programs it the same way

# Cilium can be installed with GENEVE instead of VXLAN:
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set routingMode=tunnel \
  --set tunnelProtocol=geneve

9. Performance Tuning

MTU — the most common VXLAN mistake

VXLAN adds 50 bytes of overhead to every packet (outer Ethernet 14 + outer IP 20 + outer UDP 8 + VXLAN header 8 = 50 bytes). WireGuard adds an additional 60 bytes (32-byte Poly1305 MAC + 28-byte transport header). If your physical MTU is 1500 and your inner MTU is also 1500, every packet that hits the MTU limit gets fragmented. Fragmentation is expensive — it requires the kernel to split and reassemble packets, burning CPU cycles and adding latency.

Physical MTU:            1500 bytes (standard Ethernet)

VXLAN only:
  VXLAN overhead:        50 bytes
  Inner MTU:             1450 bytes
  Set on bridge/VM:      ip link set br100 mtu 1450

VXLAN over WireGuard:
  VXLAN overhead:        50 bytes
  WireGuard overhead:    60 bytes
  Inner MTU:             1390 bytes
  Set on bridge/VM:      ip link set br100 mtu 1390

Jumbo frames (recommended for performance):
  Physical MTU:          9000 bytes (configure on switch + NICs)
  VXLAN overhead:        50 bytes
  Inner MTU:             8950 bytes
  Fragmentation:         never

# Set MTU on VXLAN interface and bridge
ip link set vxlan100 mtu 1450
ip link set br100 mtu 1450

# For VXLAN over WireGuard
ip link set vxlan100 mtu 1390
ip link set br100 mtu 1390
ip link set wg0 mtu 1420    # WireGuard itself needs headroom

# If your NIC and switch support jumbo frames:
ip link set eth0 mtu 9000
ip link set vxlan100 mtu 8950
ip link set br100 mtu 8950

# Verify no fragmentation is occurring
# Look for DF-bit drops or ICMP fragmentation-needed messages
ip -s link show vxlan100 | grep -i drop

Hardware offloading

# Check if your NIC supports VXLAN offloading
ethtool -k eth0 | grep -i vxlan
# tx-udp_tnl-segmentation: on
# tx-udp_tnl-csum-segmentation: on

# Most modern NICs (Intel X550, Mellanox ConnectX, Broadcom BCM57504)
# can offload VXLAN encap/decap in hardware
# When offloading is on, the NIC handles VXLAN headers in firmware
# CPU overhead drops significantly for high-throughput workloads

# Disable outer UDP checksum for performance
# (VXLAN inner checksum is enough; outer checksum is redundant on LAN)
ethtool -K eth0 tx-checksum-ip-generic off 2>/dev/null || true

# For VXLAN interface specifically
ethtool -K vxlan100 tx-checksum-ip-generic off 2>/dev/null || true

Kernel tuning for high VXLAN throughput

# Increase UDP socket buffer sizes for high-throughput VXLAN
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.core.rmem_default=16777216
sysctl -w net.core.wmem_default=16777216

# Enable RSS (Receive Side Scaling) if your NIC supports it
# VXLAN's outer UDP source port is hashed per-flow, enabling RSS
ethtool -X eth0 equal $(nproc)

# Persist in /etc/sysctl.d/10-vxlan.conf
cat > /etc/sysctl.d/10-vxlan.conf <<EOF
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216
EOF
sysctl -p /etc/sysctl.d/10-vxlan.conf

10. VNI Design — Mapping Networks to Identifiers

With 16,777,216 available VNIs, there is room for a structured allocation scheme. A thoughtful scheme makes VNI numbers self-documenting and simplifies troubleshooting — a packet capture showing VNI 203 immediately tells you it is Site B application traffic.

VNI allocation strategies

Concrete VNI scheme for a kldload multi-site deployment

11. Troubleshooting

VXLAN/EVPN failures fall into a small number of categories: the BGP session is down (EVPN routes not exchanged), the FDB is not populated (routes not translated to kernel state), the VTEP is unreachable (underlay connectivity problem), or MTU fragmentation is silently dropping large packets. Work through these in order.

Check BGP and EVPN state

# FRRouting: overall BGP status
vtysh -c "show bgp summary"
# Look for: State/PfxRcd — should show a number (routes received), not "Active" or "Idle"

# All EVPN routes in the table
vtysh -c "show bgp l2vpn evpn"

# Type 2 routes (MAC/IP bindings from remote VTEPs)
vtysh -c "show bgp l2vpn evpn route type macip"

# Type 3 routes (remote VTEP list for BUM traffic)
vtysh -c "show bgp l2vpn evpn route type multicast"

# EVPN VNI summary
vtysh -c "show evpn vni"

# EVPN MAC table for a specific VNI
vtysh -c "show evpn mac vni 100"

# EVPN neighbor (ARP) table — IP-to-MAC mappings
vtysh -c "show evpn arp-cache vni 100"

Check the kernel VXLAN state

# VXLAN forwarding database — populated by FRR from EVPN routes
bridge fdb show dev vxlan100
# Expected output:
# aa:bb:cc:dd:ee:ff dst 10.255.0.2 self permanent    ← specific MAC from Type 2 route
# 00:00:00:00:00:00 dst 10.255.0.2 self permanent    ← BUM entry from Type 3 route
# 00:00:00:00:00:00 dst 10.255.0.3 self permanent    ← BUM entry for another VTEP

# VXLAN interface details — verify VNI, local IP, port
ip -d link show vxlan100
# Look for: id 100, local 10.255.0.1, dstport 4789, nolearning

# Bridge MAC table — local MACs learned from attached VMs/namespaces
bridge fdb show br100

# ARP/neighbor table for the bridge IP
ip neigh show dev br100

Check underlay connectivity

# Can you reach the remote VTEP IP?
ping 10.255.0.2 -c 3

# If using WireGuard — is the WireGuard tunnel up?
wg show
# Look for: latest handshake within last few minutes
# If "latest handshake" is empty, the tunnel is down

# Is UDP 4789 (VXLAN) reachable between VTEP IPs?
# On the sending side:
nc -u -z 10.255.0.2 4789
# On the receiving side (to verify the port is open):
ss -ulnp | grep 4789

Packet capture — see VXLAN headers

# Capture VXLAN traffic on the physical interface
# This shows the OUTER headers (VTEP-to-VTEP)
tcpdump -i eth0 -n udp port 4789 -v

# To see the inner Ethernet frames decoded:
tcpdump -i eth0 -n udp port 4789 -v -X | head -100

# Capture on the bridge interface — see the INNER frames (post-decap)
tcpdump -i br100 -n -v

# If using WireGuard, capture on wg0 to see decrypted VXLAN traffic
tcpdump -i wg0 -n udp port 4789 -v

Common failure modes and fixes

12. The Complete Overlay Stack

Every concept in this masterclass is a layer in a single coherent architecture. Understanding each layer independently is useful. Understanding how they compose is what lets you build and operate a real fabric.

Application (VM / container / pod)
       |
   [ Bridge / br100 ]            ← Layer 2 domain for the VNI
       |
   [ VXLAN interface ]           ← Encapsulation: inner Ethernet in outer UDP/4789
       |   ↑ FDB programmed by FRR EVPN (MAC/VTEP bindings)
       |   ↑ ARP suppression: local VTEP answers ARPs from BGP knowledge
       |
   [ BGP EVPN (FRRouting) ]      ← Control plane: Type 2/3/5 route exchange
       |   ↑ distributes MAC, IP, VTEP reachability automatically
       |
   [ WireGuard (wg0) ]           ← Encrypted transport: inter-site and/or inter-node
       |   ↑ VTEP loopbacks reachable via WireGuard AllowedIPs
       |
   [ Physical NIC (eth0) ]       ← Underlay: your LAN, DC fabric, or internet

Cilium slots into this stack above the bridge, handling pod-to-pod policy and encapsulation within a Kubernetes cluster:

Pod (container)
       |
   [ Cilium eBPF dataplane ]     ← Identity-based L3/L4/L7 policy, kube-proxy replacement
       |   ↑ VXLAN or GENEVE encapsulation (Cilium-managed VNI)
       |   ↑ WireGuard per-node encryption (Cilium-managed keys)
       |
   [ Host network stack ]        ← Where FRR EVPN and host WireGuard live
       |
   [ Physical NIC ]

Comparison: manual VXLAN vs EVPN vs Cilium VXLAN vs cloud VPC

Related pages

• Networking tutorial — manual VXLAN, bridges, namespaces
• BIRD/BGP Masterclass — BGP fundamentals, FRRouting, route filtering
• Cilium Masterclass — eBPF dataplane, kube-proxy replacement, Hubble
• WireGuard Masterclass — the encryption underlay layer
• WireGuard Mesh & Multi-Site — building the four-plane mesh
• Kubernetes on KVM — the cluster that Cilium VXLAN runs on