BGP Basics

The short answer

Border Gateway Protocol (BGP) exchanges IP prefixes and path attributes between routers over TCP port 179. Each router applies policy to decide what to accept, which eligible path to prefer for each prefix, and what to advertise onward. BGP helps build the forwarding table; it does not carry your application packets inside its TCP session.

Before this topic, get comfortable with routing tables and longest-prefix match, administrative distance and metrics, and the TCP handshake.

Autonomous Systems: The internet's real "networks"

An Autonomous System (AS) is a network under a common routing administration that presents a coherent routing policy to other networks. Its AS number (ASN) identifies it in BGP. Modern BGP supports four-octet ASNs as well as legacy two-octet values. One organization can operate multiple ASes; an ASN is not an IP subnet or a count of routers.

Think of airlines negotiating which destinations they can offer through partner airlines. An AS is an airline, a prefix is a group of destinations, an AS_PATH is a sequence of partner airlines, and import/export policy determines which offers can be accepted or passed on. The airline's own flight planning resembles the internal routing that gets traffic to its chosen exit. No single airline dictates every partner's preferences.

Transit usually means buying onward reachability from a provider. Peering usually exchanges reachability to the networks each side agrees to carry, not automatically the entire internet. These are business and routing-policy relationships, not different BGP message types. The ASNs 64496 through 64500 and public-looking address blocks below are reserved for documentation; they are not live destinations to advertise.

eBGP vs. iBGP

• eBGP (external): a session between routers in different ASes. This is the agreement between airlines. It is common at internet boundaries, but also used in private networks and data-center fabrics.
• iBGP (internal): a session between routers inside the same AS. It shares selected BGP reachability and policy inside the airline, including routes learned externally and routes originated locally.

Both use BGP, not different transport protocols. AS membership determines the label, not physical distance. iBGP often runs between loopback addresses reached through OSPF, IS-IS, or static routes. eBGP peers are commonly directly connected, but multihop eBGP exists with explicit reachability and appropriate TTL settings.

First establish the conversation

Before airlines exchange destination offers, their dispatchers need a working connection and compatible terms. BGP likewise needs IP reachability between its configured peer addresses, an allowed TCP connection to port 179, and compatible BGP settings. A working ping alone proves none of the last two.

These are the four base message types; extensions also define messages such as ROUTE-REFRESH. Once established, peers exchange the routes their policies permit, followed by incremental changes, not a periodic full-table broadcast. IPv4 and IPv6 unicast are separate address families; a working TCP session doesn't prove that the intended family is negotiated and enabled.

Active does not mean working. A straightforward startup goes Idle, Connect, OpenSent, OpenConfirm, Established; Active is part of connection acquisition, not a mandatory successful stage. For a nonzero Hold Time, the smaller proposed value wins. If one peer proposes 180 seconds and the other 90, the negotiated value is 90 seconds; a 30-second keepalive interval is a common one-third relationship, not a universal default. Received KEEPALIVEs or UPDATEs refresh the hold timer. A negotiated zero disables that timer and periodic KEEPALIVEs.

Inside the AS: sharing offers without loops

Normally, an iBGP-learned route is not advertised to another iBGP peer. AS_PATH does not grow at each iBGP hop, so it cannot detect these internal announcement loops by itself. The airline cannot have each dispatcher endlessly repeat another dispatcher's offer as though it were new.

A full mesh lets every BGP speaker talk directly to every other BGP speaker: four speakers need 4 * 3 / 2 = 6 sessions. This is a mesh of TCP sessions, not six physical cables, and it applies to the BGP speakers, not every router in the AS. A route reflector scales this by reflecting selected routes according to client/non-client rules. ORIGINATOR_ID and CLUSTER_LIST help detect reflection loops. Think of an internal scheduling desk distributing approved offers; it doesn't have to carry the passengers itself.

A received route still needs a reachable next hop

Suppose edge router R1 learns 203.0.113.0/24 from an eBGP peer at 192.0.2.1. R1 then advertises the route over iBGP to R2, normally preserving NEXT_HOP 192.0.2.1. The iBGP session can be healthy while R2 has no route to that external next hop. The offer arrived, but the airline can't reach the departure airport.

For an existing Cisco IOS/IOS XE IPv4-unicast iBGP session sourced from R1's 10.0.0.1 loopback to R2's 10.0.0.2, neighbor 10.0.0.2 next-hop-self on R1 under the relevant BGP address family implements the second case for this externally learned route. This is one setting, not a complete deployment configuration. First verify the underlying route to R1. Route reflection alone does not fix an unreachable NEXT_HOP; a reflector normally preserves it.

From received offer to forwarded packet

