Connectivity Can Remain Available
A BGP path can change even when connectivity remains available. The new path may influence traffic distribution, latency, reachability or service performance.
Every route a network learns through Border Gateway Protocol (BGP) carries an AS path: the sequence of autonomous systems (AS) the announcement has passed through on its way from the origin. When a router has more than one route for the same prefix, it applies its best-path selection process, considering attributes such as local preference, AS path length, origin type and multi-exit discriminator, to decide which route to use. A path change happens whenever that decision produces a different result, either because a new route has appeared, an existing route has been withdrawn, or the attributes of a route have changed.
Path changes are a normal part of how BGP works. Upstream maintenance, a session reset, a provider adjusting its routing policy, AS-path prepending used for traffic engineering, or a link failure somewhere along the path can all cause a route to move. In most of these cases the destination remains reachable. Packets still arrive, BGP sessions stay established and interface monitoring reports nothing unusual.
That is exactly why path changes are easy to overlook. A route that moves from a direct peering connection to a transit provider, or from one upstream to another, can send traffic through a longer, more congested or more distant path. Users may notice slower applications, higher latency or intermittent loss before anyone has connected the symptoms to a routing change. Traffic may also shift between links, changing how load is distributed across upstreams and potentially pushing a link towards capacity.
Some path changes are a warning of something more serious. A path that passes through an unexpected network can be a sign of a route leak or a misconfiguration elsewhere on the internet. A series of path changes can be a precursor to a prefix becoming partially or fully unreachable. Because the same symptom can have very different explanations, the goal of a path investigation is to establish what changed, where it changed and whether the change matters, rather than to assume that every new path is a problem.
Path Evidence to Compare
Path investigation uses BGP and AS-path evidence to understand how the route changed.
A single routing update rarely explains a path change on its own. Investigating effectively means comparing what the route looked like before the change with what it looks like afterwards, and examining the change from several angles. The following types of evidence help teams understand how a route changed and whether the change is consistent with expected routing behaviour.
- Path transitions
- Alternate routing paths
- Path-length changes
- Upstream changes
- Unexpected AS transitions
Path transitions
A path transition is the move from one AS path to another for the same prefix. Recording each transition with its time, the old path and the new path gives teams a timeline of how the route evolved. A single transition that coincides with planned maintenance is very different from a prefix that switches back and forth between paths several times in an hour. The frequency, timing and pattern of transitions help separate a one-off change from ongoing instability or route flapping that may need further attention.
Alternate routing paths
Most networks have more than one way to reach important destinations. Knowing which alternate paths exist, and which of them is normally preferred, puts a change into context. If a route has moved to a known backup path, the question becomes why the primary path is no longer selected. If it has moved to a path that has not been seen before, the investigation needs to establish where that path came from. Viewing the paths offered by different peers and vantage points also shows whether the change is local to one part of the network or visible more widely.
Path-length changes
The number of autonomous systems in an AS path is one of the attributes BGP uses to choose between routes, and a change in path length is often one of the first visible signs that a route has moved. A longer path can mean traffic is travelling through additional networks, while a sudden shortening can mean a new, more direct route has appeared. Path length should be read with care, however. AS-path prepending deliberately repeats an AS number to make a path less attractive, so a longer path may reflect an intentional traffic engineering decision rather than additional networks. In addition, the number of AS hops does not directly reflect physical distance or latency. Path-length changes are best treated as a prompt to examine the path itself.
Upstream changes
The upstream is the neighbouring AS immediately after the local network in the path, usually a transit provider or peer. A change of upstream alters where traffic leaves the network and which provider carries it onward, which can affect cost, capacity and performance. Upstream changes frequently follow a session going down, a provider withdrawing routes, or a change in local preference or other policy. Identifying which upstream a route moved from and to, and whether other prefixes moved at the same time, helps teams decide whether the cause lies with a specific provider or with their own configuration.
Unexpected AS transitions
Some path changes introduce networks that do not normally appear in a route, or adjacencies between autonomous systems that are not usually seen together. A prefix that suddenly passes through an unfamiliar network, or a path in which one provider appears to be offering transit between two others, warrants a closer look. Such changes can indicate a route leak or a policy error elsewhere, but they can also reflect a new peering relationship or a legitimate provider change. Comparing the new path against the paths historically observed for the prefix helps teams decide whether the transition is genuinely unexpected and how much attention it deserves.
Add Prefix, Peer and Reachability Context
Prefix-specific, peer-specific and reachability evidence helps teams understand where a path changed and whether the change coincided with connectivity degradation.
Path evidence describes how a route changed. On its own, it does not say how far the change reached or whether it had any effect. Adding prefix, peer and reachability context turns a list of path transitions into an explanation that teams can act on.
Prefix context
Looking at a path change prefix by prefix shows its scope. If only one prefix moved, the cause is likely to be specific to that route, such as a change by its origin network or a more specific announcement. If many prefixes moved together, the change is more likely to involve a shared upstream, peer or policy. Prefix context also shows whether the affected routes include important prefixes, such as those that host customer-facing services or a network's own address space, which helps teams decide how urgently the change needs attention.
Peer context
Peer-specific evidence shows where in the routing environment the change was introduced. Reviewing which peer stopped advertising the previous path, which peer now provides the selected path, and whether any sessions reset or sent bursts of updates around the same time helps locate the source of the change. When several peers report the same new path, the change probably happened further upstream. When only one peer is involved, the investigation can focus on that relationship.
Reachability context
The most important question in many investigations is whether the path change coincided with connectivity degradation. Reachability evidence shows whether a prefix remained visible, became partially visible or was withdrawn during the change, and whether reachability recovered once routing stabilised. Placing path transitions on the same timeline as reachability changes and reported symptoms helps teams see whether a routing change explains a performance problem or whether the cause is likely to lie elsewhere, such as in an application, a server or the transport network.
When prefix, peer and reachability context are combined with path evidence, teams can:
- Identify which prefixes changed path and when the change began
- Compare AS paths before, during and after the change
- See which peer or upstream introduced the new path
- Check whether reachability was affected while the path changed
- Build a routing timeline that supports investigation and communication with providers
BGP path changes are not always problems, and treating every transition as an incident would quickly overwhelm any team. Equally, a path change that goes unnoticed can leave teams searching for the cause of slower applications or uneven traffic in the wrong place. Continuous visibility into paths, prefixes, peers and reachability gives network teams the evidence to tell the difference, so they can focus on the path changes that affect services and explain them with what the routing data shows rather than with assumptions.