An network is designed to use OSPF to reach eBGP peers. Which condition should be avoided in the design to potentially prevent the eBGP peers do not flap continuously in case of link failure?

Question

Options

• ADisable BGP synchronization.
• BAdvertise IP addresses used on eBGP peer statement via a non-backbone OSPF area.
• CAdvertise via eBGP IP addresses used on eBGP peer statements.
• DUse an ACL to block BGP in one direction.

• A
  10% (4)
• B
  20% (8)
• C
  66% (27)
• D
  5% (2)

Explanation

Advertising eBGP peer statement addresses back into eBGP (option C) creates a recursive dependency: the BGP session must be up to learn the route needed to bring the session back up after a link failure. When the link fails, the BGP session drops, the eBGP-learned route to the peer withdraws, and the session cannot re-establish - causing continuous flapping. OSPF should be the sole mechanism for reaching eBGP peer addresses, keeping that reachability independent of BGP state.

Why the distractors are wrong:

• A - Disabling BGP synchronization is actually standard practice and eliminates a different problem (sync was used to prevent black-holing in transit ASes); it has no bearing on peer flapping caused by route dependency.
• B - Using a non-backbone OSPF area to carry peer addresses is not inherently harmful; OSPF (any area) providing reachability is exactly the right approach - it keeps reachability independent of the BGP session itself.
• D - Blocking BGP with an ACL in one direction would simply break BGP entirely, not address flapping caused by recursive route lookup.

Memory tip: "Don't let BGP hold the keys to its own house." If the route to a BGP peer is learned through that same BGP session, the session can never self-heal - always use your IGP (OSPF here) to advertise peer addresses so reachability survives a BGP failure.

No community discussion yet for this question.