AS_PATH Did Not Change, but Traffic Moved: How to Check BGP ORIGIN

When a Familiar AS_PATH Creates False Confidence

Imagine a morning check after a routine network change. Services are reachable and no link has failed, but client traffic now arrives through the more expensive provider. The engineer compares AS_PATH and sees familiar ASNs with the same path length.

BGP is the protocol used to exchange routing information between autonomous systems, or ASes. Each AS has an autonomous system number, or ASN. AS_PATH contains a sequence of ASes encoded in the announcement, but an unchanged AS_PATH does not prove that every other policy and attribute also remained unchanged. Nor is it an exact measurement of the path followed by every packet.

ORIGIN can differ even when AS_PATH remains the same. The engineer’s task is not to edit the configuration immediately, but to establish three facts separately: which attribute changed, where the difference may have appeared, and whether it affected route selection.

First, clarify the traffic direction. Your router chooses a next hop for outbound traffic from the routes it knows. External autonomous systems choose their own paths to your prefix for inbound traffic. A local BGP route change and a shift in inbound traffic can happen at the same time, but that alone does not prove a common cause.

Do Not Confuse ORIGIN with the Origin AS

These concepts answer different questions. The origin AS is the autonomous system from which a prefix started propagating. In a simple AS_PATH made of an ordinary AS sequence, it is usually the rightmost ASN. Aggregation can make that inference more complicated, and the origin AS does not by itself prove that a network is authorized to announce the prefix.

AS_PATH is the sequence of ASes encoded in a BGP announcement. Among other purposes, it supports routing-loop detection and policy decisions. ORIGIN is a separate mandatory attribute carrying a classification of how the route information originated. Because routing policy can rewrite it, ORIGIN should not be treated as an immutable log of the original event.

ORIGIN has three values:

• IGP means the route information is considered internal to the AS that originated the announcement; many implementations assign it to routes introduced through an explicit network announcement;
• EGP means the information was learned through the historical EGP protocol and is now rarely encountered;
• INCOMPLETE means the information was learned by another method and is a common initial value for route redistribution from another source.

The exact behavior of origination and redistribution mechanisms depends on the implementation and configured policy. The numeric codes are IGP = 0, EGP = 1, and INCOMPLETE = 2. Common best-path algorithms prefer the lower code, so they compare IGP as better than EGP, and EGP as better than INCOMPLETE. RFC 4271 defines the ORIGIN values and the general decision process, but it does not prescribe one complete ordering of every criterion for every platform. Check the documentation for the specific implementation. INCOMPLETE does not mean that a route is broken, forged, or untrustworthy. It is only an attribute value.

Capture a Consistent View of One Prefix

Record the prefix, traffic direction, time, and time zone. Pause non-emergency changes while collecting evidence. For every relevant BGP neighbor, retrieve detailed data for that exact prefix, including routes that were not selected as best if the platform retains and exposes them.

Label the processing stage represented by each record:

• the route as received from the neighbor before import, or inbound, policy;
• the route after import policy in the local BGP table;
• the announcement after export, or outbound, policy that your router sends to the neighbor.

Not every platform retains or displays all three views by default. Do not treat the normal routing-table view as proof that local policy did not alter the route.

For every record, save:

• next hop — the address of the next router to which traffic should be sent, plus the neighbor that supplied the route;
• Local Preference — an internal route priority within your AS; a higher value is usually preferred;
• AS_PATH and ORIGIN;
• MED — a hint to a neighboring AS about a preferred entry point; the conditions under which it is compared depend on implementation and policy;
• communities — BGP labels used by networks to apply agreed policies;
• any other platform-specific selection criteria, if present;
• best-path status and the selection explanation, if the system provides one;
• the time when the route appeared or last changed.

Compare the BGP control plane with measured packet flow. An entry in a routing table does not by itself prove which link carried all traffic at the relevant time.

Add an independent external observation. A route collector receives BGP announcements from participating networks, while a looking glass lets you inspect a route from a particular external network. An external service may expose only its selected best route rather than every route it received. Compare observations from the same period and record the network and timestamp associated with each one.

Test Two Competing Explanations

The first hypothesis is that ORIGIN changed inside your network. Review recent changes to the origination mechanism and every policy that can set ORIGIN explicitly. Under common defaults, replacing an explicit network announcement with route redistribution often changes IGP to INCOMPLETE, but this must be verified on the specific platform.

If you are investigating a route received from a provider, compare its pre-import state with the local result. For your own prefix, inspect the post-export announcement separately for every neighbor. This separates the initial value from a local rewrite.

