A Healthy Session Does Not Always Mean a Healthy Path
Connectivity may remain available while the route used to reach a destination changes significantly.
A network path is the full sequence of devices, links and networks that packets cross between a source and a destination. Inside an organisation that might mean a branch router, a WAN link, a data centre fabric and an internet edge. Beyond the edge it means the providers, exchange points and peering links that carry traffic onward to a cloud region, a SaaS platform or a customer. Each hop on that journey is chosen by a mix of routing protocols, local policy, load balancing and the current state of the links involved, and any of those inputs can change without warning.
Most monitoring is built to answer a simpler question: is the destination up? Routing sessions report as established, interfaces are up, a ping returns a reply and the service health check passes. From that point of view, everything is fine. Yet the path behind those green indicators can look very different from one hour to the next. Traffic that normally stays on a private interconnect may start crossing the public internet. A flow that usually leaves through a nearby exit may be carried halfway across the network before it reaches a provider. A destination that sat a few hops away may suddenly sit behind several more networks.
These shifts matter because the characteristics of a path shape the experience of everything that uses it. A longer or more congested path adds delay. A path through a busy or poorly provisioned link can introduce loss and jitter. A path that is asymmetric, with requests and replies taking different routes, can confuse stateful firewalls and make troubleshooting from one side misleading. None of these conditions necessarily breaks connectivity, so they rarely trigger an outage alarm, but they are often behind complaints of slow applications, poor call quality or timeouts that come and go.
Path changes also have many possible causes, and not all of them are routing events in the BGP sense. A failed link inside the network, an IGP metric change, an equal-cost multipath (ECMP) hashing decision, a provider rerouting traffic inside its own backbone, a change in DNS or anycast steering, or planned maintenance can all move traffic onto a different path. Treating every change as an incident would be unworkable. The aim of a path investigation is to recognise when the path has moved, understand how far it moved and decide whether the new path explains the symptoms users are seeing.
Compare Network and Routing Paths
Path investigation brings path transitions, alternate paths and BGP or AS-path behaviour into the same investigation.
Network paths and routing paths describe the same journey from two different angles. The network path is what packets actually experience hop by hop, as seen through measurements such as traceroute or path probing. The routing path is what routing protocols have decided, as recorded in routing tables and BGP announcements. Each view on its own can be incomplete: a routing table does not show congestion inside a provider, and a hop-by-hop trace does not explain why a route was chosen. Reviewing them together helps teams connect what changed in the forwarding path with the routing decision that caused it. The following types of evidence are useful starting points.
- Network path changes
- BGP path changes
- Alternate path usage
- AS-path transitions
- Reachability changes
Network path changes
A network path change is any difference in the hops that traffic crosses on its way to a destination. Comparing the current path with the path observed before a problem began shows where the two diverge: at the first hop, at the network edge, inside a provider or close to the destination. The location of that divergence is often the most useful clue in the investigation. A change near the source points towards local links, devices or policy, while a change far downstream suggests a provider or destination network is involved. Because ECMP and load balancing can legitimately spread traffic over several equivalent hops, it helps to compare paths over a period of time rather than relying on a single trace.
BGP path changes
When the divergence sits at or beyond the network edge, the cause is frequently a change in the BGP route selected for the destination prefix. Checking whether the selected route changed at the same moment the forwarding path changed links the two views together. If the forwarding path moved but the BGP route did not, the cause is more likely to lie inside the network or inside a provider's backbone. If both moved together, the routing change is a strong candidate for explaining the new path, and the investigation can turn to why the previous route stopped being preferred.
Alternate path usage
Many destinations can be reached in more than one way, through a backup link, a second provider, a different data centre or a secondary interconnect. Alternate path usage asks whether traffic is now flowing over one of these secondary routes and for how long. A short failover during maintenance is expected. Traffic that stays on a backup path for days, or that alternates between primary and backup paths, suggests that something is preventing the preferred path from being used. Knowing which paths are considered primary and which are considered fallback also helps teams judge whether the alternate path has enough capacity to carry the traffic now being sent across it.
AS-path transitions
At the internet level, a path is described as the sequence of autonomous systems it crosses. An AS-path transition shows which networks were added to or removed from the journey when the route changed. This is particularly useful when the forwarding path has become longer or slower, because it shows whether traffic is now being handed through an extra provider, routed through a different region or exchanged at a different peering point. Transitions that introduce unfamiliar networks deserve attention, while transitions between well-known providers are more often the result of ordinary policy or maintenance changes.
Reachability changes
Reachability describes whether a destination can be reached at all, and from where. During a path change it is common for a destination to remain reachable from some locations but not others, or to become unreachable briefly while routing converges. Tracking reachability alongside path changes shows whether the change was clean, with traffic moving straight from one working path to another, or disruptive, with gaps in which packets were dropped. Partial reachability, where only some sources or some prefixes are affected, is a useful indicator that the problem lies with a specific path rather than with the destination itself.
Review Service Conditions
Latency, packet loss and reachability context can help determine whether a path change coincided with service-performance degradation.
Knowing that a path changed is only half of an investigation. The question users and service owners care about is whether that change made anything worse. Service conditions such as latency, packet loss and reachability provide the evidence needed to answer it. Viewed on the same timeline as path transitions, they show whether performance degraded when the path moved, recovered when it moved back, or was unaffected throughout.
Latency
Latency is often the first service condition to move when traffic takes a different path. A route that adds distance, crosses an extra provider or passes through a congested link will usually raise round-trip time. Comparing latency before and after a path transition, and checking where along the path the increase appears, helps teams tell whether the new path is responsible. A step change in latency that lines up with a path change is a strong signal. A gradual rise that began well before the path moved points towards growing congestion or load instead.
Packet loss
Packet loss has a disproportionate effect on application performance, particularly for voice, video and transactions that are sensitive to retransmissions. Loss that appears only on the new path, or only at a particular hop, suggests that the alternate route is overloaded or that a device along it is struggling. Care is needed when reading hop-by-hop loss, because many routers deprioritise responses to diagnostic traffic. Loss that is visible at an intermediate hop but not at the destination is often harmless, while loss that persists all the way to the destination is much more likely to affect users.
Reachability context
Reachability context completes the picture by showing whether the destination stayed available while the path changed. If reachability held steady while latency rose, the issue is one of performance rather than connectivity. If reachability dropped for some locations during the change, the path transition may explain reports of intermittent failures. If reachability and performance were both normal across the change, the path change is probably not the cause of the problem, and the investigation can move on to applications, servers or other parts of the service.
Correlate service conditions with path transitions
The value of these measurements comes from aligning them with path evidence rather than reviewing them in isolation. Placing path transitions, latency, loss and reachability on a single timeline shows the order in which things happened: whether performance degraded first and the path moved afterwards in response, or whether the path moved first and performance followed. That order matters. It helps teams separate a path change that caused degradation from one that was a reaction to it, and it gives them evidence to share with providers or service owners when the cause sits outside their own network.
When network path, routing and service-condition evidence are reviewed together, teams can:
- Detect when the path to a destination changed, even while connectivity remained available
- Locate where the new path diverges from the previous one
- Check whether a BGP or AS-path change explains the new forwarding path
- Identify whether traffic has moved to an alternate or backup path
- Determine whether latency, packet loss or reachability changed at the same time
A destination that answers a ping is not proof that users are getting the service they expect. Paths move for many reasons, and most of those moves are harmless, but some quietly add delay, introduce loss or route traffic through networks that were never meant to carry it. Investigating network path changes alongside routing behaviour and service conditions gives network teams a way to tell the two apart. Rather than relying on assumptions, they can show what the path looked like, how it changed and whether that change affected the services that depend on it.