Hands-On Lab: Configuring VXLAN with BGP EVPN Control Plane

This hands-on lab replaces the static head-end replication from the previous lab with a BGP EVPN control plane, allowing VTEPs to dynamically learn each other's MAC and IP information rather than relying on manually configured peer lists.

VXLAN BGP EVPNDynamic VTEP DiscoveryMAC-IP Route Type 2

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure BGP with the L2VPN EVPN address family between two VTEPs, replacing static peer configuration with dynamic route exchange, and verify MAC and IP reachability information for hosts is learned automatically through EVPN routes rather than manual configuration.

Lab Purpose

The static head-end replication configured in the previous lab requires manually listing every peer VTEP for every VNI — impractical once a fabric grows beyond a handful of switches. BGP EVPN provides a proper control plane, letting VTEPs advertise their local MAC and IP information via BGP so peers learn reachability dynamically, the same way IP routing information is learned rather than manually configured.

Lab Topology

Switch1 (VTEP), Switch2 (VTEP)
Same physical/VNI setup as the previous
lab, but static peer-ip and mcast-group
static configuration removed

Both switches: AS 65100 (single-AS
underlay for this lab, iBGP EVPN)

Task 1: Remove the Static Peer Configuration

Remove the static peer-ip and mcast-group static commands from the previous lab's NVE interface configuration.

Task 2: Configure BGP with the L2VPN EVPN Address Family

Enable BGP between the two VTEPs' loopback addresses, activating the L2VPN EVPN address family specifically.

Task 3: Configure the NVE Interface to Use BGP EVPN

Update the NVE interface to source VNI membership information from the EVPN control plane rather than static configuration.

Task 4: Verify the EVPN Session Establishes

Confirm the BGP EVPN neighbor relationship reaches Established state.

Task 5: Verify MAC/IP Information Is Learned Dynamically

Generate traffic from HostA and confirm Switch2 learns HostA's MAC and IP via an EVPN Type 2 route, without any static configuration referencing HostA.

Solution and Verification

Switch1(config)# interface nve1
Switch1(config-if)# no member vni 10100 mcast-group static
Switch1(config-if)# no member vni 10100 ingress-replication protocol static

Switch2(config)# interface nve1
Switch2(config-if)# no member vni 10100 mcast-group static
Switch2(config-if)# no member vni 10100 ingress-replication protocol static

Switch1(config)# router bgp 65100
Switch1(config-router)# neighbor 10.0.0.2 remote-as 65100
Switch1(config-router)# neighbor 10.0.0.2 update-source loopback0
Switch1(config-router)# address-family l2vpn evpn
Switch1(config-router-af)# neighbor 10.0.0.2 activate

Switch2(config)# router bgp 65100
Switch2(config-router)# neighbor 10.0.0.1 remote-as 65100
Switch2(config-router)# neighbor 10.0.0.1 update-source loopback0
Switch2(config-router)# address-family l2vpn evpn
Switch2(config-router-af)# neighbor 10.0.0.1 activate

Switch1(config)# interface nve1
Switch1(config-if)# member vni 10100

Switch2(config)# interface nve1
Switch2(config-if)# member vni 10100

-- With no static peer-ip or mcast-group
-- specified, the NVE interface now relies
-- entirely on the BGP EVPN control plane
-- to learn about remote VTEPs and their
-- VNI membership

Switch1# show bgp l2vpn evpn summary

Neighbor    V   AS    MsgRcvd  MsgSent  State/PfxRcd
10.0.0.2    4   65100   12       11        1
-- Established, with EVPN routes already
-- being exchanged

HostA> ping HostB
-- (traffic generated to populate MAC/ARP
--  tables and trigger EVPN advertisement)

Switch2# show bgp l2vpn evpn

   Network                Next Hop        Path
Route Distinguisher: 10.0.0.1:100
*>i [2]:[0]:[48]:[00aa.bb00.aaaa]:[32]:[192.168.100.10]
                          10.0.0.1        i
-- This is an EVPN Type 2 (MAC/IP
-- Advertisement) route -- Switch2 learned
-- HostA's MAC (00aa.bb00.aaaa) and IP
-- (192.168.100.10) directly from Switch1
-- via BGP, with no static reference to
-- HostA anywhere in Switch2's configuration

Switch2# show nve peers

Interface  Peer-IP    State
nve1       10.0.0.1   Up
-- The peer relationship itself is also
-- now dynamically established through
-- EVPN, rather than the static peer-ip
-- statement used in the previous lab

Key Takeaway

BGP EVPN Type 2 routes carry both a host's MAC address and its IP address in a single advertisement, allowing a receiving VTEP to build both its Layer 2 forwarding table and ARP suppression cache from the same piece of information — this dynamic learning is what allows VXLAN fabrics to scale to hundreds of VTEPs and thousands of endpoints without the linear increase in manual configuration that the static head-end replication from the previous lab would otherwise require.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه