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