BGP: Border Gateway Protocol

What BGP is

BGP (Border Gateway Protocol) is the routing protocol that holds the public Internet together, standardized in RFC 4271 (BGP-4). Unlike the three interior gateway protocols in this course, BGP is an Exterior Gateway Protocol: it runs between independently administered networks called autonomous systems (AS), each identified by an AS number. BGP is a path-vector protocol — related to distance-vector, but instead of a simple distance it exchanges the entire sequence of autonomous systems a route has crossed, letting a router detect and reject a route that loops back through its own AS. Two BGP routers that exchange routes are peers; a session between routers in different autonomous systems is eBGP, and a session between routers in the same autonomous system is iBGP. BGP runs over TCP port 179, inheriting reliable, ordered delivery instead of implementing its own.

BGP message types

RFC 4271 defines four BGP message types. OPEN is sent once, right after the TCP connection forms, to negotiate session parameters (AS number, hold time, BGP Identifier). UPDATE advertises new reachable prefixes or withdraws ones that are no longer reachable, each carrying its path attributes. NOTIFICATION reports an error and closes the session. KEEPALIVE is sent periodically (and has no body beyond its header) to confirm the session is still alive within the negotiated hold time.

The BGP finite state machine

A BGP session moves through a defined sequence of states: Idle (no connection attempted) → Connect (waiting for the TCP connection) → Active (retrying the TCP connection) → OpenSent (TCP is up, local OPEN sent, waiting for the peer's OPEN) → OpenConfirm (OPEN messages exchanged, waiting for a KEEPALIVE) → Established (the session is fully up). Routes are only exchanged once a session reaches Established — anything short of that is still session setup, not routing.

Path attributes

Every BGP UPDATE carries path attributes describing the route, which the decision process later compares. AS_PATH lists every autonomous system the route has crossed; NEXT_HOP is the IP address to forward toward; ORIGIN records how the route entered BGP (IGP, EGP, or Incomplete); LOCAL_PREF is an iBGP-only attribute an administrator sets to prefer one exit point over another; MED (Multi-Exit Discriminator) is a hint one AS gives another about which of several entry points it prefers, deliberately weak in the decision process so it rarely overrides more important attributes.

Interactive BGP session establishment

Step through two eBGP peers moving through the finite state machine from Idle to Established, then watch a third router receive the same prefix from two different peers and apply the decision process — tying on LOCAL_PREF before AS_PATH length picks a winner.

The BGP decision process

When more than one route to the same prefix survives, RFC 4271's decision process compares them in order, stopping as soon as one criterion breaks the tie: highest LOCAL_PREF, shortest AS_PATH length, lowest ORIGIN type (IGP beats EGP beats Incomplete), lowest MED (only compared between routes from the same neighboring AS), eBGP preferred over iBGP, lowest IGP metric to the NEXT_HOP, and finally lowest BGP Identifier (Router ID) as a final tiebreaker. Cisco's implementation checks a proprietary Weight attribute before all of these, but Weight is not part of the RFC 4271 specification.

Inspect BGP evidence

show ip bgp summary is the first command to check: it lists every configured neighbor and its current session state. Anything other than a number (the count of received prefixes) in the state column — Idle, Active, Connect, OpenSent, OpenConfirm — means the session has not reached Established, and no routes are being exchanged with that neighbor yet. show ip bgp (or show ip bgp <prefix>) lists the routes themselves along with their path attributes, so you can see exactly why the decision process picked the route it did.

Guided BGP path-selection practice

Two routes reach the same prefix: Route A has LOCAL_PREF 200 and a 3-AS-long AS_PATH; Route B has LOCAL_PREF 100 and a 1-AS-long AS_PATH. Because LOCAL_PREF is compared before AS_PATH length in the decision process, Route A wins outright — its longer AS_PATH is never even considered.

Troubleshoot BGP

1. Confirm basic IP reachability and that nothing is blocking TCP port 179 between the two routers.
2. Check for an AS number mismatch — each side must be configured with the AS number its peer expects, for both eBGP and iBGP.
3. If the session is stuck in Active or Idle, the TCP connection itself is failing; verify routing to the peer's address exists independently of BGP.
4. If the session reaches Established but a prefix does not appear, check outbound and inbound routing policy (prefix lists, route maps, distribute lists) on both sides before assuming a protocol fault.
5. Confirm the NEXT_HOP in a received route is actually reachable — an eBGP-learned NEXT_HOP that is not directly reachable, or not reachable via an IGP route in an iBGP scenario, will keep the route out of the forwarding table even though BGP accepted it.
6. When two routes both look valid but only one is used, read the path attributes directly with show ip bgp <prefix> and walk the decision process in order rather than guessing.

Knowledge check and summary

Pro deep dive