352-001 · Question #475
A network is designed to use OSPF to reach eBGP peers. Which condition should be avoided so that the eBGP peers do not flap continuously in case of link failure?
The correct answer is B. Advertise via eBGP IP addresses used on eBGP peer statements. Advertising eBGP peer IP addresses via eBGP itself creates a recursive routing dependency that causes continuous session flapping when a link fails.
Question
A network is designed to use OSPF to reach eBGP peers. Which condition should be avoided so that the eBGP peers do not flap continuously in case of link failure?
Options
- AAdvertise via a non-backbone OSPF area IP addresses used on eBGP peer statements.
- BAdvertise via eBGP IP addresses used on eBGP peer statements.
- CDisable BGP synchronization.
- DUse an ACL to block BGP in one direction.
How the community answered
(39 responses)- A8% (3)
- B46% (18)
- C13% (5)
- D33% (13)
Why each option
Advertising eBGP peer IP addresses via eBGP itself creates a recursive routing dependency that causes continuous session flapping when a link fails.
Advertising eBGP peer addresses via a non-backbone OSPF area is an acceptable design because OSPF provides IGP reachability that is independent of the BGP session, avoiding the recursive dependency that causes flapping.
If the IP address used in an eBGP peer statement is reachable only via a BGP-learned route, a link failure drops the BGP session, which in turn withdraws the BGP route to the peer, making the peer unreachable and preventing session re-establishment - creating a continuous flap cycle. Peer addresses should instead be reachable via the IGP (OSPF in this design) so that reachability to the peer persists independently of the BGP session state, breaking the recursive dependency.
Disabling BGP synchronization removes the requirement for iBGP routes to be present in the IGP before being advertised to eBGP peers, which is a separate concern unrelated to peer reachability flapping caused by recursive route dependencies.
Using an ACL to block BGP in one direction would prevent the session from forming entirely rather than cause flapping, and it is not a relevant design consideration for this reachability scenario.
Concept tested: eBGP peer reachability and recursive routing dependency
Source: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13701-29.html
Topics
Community Discussion
No community discussion yet for this question.