BGP Route-Reflectors and BGP Split-Horizon

The rule of BGP Split-Horizon states that advertisements received from one iBGP peer cannot be advertised to another iBGP peer.

When an iBGP peer is configured as a Route-Reflector-Client, the rule of BGP Split-Horizon is effectively disabled, allowing advertisements received from one iBGP peer to be advertised to another iBGP peer. Using Route-Reflectors is a very effective way of mitigating the iBGP full mesh requirement.

So, here I am, working on an awesome CCIE lab and the most unexpected event occurs. A prefix advertised from a Route-Reflector-Client is advertised to a non-Route-Reflector-Client peer. What the ……. how could this be…..

Here’s the scenario:
Both R9 and R10 advertise prefixes 10.217.9.0/24 and 10.217.10.0/24 respectively. As predicted in the illustration below, the Route-Reflector-Clients receive each others prefix and life is good (I believe I was sipping some freshly made iced tea) mmm mmm good 😉

Until I hopped on R7 and I see that R7 (which is not configured as a Route-Reflector-Client) is receiving both prefixes as illustrated below:

I will apologize in advance in case I missed a line of text somewhere that notated this behavior is normal.

Mwwwaaaahahaha!!! It’s troubleshooting time 😉
Interestingly, when I remove the Route-Reflector-Client role from R9 and R10 the prefixes are no longer advertised to R7, but why?

Tomorrow, I will convene with my co-workers as discuss this matter. Nothing solidifies a topic like actively conversing about it 😉

I will report back shortly.

Until next time…… LAB ON!!!!!!