The second hypothesis is that a network along the transit path rewrote ORIGIN. If you send the same ORIGIN to both providers but external observation points see another value only on paths traversing one of them, that is useful evidence of divergence. It does not yet prove that the immediate provider made the change: another AS between your outbound announcement and the observation point may have rewritten it.

Preserve complete attributes, AS_PATH, timestamps, and results from several observation points, preferably in different networks and at different distances along the path. If the provider offers a looking glass, compare its view with more distant observations. Attribute the policy to a specific network only after the evidence localizes the change sufficiently or that network confirms it.

Determine Whether ORIGIN Actually Decided the Result

Finding an ORIGIN difference does not prove that it affected route selection. In many implementations, platform-specific local criteria, Local Preference, local route origination, and AS_PATH length are evaluated before ORIGIN. The exact order, comparison conditions, and additional steps depend on the platform and configured policy.

For outbound traffic, compare every local candidate on your router. If Local Preference differs, for example, the decision will usually be made before ORIGIN is compared. To show that ORIGIN mattered, establish that the routes match on every criterion your platform evaluates earlier and that the selection explanation actually reaches the ORIGIN step.

For inbound traffic, your local best route does not explain the decision made by a remote AS. That investigation requires synchronized external observations, measured traffic flow, and, where possible, an explanation of the policy at the network where selection occurred.

Run any controlled retest in a lab or on an explicitly bounded test segment. Do not change ORIGIN across the production environment merely to confirm a hypothesis.

Cloudflare reports that, in its described experiment, nearly 70% of observed BGP paths received an ORIGIN value different from the one set by the originating network. This is a result of that experiment and its methodology, not a rule about 70% of all Internet routes or traffic.

Fix the Cause Rather Than the Symptom

If your own origination or export policy changed ORIGIN, correct that specific rule: remove the unintended rewrite or restore the intended origination method. If the change occurred outside your AS, a causal fix requires action by the network applying the rewrite. Local policy can only reduce the rewrite’s effect on your route selection in a controlled way.

For predictable outbound route selection, you can set an explicit Local Preference on routes received from providers. Limit the rule to the intended route class or prefixes. Test it first in a lab or on an isolated test segment. Local Preference is normally propagated with routes to internal BGP peers so that routers in the AS make a consistent outbound choice. Therefore, verify that the rule matches only the intended routes and assess its effect on every internal router to which those routes propagate. A standby router is not automatically a safe test environment.

Local Preference inside your network is not a direct mechanism for controlling inbound Internet traffic. In some designs, changing the local best path can indirectly alter the routes you export, so inspect outbound announcements after the change as well. To intentionally influence inbound traffic, use only provider-confirmed communities and other mechanisms the provider supports. AS_PATH prepending — repeating your own ASN in an announcement to make the path less attractive — and MED can act as signals, but external networks are not required to interpret them as you expect.

Do not try to make policy predictable simply by forcing IGP: ORIGIN may not be the deciding criterion, and another network can rewrite it farther along the path. If the evidence localizes the change to a provider, send it your outbound announcement, external observations, and timestamps, then ask for an explanation of the policy and the supported controls available to you.

Before making a change, define the expected primary and backup paths, the scope of the rule, and exact rollback conditions. Afterward, inspect local candidates, announcements sent to neighbors, measured traffic flow, and external observation points. Roll back if the backup path disappears, unexpected announcements or withdrawals begin, or unrelated prefixes are affected.

Anti-Patterns

• treating an unchanged AS_PATH as proof that policy or the actual packet path did not change;
• assuming every INCOMPLETE value indicates an error or an untrustworthy route;
• blaming a specific provider for a rewrite based on one external snapshot;
• changing ORIGIN, Local Preference, MED, and AS_PATH prepending at the same time;
• testing policy on a standby router without checking propagation through internal BGP;
• trying to control inbound traffic with local Local Preference;
• comparing snapshots from different times without a change log;
• treating ORIGIN or the origin AS as proof of authorization to announce a prefix.

Conclusion

An unchanged AS_PATH is only one part of the picture. First separate outbound from inbound traffic, then compare one prefix at consistent processing stages and verify BGP data against measured flow. A different ORIGIN confirms an attribute change, but not automatically who made it or whether it decided the route. Before remediation, prove all three links: where the values diverged, whether selection reached the ORIGIN comparison, and which bounded change can remove a confirmed local cause or reduce dependence on an external rewrite without damaging redundancy.

Sources

• BGP ORIGIN attribute manipulation and its impact on the Internet
• RFC 4271: A Border Gateway Protocol 4