← Interview Prep

BGP — Theory

The path-vector protocol that glues the Internet together: autonomous systems, attributes, best-path selection, policy, scaling, and security.

BGP (Border Gateway Protocol, current version BGP-4, RFC 4271) is the inter-domain routing protocol of the Internet. Unlike IGPs (OSPF/IS-IS) that optimize for shortest cost inside one administrative domain, BGP is built to exchange reachability between domains and to let each operator express policy — who to send traffic to, who to accept it from, and which path to prefer for business rather than purely topological reasons.

BGP is a path-vector protocol: instead of advertising a metric, it advertises the full list of autonomous systems a prefix must transit (the AS_PATH). That vector is both the loop-prevention mechanism (an AS rejects any route already containing its own ASN) and the raw material for policy. It runs over TCP port 179 — reliability, ordering, and flow control are TCP's job, not BGP's.

Overview: autonomous systems and the path vector

An Autonomous System (AS) is a network under a single administrative/routing policy, identified by an ASN. BGP speakers exchange NLRI (Network Layer Reachability Information — the prefixes) tagged with path attributes.

eBGP vs iBGP

The same protocol behaves differently depending on whether the neighbor is in a different AS (eBGP) or the same AS (iBGP). This distinction drives almost every BGP design decision.

The iBGP loop-prevention rule and full-mesh requirement

Inside an AS there is no AS_PATH growth, so BGP cannot use it to detect loops among iBGP peers. The safeguard is a split-horizon rule: a route learned from an iBGP peer is never advertised to another iBGP peer. The consequence is that every iBGP speaker must hear routes directly from the originator — i.e. iBGP requires a full mesh of sessions: n(n−1)/2 sessions for n routers. That scales quadratically and is the central iBGP scaling problem.

iBGP full mesh for 5 routers = 5*4/2 = 10 sessions

      R1 ───── R2
      │ \     / │
      │   \ /   │
      │   / \   │
      │ /     \ │
      R4 ───── R3
          \   /
           R5   (all pairs peered)

Two mechanisms remove the full-mesh burden:

Neighbor FSM (finite state machine)

A BGP session progresses through six states. Knowing where it is stuck is the fastest way to diagnose a peering problem.

Idle ─▶ Connect ─▶ OpenSent ─▶ OpenConfirm ─▶ Established
   │       │
   │       └─▶ Active ─▶ (retry Connect)
   └── admin down / error resets here

Path attributes

Every UPDATE carries attributes classed by two axes: well-known vs optional (must all routers understand it?) and transitive vs non-transitive (should an AS that doesn't recognize it still pass it on?).

Two more you should name: WEIGHT is a Cisco-proprietary, router-local attribute (never advertised) — highest wins, evaluated first. Local-only means it only affects the box it's set on.

Best-path selection algorithm

When BGP has multiple paths to the same prefix it runs them through an ordered tiebreaker and installs exactly one as best (unless multipath is enabled). The classic Cisco order — memorize it top to bottom:

Mnemonic: "We Love Oranges AS Oranges Mean Pure Refreshment" — Weight, Local-pref, Originate, AS-path, Origin, MED, Paths (eBGP/iBGP), RID. The first four settle the vast majority of real decisions.

Policy tools and traffic steering

Policy is applied per-neighbor, inbound (routes I accept) or outbound (routes I advertise). The building blocks:

Steering traffic: inbound vs outbound

The key mental model — you control your own outbound easily; influencing inbound is only a hint the other side may ignore:

! Prefer ISP-A outbound (higher local-pref set inbound):
route-map FROM_ISP_A permit 10
 set local-preference 200
!
! De-prefer this path inbound by prepending my own ASN 3x:
route-map TO_ISP_B permit 10
 set as-path prepend 65010 65010 65010
!
! Tag routes NO_EXPORT so a peer keeps them local:
route-map TO_PEER permit 10
 set community no-export

Scaling & stability

• Route reflection / confederations: remove the iBGP full-mesh (see above) — the primary control-plane scaling lever.
• Update groups / peer-groups: routers batch neighbors with identical outbound policy so the UPDATE is generated once and replicated — big CPU/convergence win with many peers.
• Multipath / ECMP: maximum-paths installs several equal paths (equal through step 8: same weight, local-pref, AS-path length, origin, MED) to load-share. bgp bestpath as-path multipath-relax allows equal-length paths through different ASes.
• Route aggregation / summarization: advertise a covering prefix instead of many specifics to shrink the global table (aggregate-address ... summary-only). Watch for loss of granularity and ATOMIC_AGGREGATE/AS_SET side effects.
• Route flap damping (RFD): penalize prefixes that flap; suppress them until the penalty decays. Historically over-aggressive; use conservative (RIPE) parameters or skip it.
• Convergence: BGP is not fast by nature (hold-timer 180s, advertisement intervals, path hunting). Speed it with BFD, next-hop tracking, fast-external-fallover, PIC (Prefix-Independent Convergence), and lower timers.
• BFD (Bidirectional Forwarding Detection): sub-second liveness independent of BGP timers; on failure it drops the session immediately instead of waiting for the hold timer to expire.
• Graceful Restart / NSR: keep forwarding across a control-plane restart so a router reload doesn't blackhole traffic.

Security

BGP trusts what it hears, so most incidents are route hijacks (someone originates a prefix that isn't theirs) or route leaks (a route propagated against policy, e.g. a customer re-advertising one provider to another). Defenses layer up:

Prefix hijack basics: because best-path prefers a more-specific prefix and (all else equal) a shorter AS_PATH, an attacker who originates a /24 covering your /22, or falsely inserts themselves closer in the path, can pull traffic. RPKI stops the naive origin-forgery case; path forgery (announcing a valid origin but a fake adjacency) needs BGPsec (path signing, little-deployed) or ASPA (AS Provider Authorization).