Border Gateway Protocol, or BGP, is how independently operated networks tell one another which parts of the internet they can reach. When a route changes, the update can travel from one network to the next. That makes the internet adaptable, but it also means a bad announcement can spread well beyond the network that created it.
BGP explained in practical terms starts with three objects: an IP prefix, an autonomous system and a path between systems.
The map BGP exchanges
An IP prefix is a block of addresses, such as a range used by a cloud provider, bank or university. An autonomous system, usually shortened to AS, is a network under one technical administration. Each AS has a number that identifies it in routing announcements.
A BGP route pairs a destination prefix with path attributes. The best-known attribute is AS_PATH, a list of the autonomous systems the announcement has crossed. The 2006 BGP-4 standard, RFC 4271, describes the protocol as an exchange of network reachability information between autonomous systems. That information lets a network build a graph of connectivity and remove routes that would form a loop.
BGP does not hand every router one global map. Neighboring routers establish sessions and exchange updates. Each network applies its own policies to the routes it accepts and the routes it passes on.
How an announcement spreads
Suppose AS 64500 operates a service at one prefix. It announces that prefix to two upstream providers. Each provider decides whether to accept the route, places an accepted route in its routing information base and may advertise it to other peers with its own AS number added to the path.
A network receiving several routes to the same prefix chooses one according to local policy and BGP attributes. The shortest AS path can matter, but it is not a universal command to choose the route with the fewest numbers. Commercial relationships, preferences and technical policy can outweigh path length.
Updates are incremental. A router announces a newly available route or withdraws one that is no longer usable. RFC 4271 does not require periodic retransmission of the whole routing table. That keeps routine exchanges manageable, though a large change can still trigger many updates as networks recalculate and advertise their choices.
Why a local error becomes an internet problem
BGP was built to exchange reachability and policy, not to prove that every announcement is authorized. NIST says the protocol lacks built-in security against route hijacking, which can be accidental or malicious.
One common failure is an incorrect origin announcement. A network advertises a prefix it does not own, and some neighbors accept it. Traffic may then be sent to the wrong network, discarded or detoured.
Another failure is a route leak. A route learned from one relationship is announced through another relationship when policy should have kept it private. The AS path can be technically well formed while the commercial or operational path is wrong.
A more specific prefix can attract traffic because internet routing prefers the longest matching prefix. If a network accidentally advertises a smaller block inside another network’s larger block, the incorrect route can win even when its AS path is longer. This is why one mistaken configuration can have effects far from its source.
BGP also converges over time. Different networks can hold different views while announcements and withdrawals travel. An application may look healthy from one region and unreachable from another during that interval. A provider’s status page can also lag the routing event, as our guide to status pages during outages explains.
What route-origin validation checks
Resource Public Key Infrastructure, or RPKI, lets the holder of an IP address block publish a Route Origin Authorization. A ROA states which autonomous system is authorized to originate a prefix and the allowed prefix length.
A network performing Route Origin Validation compares a BGP announcement with that data. The result is commonly valid, invalid or not found. Valid means the origin and prefix length match a ROA. Invalid means a relevant ROA exists but the announcement does not match it. Not found means there is no covering ROA to use for the check.
NIST Special Publication 1800-14 describes RPKI-based origin validation as a way to mitigate some route hijacks and misconfigurations. The word “some” matters. Origin validation checks who starts the route. It does not validate every relationship in the path, prove that a route leak is commercially acceptable or show that the destination service itself is healthy.
Operators therefore combine RPKI with filters, prefix limits, monitoring, peer policy and incident procedures. A control that rejects invalid origins can stop an important class of bad announcements, but it is not a complete security layer for BGP.
How an outage team reads a BGP incident
Start with the destination prefix and the expected origin AS. Compare route collectors or provider telemetry across regions. A change in origin suggests a hijack or configuration error. A sudden path change with the same origin points toward a leak, policy change or loss of an upstream path.
Next, separate the control plane from the service. A route can be visible while traffic fails farther inside the destination network. DNS can also point users to several prefixes, so only part of a service may be affected. Our guide to how DNS works covers that separate layer.
Record the first observed announcement, affected prefixes, origin and path changes, withdrawals and recovery time. Keep timestamps in UTC and state whether they come from the operator, a route collector or your own observation. The WPBV outage tracker includes events only after a provider has published its own incident report, so use live routing telemetry for diagnosis and the provider’s report for the final historical record.
