nerdexam
Cisco

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.

Layer 3 Control Plane

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)
  • A
    8% (3)
  • B
    46% (18)
  • C
    13% (5)
  • D
    33% (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.

AAdvertise via a non-backbone OSPF area IP addresses used on eBGP peer statements.

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.

BAdvertise via eBGP IP addresses used on eBGP peer statements.Correct

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.

CDisable BGP synchronization.

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.

DUse an ACL to block BGP in one direction.

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

#eBGP#OSPF#BGP peer stability#route advertisement

Community Discussion

No community discussion yet for this question.

Full 352-001 Practice