Why Is an iBGP Route Not Advertised to eBGP Peer R3?

Troubleshoot BGP (Internal and External, unicast, and VRF-Lite)

Answer Correct answer: D — IGP synchronization must be disabled on R2 so the 130.130.130.0/24 iBGP route is advertised to eBGP peer R3.

Refer to the exhibit. The 130.130.130.0/24 route shows in the R2 routing table but is getting filtering toward R3. Which action resolves the issue? -

Automatic route summarization must be enabled on R2.
The outgoing filter list for all interfaces must be set on R2.
The incoming filter list for all interfaces must be set on R2.
IGP synchronization must be disabled on R2. Correct Answer

Community Votes

100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

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.

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.

Community Discussion (4 comments)

Bombbear_W 👍 8 Selected: D

The 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 Selected: D

BGP 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.

cutetruck 👍 1 Selected: D

D 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.

Pietjeplukgeluk 👍 2 Selected: D

After some reading I agree, you should DISABLE IGP synchronistation requirement using "no synchronization" under the "router bgp ..."

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

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

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?

BGP synchronization blocks advertising an iBGP-learned prefix to an eBGP peer until it is validated in the IGP; with no IGP running on R2, that validation never happens.

Does 'no synchronization' on R2 change how eBGP-learned routes are advertised?

No. The command only removes the IGP validation requirement for iBGP-learned prefixes, so routes R2 learns directly from eBGP peers are still advertised normally.

More 300-410 FAQ →

Related Analysis

Practice All 300-410 Questions

Access 159 questions with complete answers and detailed explanations.

View Full 300-410 Practice Test →

← Back to 300-410 Study Guide