“Full-mesh iBGP requires N*(N-1)/2 peerings. In an ISP network with 20 core routers, that’s 190 active iBGP neighbor sessions thrashing router CPUs. Deploying BGP Route Reflectors reduces this to 20 hub sessions while AS-Path Prepending delivers deterministic inbound traffic steering.”

In February 2012, during my tenure as Assistant Manager at Net4 India, we managed a rapidly growing ISP backbone (AS 17813) spanning 20 core routers across Delhi, Mumbai, and Chennai.

Our core routing architecture relied on internal BGP (iBGP) to distribute external Internet routes across all internal routers.

Under standard BGP split-horizon rules, an iBGP router will not re-advertise a route learned from one iBGP peer to another iBGP peer.

To ensure all routers maintain full reachability, BGP mandates a Full-Mesh iBGP Topology—every router must establish a direct BGP TCP peering session with every other router in the Autonomous System.

As our core grew to 20 routers, full-mesh iBGP hit a mathematical scaling wall.

---

The N*(N-1)/2 Full-Mesh Scaling Wall

The formula for full-mesh peerings is N * (N - 1) / 2.

At 20 core routers, our network was maintaining 190 simultaneous iBGP neighbor sessions:

# iBGP Full-Mesh Peering Math:
# 20 Routers * (20 - 1) / 2 = 190 Active iBGP Neighbor Sessions!

Older edge routers—such as our legacy Cisco 7206VXR chassis—were drowning.

Their main CPUs were pinned at 90% utilization simply processing duplicate BGP routing updates and maintaining 19 TCP session state tables.

When a major international BGP route flap occurred, memory pools wrapped, and core routers dropped BGP neighbor adjacencies due to CPU starvation.

---

The Mess: The Inbound Traffic De-Aggregation Scandal

In addition to the iBGP CPU crisis, we had a severe inbound traffic steering problem.

Our primary 10Gbps transit circuit in Delhi was sitting 70% idle, while our expensive secondary 1Gbps transit link in Mumbai was choked at 100% capacity with incoming international user traffic.

An eager junior engineer tried to fix the traffic imbalance by de-aggregating our public IP block.

Instead of advertising our clean /19 block (202.71.128.0/19) to both ISPs, he advertised smaller /24 subnets (202.71.130.0/24, 202.71.131.0/24) over the primary Delhi link, hoping global ISPs would prefer the longer prefix.

The result was an international routing scandal.

Major Tier-1 upstream ISPs (Telia, Level3, Tata Communications) enforced strict BGP Prefix Filtering. They rejected our un-aggregated /24 announcements as route-table pollution!

International users in Europe and North America lost reachability to our hosted datacenter servers for 6 hours until we withdrew the /24 prefixes.

De-aggregating IP prefixes to steer traffic was a violation of global Internet routing hygiene. We needed a clean BGP traffic engineering solution.

---

The Solution: BGP Route Reflectors & AS-Path Prepending

We solved the scaling wall and traffic steering crisis by deploying BGP Route Reflectors (RR) and implementing outbound AS-Path Prepending.

# Dual-Pillar BGP Architecture Optimization

1. **BGP Route Reflectors (iBGP Scaling):** Deployed dual Cisco ASR 9006 core routers as Route Reflectors (`cluster-id 1.1.1.1`). Client routers peer ONLY with the 2 RRs, reducing total sessions from 190 down to 20!
2. **AS-Path Prepending (Inbound Steering):** Artificially inflated path length on the secondary Mumbai ISP link by prepending our AS number 3x (`AS 17813 17813 17813`), forcing global Internet routers to choose the shorter Delhi path.

# Cisco ASR 9006 Route Reflector Configuration
router bgp 17813
  bgp cluster-id 1.1.1.1
  neighbor 192.168.1.10 remote-as 17813
  neighbor 192.168.1.10 description "iBGP Client: Core-Edge-01"
  neighbor 192.168.1.10 route-reflector-client
!
# Outbound Route-Map for Inbound Traffic Steering via AS-Path Prepending
ip prefix-list AGGREGATED-BLOCK permit 202.71.128.0/19
!
route-map MAP-PREPEND-MUMBAI-OUT permit 10
  match ip address prefix-list AGGREGATED-BLOCK
  set as-path prepend 17813 17813 17813 # Inflate path length for secondary link

How AS-Path Prepending Steered Traffic Cleanly

When global Internet routers evaluate BGP paths for 202.71.128.0/19:

• Path via Primary Delhi ISP: AS 7018 -> AS 17813 (Length: 2 AS hops) -> PREFERRED
• Path via Secondary Mumbai ISP: AS 4755 -> AS 17813 AS 17813 AS 17813 AS 17813 (Length: 5 AS hops) -> BACKUP

Global Internet routers automatically selected the shorter 2-hop Delhi path for 80% of traffic, keeping our aggregate /19 prefix intact while reserving the Mumbai link for backup failover.

---

The Impact

• 90% Session Reduction: Reduced iBGP sessions across the core from 190 full-mesh peerings to 20 hub-and-spoke Route Reflector sessions.
• CPU Relief: Dropped core router CPU utilization from 90% back to a healthy 12%.
• Clean Traffic Steering: Successfully steered 80% of inbound international traffic over our primary 10Gbps Delhi pipe using AS-Path prepending without de-aggregating subnets.

Key Takeaway

Deploy BGP Route Reflectors and AS-Path Prepending to Scale Core Networks.

Never allow iBGP networks to expand into full-mesh session paralysis, and never de-aggregate public IP blocks to steer inbound traffic. Deploy BGP Route Reflectors (route-reflector-client) to scale internal peering to hundreds of routers, and use AS-Path Prepending to steer inbound Internet traffic deterministically while preserving global routing table hygiene.

---

Architecture and decisions: mine. Debugging sessions at odd hours: mine. AI assistance: structure, syntax, first draft. — Sachin