Repeated Routing Changes
Route flapping occurs when routes repeatedly change state. Repeated announcements and withdrawals can create instability even while connectivity remains available.
In Border Gateway Protocol (BGP), a network tells its neighbours which prefixes it can reach by sending announcements, and tells them when it can no longer reach a prefix by sending withdrawals. A single announcement or withdrawal is routine. Routes are added when new services come online, removed when they are decommissioned and adjusted when providers change policy. Route flapping describes something different: the same route being announced, withdrawn or changed over and over again within a short period, without settling into a stable state.
Each of those changes has to travel. When a route flaps, every router that has learned it must process the update, rerun its best-path selection and, in many cases, pass the change on to its own neighbours. A single unstable link at the edge of one network can therefore generate a stream of updates that reaches many other networks. The extra processing consumes router CPU and memory, and while routing tables catch up, traffic may briefly follow an outdated path, take a less preferred route or be dropped.
Flapping is easy to miss because it often does not look like an outage. A prefix may only be unavailable for a few seconds at a time, or it may move between a primary and a backup path without ever becoming unreachable. Ping tests keep succeeding, BGP sessions may stay established and the destination still appears in the routing table most of the time. What users experience instead is intermittent: short bursts of packet loss, retransmissions, dropped sessions, fluctuating latency or applications that feel unreliable without an obvious reason.
The underlying causes vary widely. A physical link with errors or an optical problem can go up and down repeatedly. A BGP session can reset because of hold-timer expiry, maximum-prefix limits or an unstable transport path. Interior routing instability that is redistributed into BGP can surface externally as flapping. Configuration problems or interactions between routing policies can cause a route to oscillate between paths. Because the same symptom can come from so many places, investigating route flapping means first establishing exactly what is repeating, where it is repeating and for how long.
Some networks respond to flapping with route flap dampening, a mechanism that temporarily suppresses routes that change too often. Dampening can reduce the load caused by unstable routes, but it also means a route may remain unavailable for a period after the underlying problem has been fixed. Understanding the flapping itself is still necessary, both to resolve the cause and to explain why a route was suppressed.
Evidence to Investigate
Teams can narrow the investigation by reviewing the route and the routing entities associated with repeated events.
A burst of routing updates on its own does not explain much. The useful questions are which routes are changing, what kind of change keeps repeating, and which prefixes, peers and paths are involved. Reviewing the following types of evidence together helps teams separate genuine instability from normal routing activity and move from the symptom towards the source.
- Repeated announcements
- Repeated withdrawals
- Prefix instability
- Peer-related instability
- Changing path behaviour
Repeated announcements
An announcement tells neighbours that a route is available. When the same prefix is announced repeatedly, it may be returning after a withdrawal, or it may be re-announced with different attributes such as a new AS path, next hop, community or multi-exit discriminator. Reviewing what changed between consecutive announcements is important. Announcements that carry identical attributes can point to session resets or duplicate updates, while announcements whose attributes keep changing suggest that the route itself is moving between options. The timing between announcements also matters: a regular rhythm can point to a timer, a scheduled process or a link that fails and recovers on a predictable cycle.
Repeated withdrawals
A withdrawal tells neighbours that a route is no longer available. Withdrawals are the part of flapping most likely to affect connectivity, because for each withdrawal there may be a moment where some networks have no route, or only a less preferred one, for the prefix. Counting how often a prefix is withdrawn, how long it stays withdrawn and how quickly it returns helps teams judge the likely impact. Very short withdrawal periods may only cause brief loss, while longer or more frequent withdrawals can leave a prefix unreachable from parts of the internet for noticeable periods.
Prefix instability
Looking at instability prefix by prefix shows its scope. If a single prefix is flapping while others from the same origin stay stable, the cause is likely to be specific to that route, such as the link or service behind it or the way it is originated. If many prefixes flap together, the cause is more likely to be shared: a session, a router, an upstream or a policy that affects them all. Prefix context also shows whether the unstable routes include important address space, such as prefixes that host customer-facing services, which helps teams decide how urgently the instability needs attention.
Peer-related instability
Peer-specific evidence shows where in the routing environment the instability is entering. Reviewing which peers are sending the repeated updates, whether those peers' sessions are resetting, and whether the same pattern is visible from several peers helps locate the source. When only one peer reports the flapping, the problem may sit on that session or with that neighbour. When several peers and vantage points see the same repeated changes, the instability is more likely to originate further upstream or at the origin of the route. A peer that sends a sudden burst of updates for many prefixes at once is often a sign of a session reset or a full table being re-advertised.
Changing path behaviour
Not every flap involves a route disappearing. Sometimes a prefix stays reachable but its AS path keeps changing, alternating between providers or between a primary and a backup route. These oscillations can be caused by a failing link on the preferred path, by interactions between routing policies, or by path exploration, where routers briefly try alternative paths after a withdrawal before converging. Comparing the sequence of AS paths over time shows whether the route is moving between a small set of known paths, introducing unfamiliar networks, or changing path length in a way that could affect latency and traffic distribution.
Focus Operational Attention
Route-flap monitoring and routing analytics help identify persistent conditions so teams can prioritize meaningful routing behaviour for further troubleshooting.
Routing on the internet is never completely still. At any moment, some routes are changing because of maintenance, policy updates or failures elsewhere, and most of that activity resolves on its own. The challenge for network teams is not to react to every update, but to recognise which repeated changes are persistent, which affect important prefixes or peers, and which are likely to have an operational impact.
Separate persistent flapping from transient events
A short burst of updates during a planned change or immediately after a session reset is usually expected. Flapping that continues for hours, recurs every day at similar times, or returns after it appeared to stop is a stronger signal that something needs to be fixed. Looking at update activity over a longer window, rather than only at the most recent events, helps teams tell one-off churn apart from a condition that will keep recurring until its cause is addressed.
Compare activity against a baseline
Every network has its own normal level of routing activity. A prefix announced by a large, busy network may see more updates than a prefix that rarely changes. Comparing current announcement and withdrawal rates against what has historically been observed for the same prefixes and peers makes it easier to see when activity is genuinely unusual, and avoids treating naturally busy routes as problems.
Correlate routing changes with symptoms
The most useful question in many investigations is whether the flapping coincided with reported issues. Placing repeated announcements, withdrawals and path changes on the same timeline as reachability changes, session events and user reports helps teams see whether routing instability 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 route-flap evidence is reviewed alongside prefix, peer and path context, teams can:
- Identify which prefixes are flapping and when the instability began
- Distinguish repeated withdrawals from attribute or path changes
- See which peers or upstreams are associated with the repeated events
- Recognise persistent or recurring patterns rather than reacting to single updates
- Build a routing timeline that supports troubleshooting and communication with providers
Route flapping is rarely dramatic. It tends to show up as intermittent loss, unexplained latency or routes that never quite settle, and it can persist for a long time if nobody connects the symptoms to the routing data. Continuous visibility into announcements, withdrawals, prefixes, peers and paths gives network teams the evidence to find the instability that matters, focus their troubleshooting on it, and explain what happened with what the routing data shows rather than with assumptions.