# Module 3: iBGP — The Brain of the ISP

> **Course**: [ISP Backbone Lab Course](../README.md)
> **Previous**: [Module 2: MPLS](02-mpls.md)
> **Next**: [Module 4: L3VPN](04-l3vpn.md)

---

## Network Diagram

![iBGP Route Reflector Design](../diagrams/Module3_iBGP_RouteReflector.png)
*iBGP Route Reflector design — P-CORE reflects routes to all PE clients, eliminating full mesh*

---

## Why BGP Inside the ISP?

IS-IS carries infrastructure routes (loopbacks, point-to-point links). But customer routes, internet routes, VPN routes — all of that rides on **BGP**. Specifically, **iBGP** (Internal BGP — same AS number on both sides).

## The Full Mesh Problem

iBGP has a rule: **A route learned via iBGP cannot be advertised to another iBGP peer.** This prevents loops but creates a problem — you need a full mesh of iBGP sessions. With 9 routers, that's 36 sessions. With 100 routers, that's 4,950 sessions. That doesn't scale.

## Route Reflectors to the Rescue

A **Route Reflector (RR)** breaks the full-mesh requirement. RR rules:
- **Client → RR**: Reflects to all other clients and non-clients
- **Non-client → RR**: Reflects to clients only
- **RR → RR**: Reflects to clients

We'll make **P-CORE** our Route Reflector. Every PE peers with P-CORE only. P-CORE reflects routes between them. Simple, scalable, elegant.

## Why Peer Using Loopbacks?

iBGP sessions use **loopback addresses** (not physical interfaces) because:
1. If a physical link goes down but an alternate path exists, the BGP session survives
2. Loopbacks never go down unless the router itself is dead
3. This is why IS-IS (Module 1) was so important — it provides reachability to loopbacks

## Lab 3 Config: iBGP with Route Reflector

**P-CORE (Route Reflector):**

```
router bgp 65000
 bgp router-id 10.0.0.5
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !
 neighbor PEERS peer-group
 neighbor PEERS remote-as 65000
 neighbor PEERS update-source Loopback0
 neighbor PEERS route-reflector-client
 !
 neighbor 10.0.0.11 peer-group PEERS
 neighbor 10.0.0.12 peer-group PEERS
 neighbor 10.0.0.13 peer-group PEERS
 neighbor 10.0.0.14 peer-group PEERS
 !
 address-family ipv4 unicast
  neighbor PEERS activate
  neighbor PEERS send-community both
  neighbor PEERS next-hop-self
 exit-address-family
 !
 address-family vpnv4 unicast
  neighbor PEERS activate
  neighbor PEERS send-community both
 exit-address-family
```

**PE-EDGE1 (and similar for all PE routers):**

```
router bgp 65000
 bgp router-id 10.0.0.11
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !
 neighbor 10.0.0.5 remote-as 65000
 neighbor 10.0.0.5 update-source Loopback0
 !
 address-family ipv4 unicast
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 send-community both
 exit-address-family
 !
 address-family vpnv4 unicast
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 send-community both
 exit-address-family
```

## Key Design Notes

- `no bgp default ipv4-unicast` — Best practice. Forces you to explicitly activate neighbors per address family. Prevents accidental route leaking.
- `send-community both` — Critical for MPLS VPNs. Route targets are carried as BGP communities.
- `address-family vpnv4` — This carries VPN routes (Module 4). We enable it now so it's ready.
- `next-hop-self` on the RR — Ensures PE routers don't need to resolve each other's next-hops through the core (the RR rewrites it to itself).

## Verification

```
show bgp summary                    ! All neighbors Established?
show bgp ipv4 unicast summary       ! IPv4 session status
show bgp vpnv4 unicast summary      ! VPNv4 session status (should be empty for now)
show bgp ipv4 unicast               ! What routes are in BGP?
show ip bgp neighbors 10.0.0.5      ! Detailed neighbor info
```

## Understanding Check

1. Why can't iBGP routes be re-advertised to other iBGP peers (without a RR)?
2. What's the difference between `address-family ipv4` and `address-family vpnv4`?
3. Why `update-source Loopback0`?
4. What would happen if P-CORE went down? (Single point of failure — how would you fix this in production?)

---

> **Next Module**: [Module 4: L3VPN — Customer Isolation with VRFs →](04-l3vpn.md)