Keep six decisions separate. In the airline analogy, receiving an itinerary, approving it, choosing it, operating it, and offering it to another partner are different jobs.

1. Receive: an UPDATE offers a prefix and attributes. The conceptual per-peer received-route store is the Adj-RIB-In.
2. Apply import policy: accept or reject the prefix and assign policy values such as LOCAL_PREF. A session may be Established while policy accepts zero routes.
3. Check eligibility: reject loops and require a resolvable NEXT_HOP. A long AS_PATH is not automatically invalid; an unreachable next hop is unusable.
4. Select: choose the preferred eligible BGP path for that exact prefix. Selected BGP routes form the conceptual Loc-RIB.
5. Install and forward: the global routing table arbitrates with other route sources for the same prefix, using administrative distance or the platform's equivalent. The forwarding table (FIB) resolves interfaces and next hops for packet delivery.
6. Advertise separately: BGP propagation rules and each neighbor's export policy determine which selected routes enter its conceptual Adj-RIB-Out. Receiving a route does not grant permission to export it.

These RIB names describe protocol roles, not a requirement for three physical copies of every route. This is the normal single-best-path model; features such as Add-Path can change which paths are advertised.

Best path is not longest-prefix match. BGP compares competing paths for 203.0.113.0/24 with one another. If 203.0.113.0/25 is also accepted and installed, packets for 203.0.113.42 follow that more-specific route even when the /24 has higher LOCAL_PREF. Administrative distance, BGP attributes, and packet lookup answer different questions.

"Best" isn't just "shortest"

Within a comparable route type, OSPF uses cost to choose a path. BGP gives local policy a much larger role: transit and peering relationships involve contracts, cost, and trust, not just distance. An airline might prefer a contracted partner over an itinerary with fewer connections. Similarly, BGP compares eligible paths to the same prefix using ordered criteria, including path attributes, rather than measuring end-to-end speed.

The path attributes, and where each one lives

Not every attribute travels the same distance. Some never leave the router they're configured on; others cross AS boundaries and get compared against everyone else's:

An edge router can assign LOCAL_PREF to a route received over eBGP and use it locally before sharing that preference through iBGP. It is not just a rule for iBGP-learned routes. MED comparison is configurable on some platforms, for example Cisco's bgp always-compare-med, but it still comes after LOCAL_PREF and AS_PATH in the ordinary sequence below. Neither attribute forces another AS to follow your preferred return path.

The order BGP actually checks them in

First exclude ineligible routes: an import-policy rejection, an AS_PATH containing your own ASN under normal loop prevention, or an unresolvable NEXT_HOP prevents a route from winning. For the remaining paths to one prefix, this is a simplified Cisco IOS/IOS XE sequence, not a universal checklist for every vendor or enabled feature:

1. Highest WEIGHT (Cisco-specific)
2. Highest LOCAL_PREF
3. Prefer a locally originated route
4. Shortest AS_PATH
5. Lowest ORIGIN type
6. Lowest MED (same neighboring AS by default)
7. Prefer eBGP-learned over iBGP-learned
8. Lowest IGP metric to reach NEXT_HOP

Later tie-breakers include path age in applicable eBGP cases, router ID, route-reflector cluster-list length, and neighbor address. Multipath can install additional qualifying paths when configured; it does not mean every learned path is used. Check your platform's documentation and enabled features before treating this list as exhaustive.

That order is why the common assumption "BGP always picks the shortest AS-PATH" is wrong: LOCAL_PREF is checked first, so a network engineer can deliberately override a shorter external path just by configuring a higher LOCAL_PREF on the longer one.

Worked example: two providers, one destination

Your AS 64496 learns two paths to 203.0.113.0/24, originated by AS 64500. This is a synthetic example, not captured router output. Assume both routes pass import policy, have reachable next hops, and are not locally originated. All earlier criteria tie. Your import policy assigns LOCAL_PREF 200 to provider A and 100 to provider B because A is your preferred outbound contract.

The leftmost AS is the neighboring AS in these ordinary eBGP paths; the rightmost is the origin. Both offers reach the same destination airline, but A uses three AS entries and B uses two. Route A wins at LOCAL_PREF. B's shorter path is never consulted. AS_PATH counts AS entries, not physical routers or measured milliseconds.

If A withdraws the prefix, or its session fails and the route is removed, B can become best. That requires B to remain eligible, resolve to a working next hop, and be installed for forwarding. Detection, route processing, and FIB updates take time; graceful-restart behavior can also affect route retention. This is not a promise of instant failover or preserved application sessions. If both LOCAL_PREF values were 100 instead, B would win at AS_PATH length under the stated assumptions.

