BGP Routers eBGP neighborship Flapping in eve-ng/GNS3

[net-wade-332]

I have connected routers in eve-ng as attached image. 5 routers forming a circle. R6 > R7 > R8 > R9 > R10 > R6. Why this topology ? To exercise on route-maps/prefix list. 

each router having own AS and forming ebgp-neighborship with adjacent routers using loopback. used /29 between P2P.  Used OSPF with 0.0.0.0 network for IGP.
R6#show run | sec ospf
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
R6#show run | sec bgp
router bgp 1
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 5
neighbor 2.2.2.2 update-source Loopback1
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 5
neighbor 5.5.5.5 update-source Loopback1

now eBGP neighborship is flapping between adjacent routers within every 1-4 minutes, time duration is not constant. not sure what might be wrong, never faced this before. Can you please help ? Is it bug or something. I tried GNS3/Eve-ng and used vIOS/Dynamips both but issue is consistent.

*Mar 17 01:45:53.943: %BGP-5-NBR_RESET: Neighbor 5.5.5.5 reset (BGP Notification sent)
*Mar 17 01:45:53.943: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Down BGP Notification sent
*Mar 17 01:45:53.943: %BGP_SESSION-5-ADJCHANGE: neighbor 5.5.5.5 IPv4 Unicast topology base removed from session BGP Notification sent
*Mar 17 01:46:01.171: %BGP-5-ADJCHANGE: neighbor 5.5.5.5 Up

[M02@rt37]

Hello @net-wade-332 

Please do on R6

show bgp ipv4 unicast neighbors 5.5.5.5

Share here output please. Look for "Last reset reason" in the output.

[balaji.bandi]

Configuring OSPF in this topology, for every router in area 0, is a bad idea.

Is this OSPF stable and able to get all the routing visibility?

[Harold Ritter · Accepted solution]

Hi @net-wade-332 ,

The issue in this specific scenario is that you are advertising the loopback of each router via eBGP and OSPF. This loopback is used to establish the eBGP session. Once the eBGP session is up, the loopback interface for the neighbor will start being learnt via eBGP. It will be installed in the RIB as the eBGP administrative distance (20) is better than the ospf AD (110). This causes a looped recursive route (i.e. 2.2.2.2 learnt via 2.2.2.2). The neighbor becomes unreachable and the eBGP session goes down after the BGP hold down timer expires (180 sec by default).

The eBGP session is then reestablished using the OSPF route and there we go again.

[net-wade-332]

Appreciate the time. Thanks for the help. This is correct solution

[Harold Ritter]

You are very welcome @net-wade-332 and thanks for the feedback