Posted on November 4, 2019 5:53 pm
 |  Asked by Jon Nicholson
Print Friendly, PDF & Email

I’m building an EVPN test network using GNS3 (v2.2.0) and vEOS-lab images ( basing the configuration on the EVPN Deployment guide.

I’ve built a network with 2 pairs of leaf switches & a pair of spine switches (see image).

The Underlay BGP network is established fine, and I can reach the endpoints correctly. However when I try and establish the eVPN overlay peerings between the leaf switches and the spines some links never proceed beyond ‘OpenConfirm’ state.

spine1(config-router-bgp)#show bgp evpn summary
BGP summary information for VRF default
Router identifier, local AS number 65000.0
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc 4 65000.1 1 2 0 0 00:00:16 OpenConfirm 4 65000.1 4 4 0 0 00:00:16 Estab 0 0 4 65000.2 3 4 0 0 00:00:11 Estab 0 0 4 65000.2 1 2 0 0 00:00:11 OpenConfirm

Here the route to the loopback ( from the spine to the leaf is being learned as ecmpr via both leaf switches:-

spine1(spine1(config-router-bgp)#show ip bgp
BGP routing table information for VRF default
Router identifier, local AS number 65000.0
BGP routing table entry for
Paths: 2 available
65000.1 from (
Origin IGP, metric -, localpref 100, weight 0, received 00:00:29 ago, valid, external, ECMP head, ECMP, best, ECMP contributor
Rx SAFI: Unicast
65000.1 from (
Origin IGP, metric -, localpref 100, weight 0, received 00:00:28 ago, valid, external, ECMP, ECMP contributor
Rx SAFI: Unicast
config-router-bgp)#show ip route

VRF: default
Codes: C – connected, S – static, K – kernel,
O – OSPF, IA – OSPF inter area, E1 – OSPF external type 1,
E2 – OSPF external type 2, N1 – OSPF NSSA external type 1,
N2 – OSPF NSSA external type2, B – BGP, B I – iBGP, B E – eBGP,
R – RIP, I L1 – IS-IS level 1, I L2 – IS-IS level 2,
O3 – OSPFv3, A B – BGP Aggregate, A O – OSPF Summary,
NG – Nexthop Group Static Route, V – VXLAN Control Service,
DH – DHCP client installed default route, M – Martian,
DP – Dynamic Policy Route, L – VRF Leaked

B E [200/0] via, Ethernet1
via, Ethernet2

(e1 is connection to leaf1a e2 is connection to leaf1b)

If I weight the route so that there is only one path (via the direct connection rather than via the iBGP peering) everything comes up as I would expect.

Is this expected? (am I misunderstanding something)
Is it an artefact of the GNS3 software or the vEOS image?
or is there something else wrong….

I’m attaching my configuration files for the 6 switches.
(in the configuration files the route-map spine-leaf is applied to weight the routes from iBGP)


Posted by Vikram
Answered on November 4, 2019 6:20 pm

Hi Jon,

Since its openconfirm state it indicates that your keepalives might not be making it back from spine1< =>leaf1. You could take a packet capture or alternatively disable the direct link and see if you are able to establish peering to confirm but it seems that you do not have ebgp-multihop on spine1 for your peer-group evpn-overlay. I see you have `ebgp-multihop 3` configured on the leaf side for the peer-group evp-overlay but I don't see it on spine1 and I believe that might be the issue. Pls do let us know if this resolves the issue. HTH

Posted by Aesha Parikh
Answered on November 4, 2019 6:52 pm

Hi Jon,

Looking at the spine configs, I see ebgp multi hop is missing for EVPN overlay peers.

neighbor evpn-overlay peer-group
neighbor evpn-overlay next-hop-unchanged
neighbor evpn-overlay update-source Loopback0
neighbor evpn-overlay fall-over bfd
neighbor evpn-overlay password 7
neighbor evpn-overlay send-community
neighbor evpn-overlay maximum-routes 12000


Post your Answer

You must be logged in to post an answer.