BGP

Routing within a single organization can be handled by internal routing protocols. But the internet is a structure of tens of thousands of independent networks, each operated by different organizations with different policies. ISP A's router does not need to know all of ISP B's internal routes, nor should it. The problem is how these independent networks exchange routes to reach each other's destinations. Internal routing only needs to find the shortest path within the same administrative authority, but inter-organizational routing must reflect not only technically optimal paths but also cost, contractual relationships, and policy. Without solving this, the internet as a connected whole cannot exist.

In the early internet, the number of networks was small and route information could be configured statically or exchanged with simple protocols. But as the internet commercialized, ISPs, universities, and enterprises each began operating networks independently, and thousands of networks needed to exchange tens of thousands of routes. The earlier EGP (Exterior Gateway Protocol) could not support policy-based route selection and had weak loop detection. BGP became necessary not merely because scale grew, but because route selection was no longer just a matter of finding the technically optimal path. Contractual relationships between ISPs might require sending certain traffic on specific routes, the cheapest route and the fastest route might differ, and automatic rerouting around failures was essential. BGP was designed to express these policy requirements as route attributes, which is why it has come to dominate route exchange between all ASes on the internet today.

BGP starts with two routers establishing a session over TCP port 179. This session is called peering: iBGP when established between routers in the same AS, and eBGP when between different ASes. Once the session is open, UPDATE messages exchange route information: 'to reach this network prefix, you need to go through these ASes.' Each route carries an AS-PATH attribute recording, in order, which ASes the route has traversed. Routers use AS-PATH to detect route loops and compare path lengths. But in BGP, path selection criteria go beyond simple hop count. Local Preference specifies internally preferred routes, MED tells external peers which entry point into your network is preferred, and Community tags allow applying policies to groups of routes at once. This policy-driven route selection is what most distinguishes BGP from internal routing protocols.

BGP and internal routing protocols (IGPs) like OSPF both exchange routes, but they differ in scope and design goals. IGPs are optimized for quickly converging on the shortest path within a single organization and share the entire network topology. BGP operates between different organizations, hiding internal structure and advertising only prefix-level reachability. IGPs calculate optimal paths using technical metrics like link cost, while BGP selects routes based on policy factors such as AS-PATH length, Local Preference, and contractual relationships. Internal network route optimization is an IGP problem; inter-organizational connectivity and traffic policy is a BGP problem. In practice, both work together: BGP injects routes learned from the outside into the internal routing table via IGP, and vice versa.

BGP is used when ISPs interconnect their networks, when an enterprise connects to multiple ISPs (multihoming) for automatic failover to another path, and when on-premises networks connect to the cloud via dedicated links (Direct Connect, Cloud Interconnect). Large-scale service operators can use BGP policies to finely control inbound and outbound traffic paths. Conversely, BGP is overkill for routing between subnets within the same organization. BGP prioritizes policy flexibility over convergence speed, so internal route changes may be reflected slowly, and configuration complexity is high. Additionally, a BGP misconfiguration can affect not just your own network but the entire internet, so route filtering and prefix validation must always be part of the operational practice. When deciding whether to use BGP, the key question is: 'does this involve route exchange across organizational boundaries?'