BGP

The Internet is not one network. It is a network of networks, each run under its own policy. Border Gateway Protocol, or BGP, is how those networks exchange reachability information.

BGP answers a practical question: which neighboring network should receive traffic for a destination prefix? It carries possible paths and enough attributes for each network to apply its own policy. That makes BGP different from an interior routing protocol. An interior protocol usually seeks efficient paths inside one administration. BGP coordinates paths between administrations that may have different technical and business goals.

The core mental model

Think of a BGP route as a claim with context:

I can reach this IP prefix through this path, and here are attributes you can use when deciding what to do with the claim.

A BGP speaker sends that claim to a configured peer. The receiving speaker applies import policy. It rejects or accepts the route, compares accepted routes, and selects a preferred route. It may then apply export policy and advertise a route to other peers.

That flow matters more than any vendor command:

peer advertisement
      ↓
import policy
      ↓
candidate routes
      ↓
decision process
      ↓
selected route
      ↓
export policy
      ↓
advertisement to another peer

BGP does not discover peers automatically. Operators configure the neighbor relationship and the policy around it. Modern default-reject behavior requires explicit import and export policy before an external BGP session can use or advertise routes.

Autonomous systems and prefixes

An autonomous system, or AS, presents a coherent routing policy to other networks. Each public AS uses an autonomous system number, or ASN. BGP supports four-octet ASNs, which expanded the available number space beyond the original two-octet format.

A prefix describes a block of IP destinations. For example, an organization might originate a prefix from its AS. Other autonomous systems can learn that prefix, attach or change permitted attributes, and advertise a path onward according to policy.

The AS_PATH attribute records the sequence of autonomous systems an advertisement has traversed. A speaker can reject a route containing its own ASN, which prevents a common inter-AS loop. Operators also use the path as one input to policy and route selection.

eBGP and iBGP

External BGP, or eBGP, connects speakers in different autonomous systems. It carries routes across administrative boundaries. Typical relationships include customer-to-provider, settlement-free peering, and connections to an Internet exchange route server.

Internal BGP, or iBGP, connects speakers inside the same AS. It distributes external reachability and policy decisions across that AS. An interior gateway protocol still handles reachability between the routers themselves and resolves BGP next hops.

The base iBGP model assumes a full mesh: every iBGP speaker peers with every other iBGP speaker. That becomes difficult to scale. A route reflector can advertise iBGP-learned routes to selected iBGP clients, reducing the number of sessions. Route-reflector design needs care because a reflector normally exposes only its selected path, and topology can affect route choice.

What a BGP session carries

BGP uses TCP port 179. Two speakers establish a TCP connection, exchange OPEN messages, and confirm the session with KEEPALIVE messages. UPDATE messages advertise new routes, replace route attributes, or withdraw routes. A NOTIFICATION reports an error and closes the connection.

After the initial permitted routing information is exchanged, BGP sends incremental changes. It does not periodically resend the entire table as part of its base operation.

Inside a speaker, the standard describes three conceptual routing information bases:

• Adj-RIB-In: routes received from peers before the local decision process.
• Loc-RIB: routes selected after local policy and route selection.
• Adj-RIB-Out: routes selected for advertisement to a specific peer.

Vendor implementations may expose different table names or extra stages. The receive, select, and advertise model remains useful when you troubleshoot.

Attributes turn reachability into policy

BGP carries path attributes alongside destination reachability. The most important starting points are:

• AS_PATH: autonomous systems the route advertisement traversed.
• NEXT_HOP: address used to reach the next router for the route.
• LOCAL_PREF: preference distributed within an AS; higher values are preferred by the base decision process.
• MULTI_EXIT_DISC, usually called MED: a suggestion to a neighboring AS about the preferred entry point among comparable routes.
• ORIGIN: how the originating speaker introduced the route into BGP.
• COMMUNITIES: labels that let policy match groups of routes.

Attributes do not create one universal idea of the best path. Each AS applies local policy. A network may prefer a customer route over a shorter provider route, choose one exit for cost or capacity reasons, or limit where an advertisement may travel.

The well-known NO_EXPORT community tells a receiving network not to advertise the route beyond its autonomous-system or confederation boundary. NO_ADVERTISE tells it not to advertise the route to any BGP peer. Other communities have meanings defined by the network that uses them.

Selection is local, propagation is selective

BGP commonly selects one preferred path for a prefix. The exact sequence can vary by implementation and configuration, so do not memorize one vendor's tie-break list as a protocol law.

Use this reasoning order instead:

1. Is the route accepted by import policy?
2. Is its next hop resolvable?
3. Which accepted route does local policy prefer?
4. Which remaining path wins the decision process?
5. Is that route permitted by export policy for this peer?

The longest-prefix match used to forward a packet is a separate decision. A router can hold selected BGP routes for several prefix lengths. The forwarding table chooses the most specific matching prefix for each destination.

Why policy errors spread

BGP peers exchange claims, not proof that every claim is correct. A bad export policy can leak routes to a provider or peer. A bad origin announcement can attract traffic for someone else's prefix. A sudden flood of routes can exhaust control-plane resources.

Defensive operation uses layers:

• Explicit import and export policy on every eBGP address family.
• Prefix and AS-path filters based on the expected relationship.
• Maximum-prefix limits sized for each peer and reviewed as routing changes.
• Session protection and control-plane filtering.
• Monitoring for unexpected announcements, withdrawals, and path changes.
• Resource Public Key Infrastructure route origin validation, or RPKI ROV.
• BGP Roles and the Only to Customer attribute where supported, to help detect route leaks.

RPKI ROV compares a route's prefix and origin ASN with validated authorization data. The result is Valid, Invalid, or NotFound. It validates the origin, not the full AS_PATH, so it complements filtering and policy rather than replacing them.

Where BGP fits

You need BGP when routing policy crosses autonomous-system boundaries. Internet service providers, content networks, large enterprises with multiple providers, and Internet exchanges all use it. Some private networks also use BGP for controlled route exchange across large internal domains or overlay systems.

You usually do not need BGP for a small single-provider site that can use a default route. Adding BGP creates policy, monitoring, security, and troubleshooting obligations. Receiving a full Internet table is not a badge of maturity. It is useful only when the routing design needs that information and the platform can handle it.

BGP also does not replace an interior gateway protocol. BGP tells your AS which external paths it prefers. The interior protocol tells routers how to reach internal next hops. Forwarding succeeds only when those layers agree.

A route toward competence

Start by reading routes as structured claims: prefix, next hop, path, attributes, and source peer. Then learn how your platform expresses import and export policy. Build small labs with private ASNs before touching production.

Next, study route selection, iBGP scaling, and relationship-based filtering. Practice predicting what each peer should receive before examining actual output. Finish with operational security, RPKI ROV, route-leak prevention, monitoring, and controlled failure tests.

The goal is not to memorize every attribute. It is to explain why a route was accepted, selected, installed, and advertised. That reasoning is the foundation of safe BGP work.