Build a BGP EVPN‑Based VXLAN Lab on Linux with FRR

VXLAN now has several control‑plane types:

Centralized SDN controller

IP multicast flooding and learning

Unicast‑based HER (Head‑End Replication) flooding and learning, where packets are replicated at the ingress VTEP and sent via unicast to all VTEPs that need the flood

The article focuses on the BGP EVPN (Ethernet Virtual Private Network) control plane, which is defined by RFC 7432 and supports three data‑plane technologies: MPLS, PBB, and NVO (Network Virtualization Overlay). VXLAN is one NVO solution, and its EVPN application is defined by RFC 8365. BGP EVPN relies on the BGP protocol and MP‑BGP extensions to distribute MAC addresses and their associated IP information.

Compared with other control‑plane options, EVPN offers several advantages:

No centralized SDN controller, simplifying deployment

Higher scalability, stability, and multi‑vendor interoperability

Fine‑grained traffic‑control policies

In an EVPN‑based VXLAN design, VTEPs are typically placed as first‑hop routers on ToR switches (or virtual switches on hypervisors). When a local switch learns a MAC address on a VLAN (via Gratuitous ARP or the first data packet), it stores the MAC in its FDB. Each local VLAN maps to a VNI. The local MP‑BGP process gathers VNI information and MAC addresses, then advertises them to other VTEPs using MP‑BGP.

Advertisement details:

VTEP information is announced via Type 3 routes

Local MAC addresses under each VNI are announced via Type 2 routes

Received routes are stored in the BGP table; if the route’s RT community matches the local VNI’s import RT, the MAC addresses are installed into the local FDB. This enables other VTEPs to build complete VXLAN FDB entries and forward traffic based on MAC, VNI, and destination VTEP.

<MAC> <VNI> <REMOTE VTEP>

Full‑mesh BGP sessions between every pair of VTEPs become cumbersome in large deployments, so a Route Reflector (RR) is commonly introduced. Each VTEP establishes a BGP session only with the RR, which then reflects routes to all other peers.

The open‑source FRRouting (FRR) project implements the EVPN protocol on Linux. The lab uses FRR on a dedicated RR VM and on two VTEP hosts.

In practice, EVPN can be deployed with either eBGP (different AS numbers per VTEP) or iBGP (same AS number). The lab uses iBGP with AS 65000 for all VTEPs.

FRR configuration on the RR (192.168.33.12):

router bgp 65000
  bgp router-id 192.168.33.12
  bgp cluster-id 192.168.33.12
  bgp log-neighbor-changes
  no bgp default ipv4-unicast
  neighbor fabric peer-group
  neighbor fabric remote-as 65000
  neighbor fabric capability extented-nexthop
  neighbor fabric update-source 192.168.33.12
  bgp listen range 192.168.33.0/24 peer-group fabric
  !
  address-family l2vpn evpn
    neighbor fabric activate
    neighbor fabric route-reflector-client
  exit-address-family
!
exit

Start FRR:

systemctl start frr

Configure VTEP hosts (Host1 192.168.33.15 and Host2 192.168.33.16). Example for Host1:

sysctl -w net.ipv4.ip_forward=1
ip netns add ns1
ip link add veth1 type veth peer name eth0 netns ns1
ip netns exec ns1 ip link set eth0 up
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip addr add 3.3.3.3/24 dev eth0
ip link set up dev veth1
ip link add br1 type bridge
ip link set br1 up
ip link set veth1 master br1
ip link add vxlan100 type vxlan id 100 dstport 4789 local 192.168.33.15 nolearning
ip link set vxlan100 master br1
ip link set up vxlan100

Host2 uses the same commands with its own IP addresses (3.3.3.4 and local 192.168.33.16).

Initial ping between the namespaces fails, indicating missing MAC/FDB entries.

# ip netns exec ns1 ping -c2 3.3.3.4
PING 3.3.3.4 (3.3.3.4) 56(84) bytes of data.
From 3.3.3.3 icmp_seq=1 Destination Host Unreachable
From 3.3.3.3 icmp_seq=2 Destination Host Unreachable
--- 3.3.3.4 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss

After configuring FRR on each VTEP (similar to the RR config but without the route‑reflector client), starting FRR, and establishing iBGP sessions, the ping succeeds.

# ip netns exec ns1 ping -c2 3.3.3.4
PING 3.3.3.4 (3.3.3.4) 56(84) bytes of data.
64 bytes from 3.3.3.4: icmp_seq=1 ttl=64 time=0.677 ms
64 bytes from 3.3.3.4: icmp_seq=2 ttl=64 time=0.731 ms
--- 3.3.3.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss

Verification commands on the RR:

# show bgp summary
L2VPN EVPN Summary:
BGP router identifier 192.168.33.12, local AS number 65000
Peers 2
*192.168.33.15 4 65000 ...
*192.168.33.16 4 65000 ...

EVPN routes received:

# show bgp evpn route
... (type‑2 and type‑3 prefixes for both VTEPs) ...

VXLAN interface details on Host1:

# show interface vxlan100
Interface vxlan100 is up, line protocol is up
VxLAN Id 100 VTEP IP: 192.168.33.15
Master interface: br1

MAC entries for VNI 100:

# show evpn mac vni 100
7a:bb:b4:6a:55:02 local veth1
e2:38:ad:ed:8f:9e remote 192.168.33.16
06:a7:49:0e:8b:48 local br1

Bridge FDB shows the remote MAC learned via EVPN:

# bridge fdb show dev vxlan100
e2:38:ad:ed:8f:9e vlan 1 extern_learn master br1
...

Reference links:

https://umairhoodbhoy.net/2014/10/29/head-end-replication-and-vxlan-compliance/

https://www.sdnlab.com/19717.html

https://vincent.bernat.ch/en/blog/2017-vxlan-bgp-evpn

https://vincent.bernat.ch/en/blog/2017-vxlan-linux