BGP Fundamentals for Engineers
Understand how the internet routes traffic between networks. Covers BGP peering, autonomous systems, route propagation, prefix hijacking, and the networking fundamentals that every cloud engineer should know about how packets find their destination.
Border Gateway Protocol (BGP) is the protocol that makes the internet work. Every time you make a request to google.com, BGP determines which path your packets take across dozens of autonomous networks. Understanding BGP is critical for engineers working with multi-cloud architectures, CDNs, DDoS mitigation, and network security.
How BGP Works
The internet is a network of networks (Autonomous Systems).
Each AS has a unique number (ASN):
AS15169 — Google
AS16509 — Amazon (AWS)
AS13335 — Cloudflare
AS8075 — Microsoft (Azure)
AS7018 — AT&T
BGP routers exchange "prefix announcements":
"I can reach 142.250.0.0/15 via AS15169"
This means: "If you want to send packets to any IP
in the 142.250.x.x range, send them to me (AS15169)"
Path selection:
Multiple paths may exist to reach a destination.
BGP selects based on:
1. Shortest AS path (fewest hops between networks)
2. Local preference (business policies)
3. MED (Multi-Exit Discriminator — from neighboring AS)
4. IGP metric (internal routing cost)
Example paths to Google (142.250.0.0/15):
Path 1: Your ISP → Tier 1 → Google (2 hops)
Path 2: Your ISP → IXP → Google (1 hop) ← preferred
Path 3: Your ISP → Other ISP → Google (2 hops)BGP for Cloud Engineers
Why you care about BGP:
1. Multi-Cloud Connectivity:
AWS Direct Connect, GCP Interconnect, Azure ExpressRoute
All use BGP to exchange routes between your network and cloud
Your AS → BGP session → AWS (AS16509)
You announce: "10.0.0.0/8 is my network"
AWS announces: "172.16.0.0/12 is your VPC"
2. CDN and Anycast:
Cloudflare (1.1.1.1) uses BGP anycast:
The SAME IP address is announced from 300+ data centers
BGP routes you to the geographically nearest one
User in Tokyo → AS13335 Tokyo POP
User in London → AS13335 London POP
Same IP, different server!
3. DDoS Mitigation:
During attack, BGP is used to reroute traffic:
Normal: User → Your origin server
Under attack: Announce route through DDoS scrubber
Scrubbed: User → Scrubber → Clean traffic → Your server
4. Prefix Hijacking Awareness:
If another AS announces YOUR IP prefix:
Routes get redirected to attacker
Your service becomes unreachable
Protection: RPKI (Resource Public Key Infrastructure)RPKI (Route Origin Validation)
Problem: BGP has no built-in authentication
Anyone can announce ANY prefix
2018: BGP leak/hijack sent Amazon DNS traffic to cryptocurrency
stealing servers for 2 hours
2008: Pakistan Telecom accidentally hijacked YouTube globally
Solution: RPKI — cryptographic proof of route origin
ROA (Route Origin Authorization):
"Only AS15169 is authorized to announce 142.250.0.0/15"
Signed by the IP address owner (RIR-validated)
Validation states:
Valid: Route matches a ROA → Accept ✓
Invalid: Route contradicts a ROA → Reject ✗ (likely hijack)
Unknown: No ROA exists → Accept (but monitor)
Adoption: ~50% of internet routes have ROAs (2024)
Major ISPs dropping invalid routes by defaultAnti-Patterns
| Anti-Pattern | Consequence | Fix |
|---|---|---|
| No RPKI for your prefixes | Vulnerable to prefix hijacking | Create ROAs for all your IP space |
| Single upstream provider | No redundancy if provider has issues | Multi-homed BGP with 2+ upstreams |
| No BGP monitoring | Route leaks and hijacks go undetected | BGP monitoring (RIPE RIS, BGPStream) |
| Flat preference for all routes | Suboptimal traffic paths | Local preference policies for cost/latency |
| Announce too-specific prefixes | Filtered by upstream providers, unreachable | Follow minimum prefix length guidelines (/24 for IPv4) |
BGP is the internet’s control plane. Understanding it helps cloud engineers make better decisions about connectivity, CDN architecture, and network security. You do not need to be a BGP operator — but you do need to understand how your packets find their way across the internet.
