Why Is an iBGP Route Not Advertised to eBGP Peer R3?
Short answer
D IGP synchronization must be disabled on R2 so the 130.130.130.0/24 iBGP route is advertised to eBGP peer R3.
Question
Key Takeaways
This question tests the BGP synchronization rule — a router will not advertise an iBGP-learned route to an eBGP peer unless the prefix is validated by the IGP — and the trap is diagnosing the symptom as an outgoing filter list.
When 130.130.130.0/24 sits in R2's table but never reaches R3, the culprit is BGP synchronization withholding an iBGP-learned prefix from an eBGP peer, not a route filter. The fix is disabling IGP synchronization on R2 with "no synchronization" under router bgp.
Common mistake: Most candidates pick the incoming or outgoing filter-list option (B or C) because the symptom is described as "filtering," but no filter list is configured; the prefix is silently withheld by the synchronization requirement.
Expert Analysis
Why the Answer Is Correct
BGP synchronization states that a prefix learned from an iBGP neighbor cannot be advertised to an eBGP neighbor until that same prefix is also reachable through the IGP. In this scenario R2 holds 130.130.130.0/24 from an iBGP source, but the exhibit's show ip protocols output shows no IGP process running, so the route can never be validated internally and R2 withholds it from R3. That is exactly why R3 reports the prefix as filtered or missing rather than as a normal eBGP-learned path. Entering no synchronization under router bgp on R2 removes the IGP validation requirement and lets 130.130.130.0/24 be announced to R3 immediately. The behavior is legacy, but on IOS images where synchronization is enabled it still suppresses iBGP-to-eBGP advertisement.
Why the Other Options Are Wrong
Option A confuses BGP with EIGRP/RIP: BGP does not perform automatic classful summarization of 130.130.130.0/24 into 130.130.0.0/16, and a summary would not bypass the synchronization check anyway. Options B and C assume a filter list is responsible, but no distribute-list or filter-list is blocking the prefix — the suppression comes from synchronization, and the problem is what R2 sends, not what it receives. Option C is also directionally wrong: an incoming filter list on R2 changes what R2 accepts from neighbors, which cannot explain a route that R2 already has locally but R3 never sees. Only D targets the actual mechanism visible in the exhibit's protocol output.
Community Comment Notes
Every voter in this thread selected D, and their reasoning points at vendor documentation rather than mere consensus. Bombbear_W links Cisco's BGP case study and directs readers to the section titled "Unable to Announce iBGP-Learned Routes," which describes this exact symptom. DavideDL frames synchronization as an old rule from the days when iBGP was not run on every transit router, so a prefix that cannot be validated in the IGP is withheld. Pietjeplukgeluk records the fix directly, saying "you should DISABLE IGP synchronistation requirement" using no synchronization under router bgp. cutetruck ties it to the exhibit, noting that "no IGP is currently running" per the show ip protocols output, which is precisely why validation fails.
Official Reference
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html
This link opens the official vendor documentation in a new tab.
Exam Strategy
Whenever a prefix is present in the local BGP table but never appears on a downstream eBGP peer, check the protocol output for a running IGP and for the synchronization state before blaming filters. On 300-410, "present locally, missing downstream" plus no IGP running is a synchronization signature, and the answer is no synchronization under router bgp.
Frequently Asked Questions
Why is 130.130.130.0/24 withheld from R3 even though R2 has it in its table?
Does 'no synchronization' on R2 change how eBGP-learned routes are advertised?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 4 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 4
-
Bombbear_W 👍 8 Answered DThe answer is D https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html Scroll down to the "Unable to Announce iBGP-Learned Routes" section for the explaination.
-
DavideDL 👍 7 Answered DBGP synchronization is an old rule from the days when we didn’t run IBGP on all routers within a transit AS. In short, BGP will not advertise something that it learns from an IBGP neighbor to an EBGP neighbor if the prefix can’t be validated in its IGP.
-
Pietjeplukgeluk 👍 2 Answered DAfter some reading I agree, you should DISABLE IGP synchronistation requirement using "no synchronization" under the "router bgp ..."
-
cutetruck 👍 1 Answered DD is correct IGP synchronization only allows the router to advertise IBGP routes if its able to validate the route from an IGP. Since no IGP is currently running based on the "show ip protocols" output, we need to disable IGP synchronization.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All 300-410 Questions
Access 159 questions with complete answers and detailed explanations.
View Full 300-410 Practice Test →