BGP Fundamentals: The Protocol That Runs the Internet

Why the Internet Needs a Different Kind of Protocol

OSPF and EIGRP, discussed earlier in this series, are Interior Gateway Protocols (IGPs), designed to find the mathematically shortest path within a single organization's network, where every router is under common administrative control. Connecting the internet's hundreds of thousands of independent networks together requires something fundamentally different: a protocol that can express business policy and trust relationships between separate organizations, not just calculate the shortest path.

BGP: A Path-Vector Protocol

BGP (Border Gateway Protocol) is classified as a Path-Vector protocol, distinct from both the link-state approach of OSPF and the distance-vector approach of EIGRP, discussed earlier in this series. Rather than calculating a numeric cost, BGP tracks the actual sequence of autonomous systems a route has passed through, using that path information both to prevent loops and to make policy-based routing decisions.

Autonomous System (AS): a network or group of
  networks under a single administrative
  authority's control, identified by a unique
  AS Number (ASN)

Example AS path for a route:
  Path: 65001 65002 65003
  This means the route originated in AS 65003,
  and was learned by passing through AS 65002
  then AS 65001 -- the receiving router simply
  needs to check whether its own AS number
  already appears in this path to detect a loop

eBGP Versus iBGP

BGP operates in two distinct modes depending on whether the two peering routers belong to the same or different autonomous systems.

eBGP (External BGP):
  Between routers in DIFFERENT autonomous systems
  Typically directly connected (though this is
  not strictly required)
  Used between separate organizations -- an
  enterprise and its ISP, or between ISPs

iBGP (Internal BGP):
  Between routers in the SAME autonomous system
  Used to carry BGP routing information across
  an organization's own internal network,
  typically alongside an IGP like OSPF handling
  the actual internal path calculation

This distinction matters immensely for configuration and design: eBGP sessions typically require minimal configuration between directly connected neighbors, while iBGP has additional requirements, such as the need for a full mesh of iBGP sessions (or route reflectors, a more advanced topic) to properly propagate routes throughout an AS.

Configuring Basic eBGP

Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.2 remote-as 65002
Router(config-router)# network 192.168.1.0 mask 255.255.255.0

-- "65001" is this router's own AS number
-- "neighbor ... remote-as 65002" identifies a
--   specific eBGP neighbor and its AS number --
--   both values must be configured accurately,
--   since a mismatch prevents the session
--   from establishing
-- "network" advertises a specific prefix into BGP,
--   fundamentally different from OSPF/EIGRP's
--   network command, which enables the protocol
--   on matching interfaces -- BGP's network
--   command specifically advertises that exact
--   prefix if it exists in the routing table

Key BGP Path Attributes for Route Selection

Since multiple paths to the same destination often exist across the internet, BGP uses a well-defined sequence of Path Attributes to select a single best path when more than one is available.

A simplified view of BGP's best-path selection
order (the full algorithm has more steps, but
these are among the most commonly relevant):

1. Weight (Cisco-proprietary, highest wins,
   local to the router only, never advertised)
2. Local Preference (higher wins, shared within
   an AS via iBGP, used to influence outbound
   traffic preference)
3. Locally originated routes preferred over
   learned routes
4. Shortest AS Path (fewer AS hops wins)
5. Lowest Origin type
6. Lowest MED (Multi-Exit Discriminator, used
   to influence which entry point a neighboring
   AS should prefer)
7. eBGP-learned paths preferred over iBGP-learned
8. Lowest IGP metric to the next hop
9. Oldest route (for stability)
10. Lowest router ID (final tiebreaker)

This ordered list reflects BGP's fundamentally policy-driven nature: unlike an IGP that simply picks the mathematically shortest path, BGP's very first consideration (Weight) is a purely local, administrator-configured preference, and even Local Preference, evaluated second, is explicitly designed to let an organization express its own business policy about preferred paths rather than relying on any objective distance measurement.

Using AS Path Length as a Simple Example

Two paths to the same destination network:
Path A: AS Path = 65001 65002 (2 hops)
Path B: AS Path = 65001 65003 65004 (3 hops)

All else being equal, BGP prefers Path A,
since it has the shorter AS path -- though
this is only reached as a tiebreaker after
Weight and Local Preference have already
been checked and found equal

Verifying BGP Neighbors and the Routing Table

Router# show ip bgp summary

Neighbor        V    AS  MsgRcvd MsgSent   State
203.0.113.2     4  65002      142     138   Established

Router# show ip bgp

Network            Next Hop        Metric  LocPrf  Path
*> 192.168.2.0/24   203.0.113.2         0            65002 i

Router# show ip route bgp

B    192.168.2.0/24 [20/0] via 203.0.113.2

A neighbor state of Established confirms the BGP session is fully formed and exchanging routes — any other state indicates a session still forming or failing, requiring the same kind of systematic troubleshooting (checking AS number configuration, IP reachability, and any configured authentication) applied to OSPF and EIGRP neighbor issues discussed earlier in this series. BGP routes appear in the routing table with the code B and a default administrative distance of 20 for eBGP-learned routes, notably lower than both OSPF's 110 and EIGRP's 90 -- meaning eBGP routes are strongly preferred over IGP routes to the same destination when both exist.

Why BGP's Design Philosophy Differs Fundamentally from IGPs

Every protocol covered earlier in this series — OSPF's link-state cost and EIGRP's composite metric — ultimately optimizes for the mathematically best path within a single trusted administrative domain. BGP was deliberately designed around a different priority entirely: since it connects mutually distrustful, independently operated networks, it must support administrator-defined policy (which neighbor to prefer, which paths to accept or reject, which routes to advertise to whom) as a first-class concern, with pure path length serving as only one relatively minor factor among many in the eventual path selection decision.

Why BGP Fluency Is Essential Beyond Service Providers

While BGP was originally the domain of internet service providers connecting to each other, it has become increasingly common in enterprise networks as well — particularly for organizations with connections to multiple ISPs for redundancy, or for connecting to cloud providers, many of which use BGP for their own network connectivity offerings. Understanding the eBGP/iBGP distinction and the policy-driven path selection process covered in this article is foundational knowledge before tackling the more advanced BGP policy tools, such as route maps and communities, covered later in this series.