isp-backbone-course/modules/03-ibgp.md

Module 3: iBGP — The Brain of the ISP

Course: ISP Backbone Lab Course Previous: Module 2: MPLS Next: Module 4: L3VPN

---

Network Diagram

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 →