BGP: Split Horizon Rule (iBGP Protocol)

#BGP #networkengineers #ibgp #routingandswitching
An important question often asked by interviewers for a Network Engineer position
---------------------------------------------------------------------------------
PART 1️: - Split Horizon Rule in iBGP
In iBGP, the split horizon rule says:
A route learned from one iBGP neighbour is NOT advertised to another iBGP neighbour. This rule applies only to iBGP, not eBGP.
Why this rule exists (Very important logic)
Inside one AS:
• iBGP routers do not modify AS_PATH
• If routes were freely re-advertised:
o Loops could happen
o AS_PATH would not help detect Loop in this condition
So BGP designers said: “To be safe, do NOT forward iBGP-learned routes to other iBGP peers.”

🔹 Exact Route Flow (step-by-step)
STEP 1: R1 originates the route
• Route exists behind R1
• R1 puts it into BGP
STEP 2: R1 → R2
• R1 advertises 10.10.10.0/24 to R2
• R2 learns it via iBGP
STEP 3: R2 → R3 ❌ (BLOCKED)
• R2 wants to send the route to R3
• ❌ iBGP split horizon blocks it
RESULT:
• R2 knows the route
• R3 never learns it
🚨 This is the iBGP scalability problem

How BGP expects you to fix this (without RR)

Option 1: Full Mesh iBGP
Every router peers with every other router.
❌ Not scalable
❌ Too many sessions


Why Route Reflector is Needed
🔹 The real-world problem
If you have:
• 50 routers → 1225 iBGP sessions
• 100 routers → 4950 sessions
This is:
• Hard to manage
• Hard to troubleshoot
• CPU & memory heavy
So we need:
A way to break split horizon safely
That solution is Route Reflector.