BGP, the Border Gateway Protocol, lets autonomous systems exchange routes to IP prefixes and decide which routes to accept, use, and advertise. A route includes information about the destination and the path toward it. Each network applies its own routing policy, so a route with fewer autonomous systems in its path does not automatically win.

An autonomous system, or AS, presents a consistent routing policy to other networks and is identified by an autonomous system number, or ASN. Its routers can use external BGP, or eBGP, to exchange routes with another AS and internal BGP, or iBGP, to distribute BGP information within their own AS. Those sessions carry routing information, while the forwarding table determines where packets actually go.

The examples below use addresses and ASNs reserved for documentation. They illustrate hypothetical routing decisions, not live Internet announcements.

ASNs Identify Networks; Prefixes Identify Destinations

An ASN identifies an autonomous system, not an individual router or an address block. A prefix identifies a range of destination addresses. One AS can originate multiple prefixes, and another AS can advertise paths toward them without being their origin.

For example, 203.0.113.0/24 covers the addresses from 203.0.113.0 through 203.0.113.255. The slash length describes the leading address bits shared by that range. Announcing this prefix advertises a route toward the range rather than reporting that all 256 addresses contain active devices.

The originating AS introduces the route into BGP. Neighboring networks may then advertise that reachability onward, subject to their export policies. A network does not have to originate a destination prefix to help carry traffic toward it.

This distinction matters when reading an AS path. The neighboring AS that sent an announcement and the AS that originated the destination are different roles. A registration record for an ASN also does not by itself prove that the AS is currently advertising a particular prefix.

A Peer Session Carries Routing Messages

A BGP peer is another BGP speaker with which a router exchanges messages. BGP uses TCP to provide a reliable connection between peers, with port 179 used for the listening service. Reaching that port alone does not establish a working exchange: the peers must also open the BGP session and agree on the relevant parameters.

OPEN messages establish the session parameters, and KEEPALIVE messages help maintain it. Once the session is established, UPDATE messages advertise routes or withdraw previous advertisements. After the initial exchange of eligible routes, updates normally describe changes rather than periodically resending the entire routing table.

An established BGP session does not prove that either peer has a usable route to a particular destination. For example, an import filter can reject every received prefix, or an export filter can permit nothing to be sent.

Follow an Announcement from Origin to Receiver

Suppose AS64496 originates the documentation prefix 203.0.113.0/24. If AS64497 learns that route and advertises it to another external neighbor, the simple AS sequence at that receiver would be 64497 64496. The nearest advertising AS appears first, and the originating AS appears at the end of this straightforward sequence.

The receiver also needs a next hop: an address through which it can reach the advertised destination. AS_PATH describes AS traversal, while NEXT_HOP identifies the forwarding next hop for the route. The AS sequence is not a list of every router interface that packets will cross.

The router must be able to resolve the next hop before it can use the route. That can involve another route in its own routing table. A valid-looking prefix and AS path are insufficient if the next hop cannot be reached.

AS_PATH also helps detect routing loops. In ordinary operation, a router excludes a received route that already contains its own AS number. The check prevents that AS from treating an announcement that has returned through other networks as a new usable path.

Receiving a route is only the start of its local processing. The router applies import policy, compares eligible alternatives, and considers the resulting route for installation. Export policy separately determines which information a neighbor is allowed to receive.

Routing Policy Comes before a Simple Path Count

LOCAL_PREF expresses the preference for a route within an AS, with a higher value favored. It lets the AS prefer one exit over another for the same destination prefix. In ordinary operation outside a confederation, LOCAL_PREF is shared with internal peers rather than sent to external peers.

Consider two otherwise eligible routes to 203.0.113.0/24 at a router in AS64500. One has the AS sequence 64497 64496 and a local preference of 150. The other has 64498 64499 64496 and a local preference of 200.

If earlier selection criteria tie and local preference is evaluated before AS path length, the second route wins despite its longer AS sequence. These values illustrate a policy choice; they are not recommended settings for every network. Reversing the preferences under the same conditions would change the outcome without changing either sequence.

AS path length can become decisive when earlier selection criteria tie. Even then, the count is not a measurement of latency, available bandwidth, or physical distance. Repeating an AS number through prepending can also lengthen the advertised path without adding another network.

The Multi-Exit Discriminator (MED) attribute can express a preference among entry points into a neighboring AS. A lower MED is preferred when the routes qualify for comparison and earlier criteria tie. By default, MED values are generally compared for routes from the same neighboring AS; configuration can change that behavior.

Implementations also have other selection criteria, and configuration can alter their behavior. For example, a local weight setting may precede local preference on an implementation that supports it. Diagnose a choice using the router's actual rules and settings rather than assuming one shortened list applies to every product.

eBGP Connects ASes; iBGP Shares Information within One

An eBGP session normally connects speakers in different ASes. When a route crosses to another AS, the advertising speaker adds its AS to the path. An iBGP session connects speakers in the same AS and normally preserves the AS path rather than adding that AS again for each internal router.

For an AS with two border routers, one router might learn a destination externally and share that route with the other through iBGP. Both routers still need internal reachability to the route's next hop. Learning an external prefix through iBGP does not create the internal links or internal routes needed to forward toward that exit.

Ordinary iBGP also restricts readvertising a route learned from one internal peer to another internal peer. A full mesh of sessions or a suitable design such as route reflection provides the required distribution. That is a session design question, not a requirement to connect every router with a dedicated physical cable.

A Withdrawal Removes One Advertised Route

A withdrawal tells a peer that a previously advertised route is no longer available through that advertisement. The receiver removes that candidate and reassesses the remaining routes to the prefix. It can select another eligible path if one exists, so a withdrawal does not automatically make the destination unreachable everywhere.

In the earlier example, withdrawing the path with local preference 200 could leave the path with preference 150 as the usable alternative. The new selection depends on the remaining route still passing policy and having a reachable next hop. If neither route is usable, the router needs another matching route to forward traffic.

A changed announcement can also replace a previous path for the same prefix. The advertised destination might remain reachable while its attributes or chosen exit change. Keep that event distinct from losing the prefix entirely.

Changes take time to be detected, processed, and propagated. There is no single convergence duration that applies to every network and failure. Session behavior, remaining paths, processing, and export policy all affect when another router sees a usable replacement.

The Forwarding Table Uses the Destination Address

BGP compares candidate paths for a destination prefix. Packet forwarding then looks up the packet's destination address in the installed forwarding table. These are related operations, but the router does not rerun the entire BGP selection process for every packet.

Where overlapping usable prefixes are installed, ordinary IP forwarding chooses the longest matching prefix. For example, a destination within an installed /24 matches that route more specifically than an installed /16 containing the same address. A high local preference on the /16 does not turn it into a longer match.

When a route appears in BGP output but traffic does not follow it, inspect whether that route was actually installed and whether another matching prefix is more specific. Also check the return direction separately: another AS applies its own policy and can choose a different path back. A BGP announcement alone does not verify application availability at the destination.