What Problem Does BGP Solve?
Imagine you want to send a letter from BogotΓ‘ to Tokyo. You hand it to your local post office (your ISP). They don't have a direct route to Tokyo, so they pass it to a bigger postal network, which passes it to another, and eventually it arrives. Each postal hub along the way makes a decision: "Who's the best next hop for Tokyo?"
That's exactly what BGP does β but for internet traffic. The internet isn't one giant network. It's thousands of independent networks, each owned by a different organization (ISPs, cloud providers, universities, corporations). These networks are called Autonomous Systems (AS), and BGP is the protocol they use to tell each other: "I can reach these IP addresses. Here's how to get to me."
What Is an Autonomous System (AS)?
An Autonomous System is a network (or group of networks) under a single administrative control β one organization's routing domain. Every AS on the internet gets a unique number called an ASN (Autonomous System Number).
- π Google: AS15169
- βοΈ Amazon AWS: AS16509
- π‘ Cloudflare: AS13335
- π¨π΄ Claro Colombia: AS52468
When your traffic leaves your ISP's AS and enters another AS, BGP is what makes that handoff possible.
eBGP vs iBGP
BGP comes in two flavors, and understanding the difference is crucial:
eBGP (External BGP) runs between routers in different autonomous systems. This is what connects ISPs to each other, ISPs to cloud providers, and so on. When your ISP peers with Amazon's network, they're running eBGP.
iBGP (Internal BGP) runs between routers within the same AS. Large organizations use iBGP to distribute the BGP routing table internally. A major ISP might have hundreds of routers, all needing the same internet routing information β iBGP is how they share it.
The key rule: iBGP routers must be in a full mesh (every router peers with every other router) unless you use Route Reflectors β but that's a story for another article.
How BGP Builds Its Routing Table
BGP routers exchange Network Layer Reachability Information (NLRI) β basically, a list of IP prefixes they can reach and via which AS path. When Router A announces "I can reach 8.8.0.0/16, and the path goes through AS64512 β AS15169", Router B stores that in its BGP table.
Over time, a BGP router learns multiple paths to the same destination. The BGP decision process picks the best one. In order of priority:
- Highest Weight (Cisco-specific, local to the router)
- Highest Local Preference (influences outbound path within your AS)
- Locally originated routes preferred
- Shortest AS Path (fewest autonomous systems to traverse)
- Lowest Origin type (IGP > EGP > Incomplete)
- Lowest MED (influences inbound traffic from neighboring AS)
- eBGP over iBGP paths
- Lowest IGP metric to next hop
- Lowest Router ID as tiebreaker
You don't need to memorize all of these right now β but know that BGP is incredibly flexible. You can influence which paths get chosen using these attributes, which is what makes BGP such a powerful traffic engineering tool.
A Simple BGP Configuration (Cisco IOS)
Here's what a basic eBGP peering looks like in configuration:
! On Router A (AS 65001)
router bgp 65001
bgp router-id 1.1.1.1
neighbor 10.0.0.2 remote-as 65002 ! Peer with Router B
neighbor 10.0.0.2 description ISP-UPSTREAM
!
network 192.168.10.0 mask 255.255.255.0 ! Advertise this prefix
! On Router B (AS 65002)
router bgp 65002
bgp router-id 2.2.2.2
neighbor 10.0.0.1 remote-as 65001
Once both sides are configured and the TCP session comes up (BGP uses TCP port 179), the routers exchange their routing tables and traffic can flow.
BGP States β What's Happening Under the Hood
BGP goes through several states before a session is established. You'll see these in your show bgp neighbors output:
- Idle: BGP is not running or is blocked
- Connect: Trying to establish TCP connection
- Active: TCP connection failed, retrying
- OpenSent: TCP connected, OPEN message sent
- OpenConfirm: Waiting for KEEPALIVE confirmation
- Established: β Session is up, routes being exchanged
The most common troubleshooting state is Active β it means BGP is desperately trying to connect but failing. Common causes: wrong neighbor IP, wrong ASN, firewall blocking TCP 179, or TTL issues on multihop eBGP sessions.
Why Should You Care?
Even if you're not at an ISP, BGP matters in the enterprise world more than ever. SD-WAN products use BGP internally. MPLS VPNs are built on BGP (MP-BGP). AWS, Azure, and GCP all use BGP for Direct Connect / ExpressRoute / Cloud Interconnect. If you're serious about networking, BGP is unavoidable.
The good news: once the fundamental model clicks β AS numbers, peering, path attributes, the decision process β the rest is just detail. Start with the basics, lab it up in GNS3 or EVE-NG, and the rest will follow.
Key Takeaways
- BGP connects autonomous systems and is the routing protocol of the internet
- eBGP runs between AS boundaries; iBGP runs within an AS
- BGP selects paths based on a prioritized set of attributes (Weight β Local Pref β AS Path β MEDβ¦)
- BGP sessions go through 6 states; "Established" is what you want
- You'll encounter BGP in SD-WAN, MPLS, and all major cloud connectivity solutions