Short answer: BGP EVPN is a control-plane protocol that advertises Ethernet and IP reachability between VXLAN tunnel endpoints. It lets a fabric distribute endpoint, subnet and multihoming information without relying on data-plane flooding for every learning event. EVPN carries reachability; VXLAN encapsulates the user traffic.
Why combine BGP EVPN and VXLAN?
VXLAN provides a Layer 2 overlay over an IP underlay. Each VTEP encapsulates frames in UDP/IP, while the underlay only needs IP reachability between VTEP loopbacks. EVPN uses MP-BGP to signal which VTEP can reach a MAC address, an IP address, or an IP prefix, and associates that information with an overlay segment such as a VXLAN Network Identifier (VNI).[1][2]
This separation is useful in leaf-spine data centers: the underlay routes infrastructure addresses; the overlay provides tenant segments and routing. BGP EVPN is not itself the encapsulation and does not forward packets.
EVPN route types you should recognize
- Type 1 — Ethernet Auto-Discovery: supports Ethernet-segment discovery and mass withdrawal, important for multihoming.
- Type 2 — MAC/IP Advertisement: advertises a learned MAC and optionally its IP, enabling remote VTEPs to forward known unicast toward the correct endpoint VTEP.
- Type 3 — Inclusive Multicast Ethernet Tag: signals membership for BUM (broadcast, unknown-unicast and multicast) handling in a VNI.
- Type 4 — Ethernet Segment: supports discovery of multi-homed Ethernet segments and designated-forwarder election.
- Type 5 — IP Prefix: advertises IP prefixes for inter-subnet routing and connectivity beyond locally learned endpoint routes.[1][4]
Exact implementation and route display vary by platform. A route type is a control-plane NLRI, not a promise that the corresponding forwarding entry is installed.
Packet walk: host-to-host across a VXLAN fabric
- Host A sends a frame to Host B. Its local leaf learns A locally and advertises a Type 2 MAC/IP route through EVPN.
- The remote leaf imports the route into the matching tenant/VNI context and resolves B's MAC to the advertising VTEP.
- The ingress leaf encapsulates the original Ethernet frame in VXLAN/UDP/IP, using the remote VTEP as the outer destination and the correct VNI.
- The routed underlay delivers the encapsulated packet. The egress VTEP removes the outer headers and forwards the inner frame.
For different IP subnets, the gateway leaf routes the packet. EVPN Type 5 routes can advertise IP prefixes between routing domains; distributed anycast gateways provide a consistent first-hop gateway address on participating leaves. Integrated routing and bridging behavior is described in RFC 9135.[3]
How EVPN affects traffic engineering
- Outbound within the fabric: route import policy, VNI/VRF association, local route preference and next-hop reachability determine which advertised endpoint or prefix is usable. BGP attributes can choose among eligible paths, but the forwarding table and encapsulation state must also be correct.
- Inbound toward a tenant or service: Type 5 advertisements, prefix policy and route selection can influence which fabric gateway attracts traffic. External networks still make their own routing decisions.
- What it cannot do: EVPN does not fix a broken IP underlay, create missing endpoint reachability, guarantee symmetric stateful-firewall paths, or make inconsistent VNI/VRF mappings work. BGP control-plane visibility alone does not prove data-plane reachability.
Configuration pattern (vendor-neutral)
Exact syntax differs, but a common design sequence is:
- Build an IP-routed underlay with reachability to every VTEP loopback.
- Enable BGP EVPN address-family peering between leaf VTEPs, often using route reflectors.
- Configure a VTEP source loopback and map each tenant bridge domain to a Layer 2 VNI; map routed tenant VRFs to Layer 3 VNIs where supported.
- Enable MAC/IP route advertisement and the intended anycast gateway behavior.
- Apply explicit import/export policy and verify route-target/VNI or VRF associations.
FRRouting-style illustrative fragment (syntax/features vary by release and platform):
router bgp 65001
bgp router-id 192.0.2.11
neighbor 192.0.2.1 remote-as 65001
neighbor 192.0.2.1 update-source lo
address-family l2vpn evpn
neighbor 192.0.2.1 activate
advertise-all-vni
exit-address-family
!
vrf TENANT-A
vni 10100
Treat this as a conceptual fragment, not a drop-in production configuration. Consult the target NOS documentation for peer-group, route-reflector, VNI, VRF and address-family syntax.
Verification commands and expected logic
On FRR, inspect show bgp l2vpn evpn summary for established peers, show bgp l2vpn evpn route for EVPN NLRIs, show evpn vni for VNI state, and show ip route/show ip nht for underlay next-hop resolution. On other platforms use the equivalent BGP EVPN, MAC-VRF/bridge-domain, VNI and forwarding-table commands.
Expected logic: the peer is Established; the remote MAC/IP or prefix route is present and imported into the intended tenant; its VTEP next hop resolves through the underlay; the local MAC/ARP and hardware forwarding entries point to the expected VNI and remote VTEP. Validate with a controlled ping and packet counters, not route output alone.
Troubleshooting checklist
- Are BGP EVPN sessions established, and is the EVPN address family activated?
- Can each leaf reach the remote VTEP loopback in the underlay?
- Does the route exist, and is it the expected Type 2 or Type 5 route?
- Do route targets, tenant VRF, bridge domain and VNI mappings match?
- Is the route rejected, hidden, or losing best-path selection due to policy?
- Is the remote VTEP next hop resolved and installed in hardware?
- Are MTU and UDP/4789 handling correct across the underlay?
- For BUM or multihoming issues, check Type 3/Type 1/Type 4 state and designated-forwarder behavior.
- For stateful services, inspect return-path symmetry, firewall/ NAT policy and gateway placement.
Modern fabric use
EVPN/VXLAN is used in leaf-spine data-center designs to distribute tenant L2/L3 reachability across a routed IP fabric. Cisco ACI and other policy-based fabrics have their own architecture and operational abstractions; do not assume every fabric exposes or configures EVPN exactly like a standards-based, manually managed BGP EVPN deployment. For cloud/on-prem connectivity, Type 5 or border-gateway routes may connect tenant routing domains, but advertise only intended prefixes and enforce explicit filtering.
Interview answer
Question: What does BGP EVPN do in a VXLAN fabric?
Answer: EVPN is the MP-BGP control plane that distributes MAC/IP and IP-prefix reachability, plus information needed for flooding and multihoming. VXLAN carries encapsulated data between VTEPs. I verify the EVPN route, tenant/VNI import, underlay next-hop resolution and actual forwarding entry separately.
Post a Comment