hardMultiple Choice
300-410 R1 and R2 are iBGP peers Practice Question
R1 and R2 are iBGP peers. R1 has: neighbor 10.1.1.2 route-map RM_SET in. The route-map RM_SET sets community 100:100. R2 advertises a prefix 172.16.1.0/24 with community 200:200. R1 receives the prefix and the community is changed to 100:100. However, R1's BGP table shows the prefix with community 100:100, but R1 does not propagate this prefix to its other iBGP peer R3. R3 has no special configuration. What is the root cause?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
iBGP split-horizon rule prevents R1 from advertising routes learned from an iBGP peer to another iBGP peer.
By default, iBGP learned routes are not advertised to other iBGP peers to prevent loops, unless the router is a route reflector or confederation. R1 is not a route reflector, so it will not advertise the prefix learned from R2 to R3. The community manipulation is irrelevant to the propagation issue. The root cause is that iBGP split-horizon prevents R1 from advertising the prefix to R3.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
iBGP split-horizon rule prevents R1 from advertising routes learned from an iBGP peer to another iBGP peer.
Why this is correct
BGP's iBGP split-horizon rule forbids re-advertising a route learned from one iBGP peer to another iBGP peer, so R1 cannot pass the prefix to R3. Full-mesh iBGP peering or a route reflector is required to relay it.
- ✗
The community 100:100 is being filtered by R3's inbound policy.
Why it's wrong here
R3 has no special configuration, so no inbound policy exists to filter the community; the prefix is absent because R1 never advertises it. It is tempting because community-based filtering is a common cause of missing routes, and it would be correct if R3 actually had a matching inbound route-map.
- ✗
The route-map RM_SET should have been applied outbound on R2 instead.
Why it's wrong here
Applying the route-map outbound on R2 would set the community before R1 receives it, but that does not explain R1 withholding the prefix from R3; the fault lies in R1's own advertisement. It is tempting because outbound route-maps are a normal way to tag communities, and it would be correct if the goal were to tag routes leaving R2.
- ✗
R1 must have a network statement for 172.16.1.0/24 to advertise it.
Why it's wrong here
A network statement only originates a locally known prefix into BGP; it is irrelevant to relaying a prefix already learned from an iBGP peer, which R1 simply fails to re-advertise. It is tempting because network statements are the standard way to inject prefixes, and it would be correct if R1 were originating 172.16.1.0/24 itself.
Go deeper
Related to this question
Learn chapter
OSPF Route Summarization and Filtering
Key term
BGP Route Reflector
A BGP Route Reflector is a networking device that reduces the number of BGP peer connections needed in a large network by allowing routers to share routing information without needing to connect to every other router directly.
About these practice questions
One of 1,401 original 300-410 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 300-410 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 300-410 exam.