Every time you load a webpage, your traffic crosses multiple networks owned by different organizations. The protocol responsible for making that work — for stitching together tens of thousands of independently operated networks into a single functional internet — is BGP, the Border Gateway Protocol.
BGP is not like OSPF or EIGRP. Those are interior gateway protocols (IGPs) designed to route traffic within a single organization's network. BGP operates between organizations — between autonomous systems (ASes) — and it's the only protocol that does this at internet scale.
Why BGP Exists
The internet is not one network. It's a collection of over 75,000 autonomous systems, each identified by a unique AS number (ASN). ISPs, cloud providers, enterprises, universities, and content delivery networks all operate their own ASes. These organizations need a way to tell each other which IP prefixes they can reach and which path traffic should take to get there.
That's BGP's job. It's a path-vector routing protocol that exchanges network layer reachability information (NLRI) between BGP speakers. Unlike link-state protocols that build a complete topology map, BGP only knows the path — a sequence of AS numbers — that traffic would traverse to reach a destination prefix.
Autonomous Systems and ASNs
An autonomous system is a collection of IP networks under the control of a single administrative entity that presents a common routing policy to the internet. Each AS is assigned a number:
- 2-byte ASNs: 1–65535 (the original range, defined in RFC 4271)
- 4-byte ASNs: 65536–4294967295 (extended range, defined in RFC 6793)
- Private ASNs: 64512–65534 (2-byte) and 4200000000–4294967294 (4-byte) — used internally, not advertised to the internet
In our PingLabz BGP Lab, AS 65001 represents the enterprise HQ, AS 65002 is a branch site, and AS 65010/65020 are ISPs. These are private ASNs suitable for a lab environment. In production, public ASNs are assigned by Regional Internet Registries (RIRs) like ARIN, RIPE, or APNIC.
How BGP Differs from IGPs
If you're coming from an OSPF or EIGRP background (see our OSPF series for reference), BGP will feel fundamentally different:
| Feature | IGPs (OSPF, EIGRP) | BGP |
|---|---|---|
| Scope | Within one AS | Between ASes (and within) |
| Algorithm | SPF / DUAL | Best path selection (13 steps) |
| Transport | IP protocol 89/88 | TCP port 179 |
| Neighbor discovery | Automatic (multicast) | Manual configuration |
| Scalability | Hundreds of routers | 950,000+ IPv4 prefixes |
| Metric | Cost / composite | Path attributes |
| Convergence | Sub-second (with tuning) | Minutes (default timers) |
BGP runs over TCP (port 179), which means neighbors must be explicitly configured — there's no multicast hello mechanism. BGP converges more slowly by default, with keepalive timers of 60 seconds and hold timers of 180 seconds, though these can be tuned significantly with BFD (we'll cover this in BGP Convergence: Timers, BFD, and Reducing Failover Time).
eBGP and iBGP
BGP has two flavors depending on whether the peers are in the same or different autonomous systems:
- eBGP (External BGP): Peering between routers in different ASes. This is the classic use case — ISP to ISP, enterprise to ISP, content provider to exchange point. eBGP peers are typically directly connected, and the TTL defaults to 1.
- iBGP (Internal BGP): Peering between routers in the same AS. Used to carry BGP-learned prefixes across your internal network. iBGP has special rules: it does not modify the AS-path, and routes learned from one iBGP peer are not advertised to another iBGP peer (the split-horizon rule). This is why iBGP requires either a full mesh, route reflectors, or confederations.
We'll dive deep into the differences in eBGP vs iBGP: What's the Difference and When to Use Each.
BGP in the Real World
BGP is everywhere, not just at internet exchange points:
- Internet routing: Every ISP, cloud provider, and CDN uses BGP to exchange the full internet routing table (950,000+ IPv4 prefixes, 210,000+ IPv6 prefixes as of 2025).
- Enterprise multihoming: Organizations with two or more ISP connections use BGP to control inbound and outbound traffic paths.
- MPLS VPNs: Service providers use MP-BGP (Multiprotocol BGP) to distribute VPN routes between PE routers.
- Data center fabrics: Modern data center designs (like BGP on the host with Cumulus/SONiC) use eBGP as the underlay routing protocol.
- SD-WAN underlays: BGP often serves as the transport routing protocol beneath SD-WAN overlays.
The BGP Finite State Machine
When two BGP routers attempt to form a peering session, they step through a finite state machine (FSM) with six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Only in the Established state do routers actually exchange routing information. Understanding the FSM is critical for troubleshooting — a peer stuck in Active or OpenSent tells you exactly where the problem lies. We'll break this down fully in How BGP Works: Peers, Updates, and the Finite State Machine.
Key Takeaways
- BGP is the only protocol that routes traffic between autonomous systems at internet scale — it's the glue holding the internet together.
- Unlike IGPs, BGP uses TCP (port 179), requires manual neighbor configuration, and makes routing decisions based on path attributes rather than a single metric.
- eBGP runs between different ASes; iBGP runs within the same AS with additional rules like the split-horizon restriction.
- BGP is used far beyond internet peering — enterprise multihoming, MPLS VPNs, data center fabrics, and SD-WAN all rely on it.
- The BGP finite state machine (six states from Idle to Established) is essential knowledge for troubleshooting adjacency issues.