300-410 Practice Question: An engineer configures iBGP between two routers…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The BGP next-hop is not reachable because the IGP does not advertise it, and no static route exists.

  Why this is correct

  When an eBGP speaker advertises a route to an iBGP peer, the next hop remains the IP address of the external neighbor unless next-hop-self is configured. The iBGP router must have a route in its IGP (or a static route) to that exact next-hop address before BGP will consider the path valid and install it into the routing table. Because neither an IGP advertisement nor a static route exists for that address, BGP marks the path as unreachable and withholds it from the RIB, even though the prefix appears in the BGP table.

• ✗

  The BGP synchronization rule is enabled, causing the route to be suppressed until the IGP learns it.

  Why it's wrong here

  BGP synchronization is an outdated rule that requires an iBGP-learned prefix to also be present in the IGP before it is used for forwarding. However, modern IOS versions disable synchronization by default, and the rule checks the reachability of the prefix itself, not the reachability of the next-hop. Even if synchronization were enabled, it would suppress the route because the IGP does not carry the exact prefix, which is not the issue in this scenario; the root cause is the unreachable next-hop address.

• ✗

  The next-hop-self command is missing on the eBGP neighbor, so the iBGP router sees the external next-hop.

  Why it's wrong here

  The missing next-hop-self command is not the cause here. In eBGP sessions, the next hop is always set to the IP address of the eBGP neighbor, and next-hop-self is typically configured on iBGP neighbors to override the external next-hop with the router's own address. Even if next-hop-self were applied, the iBGP router would still need a route to that newly advertised next-hop (e.g., the loopback of the iBGP peer). Because neither the IGP nor a static route provides reachability to the external next-hop, the route remains invalid regardless of the next-hop-self setting.

• ✗

  The BGP table shows the route as valid, but the routing table does not install it due to administrative distance.

  Why it's wrong here

  Administrative distance is used to compare routes from different protocols when multiple valid routes to the same prefix exist. BGP only enters the RIB after passing all validity checks, including the reachability of its next hop. If the next hop is unreachable, the route is never inserted into the routing table, so the router never gets to the point of comparing administrative distances. Even if a static or IGP route to the prefix exists, the BGP route would be ignored due to its higher AD only after next-hop reachability is confirmed — which is not the case here.

Go deeper

Related to this question