This controls traffic leaving your AS toward that prefix. Return traffic is selected independently by other ASes. Advertising your own prefix with extra copies of your ASN (AS-path prepending), a MED, or an agreed provider community can influence inbound routing, but a provider's higher-priority policy may override the hint. The airline can choose its outbound partner; it cannot dictate every partner's return itinerary.

Accept and export deliberately

The airline analogy has a limit: an offer is not proof of permission to serve a destination. BGP does not inherently verify that a neighbor is entitled to originate or re-advertise every prefix it sends.

• Explicit import and export policy: accept only the reachability your relationship calls for, and advertise only your authorized prefixes or agreed customer routes. A dual-provider enterprise must not accidentally export routes from provider A to provider B and become unintended transit. RFC 8212 specifies default rejection without explicit eBGP policy; deployed defaults and configuration modes still vary.
• Prefix and length filters: specify both permitted networks and permitted more-specific lengths. Accepting 203.0.113.0/24 exactly is different from allowing every more-specific prefix inside it.
• Maximum-prefix limits: set an expected ceiling with an intentional response. Depending on platform and settings, exceeding it can warn, stop accepting routes, or shut down the session. It is a volume safeguard, not proof that accepted routes are legitimate.
• Session protection: restrict who can reach the router's BGP control plane and use supported, agreed peer authentication and TTL-security settings. Protecting a TCP session does not authorize the prefixes carried inside it.

Communities are policy labels

A standard BGP community is a 32-bit value commonly displayed as two 16-bit numbers, for example 64496:100. Like an airline's internal contract label, that number has the meaning its operators assign to it. It has no universal "prefer this provider" effect: a matching policy must take an action, such as setting LOCAL_PREF. Check whether communities are actually sent, retained, or removed along the path.

Well-known communities have defined meanings: NO_EXPORT prevents advertisement outside an AS in the ordinary non-confederation case, while NO_ADVERTISE prevents advertisement to any BGP peer, including iBGP peers. These are routing instructions, not encryption or an access-control boundary for application traffic. Extended and large communities support other uses; a standard two-field community cannot fit an arbitrary four-octet ASN in its first field.

RPKI checks the origin, not the whole journey

Resource Public Key Infrastructure (RPKI) lets address holders publish Route Origin Authorizations (ROAs). Validated ROA data associates a prefix with an authorized origin ASN and maximum prefix length. Routers use that data for route origin validation: does this announcement's origin and length match an authorization?

For this synthetic example, assume the validator has exactly one relevant authorization: 203.0.113.0/24, origin 64500, maximum length 24, and none covering 198.51.100.0/24.

Valid does not validate the entire AS_PATH or prevent every route leak. NotFound is not the same as Invalid. Configure how validation states affect import policy, keep the validator healthy, and check ROA changes before treating an unexpected Invalid as proof of an attack. In the airline analogy, an origin authorization checks who can offer the destination, not every onward agreement in the itinerary.

Troubleshoot in the order BGP depends on things

Start with the connection, then the offers, then the chosen itinerary, then actual delivery. These are read-only Cisco IOS/IOS XE IPv4-unicast examples for routers you administer. Syntax and output vary by release and address family; the addresses refer to the documentation scenario, not targets to probe on the internet.

show ip bgp summary
show ip bgp neighbors 192.0.2.1
show ip bgp 203.0.113.0 255.255.255.0
show ip route 192.0.2.1
show ip route 203.0.113.42
show ip cef 203.0.113.42
show ip bgp neighbors 192.0.2.1 advertised-routes

Record the peer, address family, exact prefix, selected path, and last reset reason before changing anything. A blanket session clear can withdraw many working routes and erase useful evidence. Use an approved change plan for policy edits or resets; these examples do not require either.

Related topics

Continue with packet lookup and longest-prefix match, the IGP that reaches BGP next hops, diagnostic tools, and packet capture. Route-reflector design, full-table capacity planning, and advanced traffic engineering deserve separate treatment.

Sources and scope

Reviewed against the references below on 21 September 2026. The examples are synthetic IPv4-unicast scenarios; no router configuration, failover, or production network was exercised. Best-path options, command syntax, defaults, and convergence behavior depend on the platform and software release.

• RFC 4271: BGP-4, especially sessions, attributes, next-hop resolution, and the decision process.
• Cisco: BGP best-path selection, including WEIGHT, MED options, tie-breakers, and multipath.
• RFC 4456: route reflection and its propagation and loop-prevention rules.
• RFC 1997: BGP communities, including NO_EXPORT and NO_ADVERTISE.
• RFC 8212: explicit eBGP import and export policy.
• RFC 6811: prefix origin validation and its security limitations.