Building BGP EVPN VXLAN datacenter fabric – Part 4 (Overlay BGP EVPN configuration)

Quick Intro

In essence, BGP is used here to support Ethernet VPN (EVPN) deployment and it is responsible for control-plane operations to advertise all necessary routing information for both Layer2 and Layer3 services. Replace traditional flood-and-learn techniques with a more scalable and manageable approach.

Also, BGP is responsible for the Overlay Network to support VTEP-to-VTEP communication to help with the distribution of mappings between VTEP (VXLAN Tunnel Endpoint) IPs and VNIs (VXLAN Network Identifier)


There are multiple approaches to configuring BGP for the traditional leaf-spine network DC topology. In this case, I’ll be using iBGP, which will run with the help of OSPF, which I configured in a previous part.

iBGP usage will require me to configure my Spine switches as route-reflectors and leaf switches as route-reflector clients to overcome the iBGP loop prevention mechanism.

Spine switch configuration:

  • feature bgp – required to enable BGP routing protocol support on the Nexus switch
  • nv overlay evpn – command allows to configure BGP neighbors as L2VPN EVPN peers
feature bgp

router bgp 65000
  router-id 10.255.255.1
  address-family l2vpn evpn
    maximum-paths ibgp 4
    advertise-pip
  template peer LEAF
    remote-as 65000
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.255.255.3
    inherit peer LEAF
  neighbor 10.255.255.4
    inherit peer LEAF
  neighbor 10.255.255.5
    inherit peer LEAF
  neighbor 10.255.255.6
    inherit peer LEAF
  neighbor 10.255.255.7
    inherit peer LEAF
  neighbor 10.255.255.8
    inherit peer LEAF

Same configuration should be applied to the second Spine with an exception of router-id

Leaf switch configuration

Just like with Spine switch configuration I’ll be using similar template configuration excluding route-reflector client keyword

feature bgp
nv overlay evpn

router bgp 65000
  router-id 10.255.255.3
  address-family l2vpn evpn
    maximum-paths ibgp 4
    advertise-pip
  template peer SPINE
    remote-as 65000
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.255.1
    inherit peer SPINE
  neighbor 10.255.255.2
    inherit peer SPINE

The configuration above will be repeated on every LEAF switch in my topology with necessary change to the router-id

Verification:

After all configuration was applied the SPINE switches will show the following neighbors in the output:

dc01-spine01# show bgp l2vpn evpn summary 
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.255.255.1, local AS number 65000
BGP table version is 8, L2VPN EVPN config peers 6, capable peers 6
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.255.3    4 65000      26      25        8    0    0 00:18:57 0         
10.255.255.4    4 65000      13      13        8    0    0 00:07:36 0         
10.255.255.5    4 65000      13      13        8    0    0 00:07:07 0         
10.255.255.6    4 65000      12      12        8    0    0 00:06:25 0         
10.255.255.7    4 65000      11      11        8    0    0 00:05:39 0         
10.255.255.8    4 65000      11      11        8    0    0 00:05:03 0     

Respectively LEAF switches will display two SPINE switches as a neighbors:

dc01-r01-leaf01# show bgp l2vpn evpn summary 
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.255.255.3, local AS number 65000
BGP table version is 6, L2VPN EVPN config peers 2, capable peers 2
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.255.1    4 65000      27      28        6    0    0 00:21:17 0         
10.255.255.2    4 65000      28      28        6    0    0 00:21:17 0         
dc01-r01-leaf01# 

This part completes the requirements for the peering between VTEPs, where OSPF will deliver L3 reachability between VTEP peers and iBGP will be responsible for the control-plane information delivery

Leave a comment