What Is AS Path Prepending? BGP Inbound Traffic Engineering

AS path prepending is a traffic engineering technique where a BGP speaker intentionally repeats its own AS number multiple times in the AS_PATH attribute when announcing a prefix to a neighbor. Because the BGP best-path algorithm prefers shorter AS paths (step 4), artificially lengthening the path on one link makes that link less attractive to remote networks choosing how to reach you. It is the most widely deployed mechanism for inbound traffic engineering without requiring any coordination with upstream providers.

How Prepending Works

When AS 64500 originates the prefix 203.0.113.0/24 and has two upstream providers — Transit-A (AS 3356) and Transit-B (AS 174) — the normal announcement produces paths that downstream networks see as:

Both paths are length 2. Remote routers will pick between them based on lower-priority criteria such as local preference, MED, or router ID — the choice is effectively outside your control. Now suppose AS 64500 wants to shift inbound traffic to arrive via Transit-A. It applies a route-map on the session toward Transit-B to prepend its own ASN twice before export:

Remote routers that receive both paths will now prefer Transit-A because its path is shorter — AS path length is step 4 in best-path selection and will decide the winner unless a higher-priority attribute (weight, local-pref) differs first.

Why Operators Prepend

The primary motivation is inbound traffic engineering: controlling which upstream link carries the majority of incoming traffic. Common scenarios include:

• Primary/backup links — Prepend heavily (3–5 times) on the backup upstream so that all traffic uses the primary. Traffic shifts automatically when the primary fails because the prepended path remains reachable.
• Capacity balancing — Prepend once or twice on the higher-capacity link to nudge some traffic toward the smaller link, filling it without saturating it.
• Cost management — If Transit-B charges by the 95th percentile of inbound traffic and Transit-A has flat-rate billing, prepending toward Transit-B reduces billable peaks.
• Geographic preference — A network with a US uplink and a European uplink can prepend on the US side for a European prefix (or vice versa) to bias regional traffic to the closer link.

Diminishing Returns and the Local-Pref Problem

Prepending is effective only when AS path length is the deciding criterion in remote networks' best-path selection. Because local-pref (step 2) and policy-driven weight (step 1) are evaluated before AS path length, any upstream provider or large network that sets a local-pref based on business relationship will ignore your prepending entirely for routes covered by that policy.

A concrete example: if a major ISP sets local-pref 200 on all routes from its customers (you, via Transit-A) and local-pref 100 on peer routes (via Transit-B), then no amount of prepending on the Transit-A session will make that ISP's routers prefer Transit-B. Local-pref 200 wins at step 2; AS path length at step 4 is never reached. The ISP will always send you traffic via Transit-A regardless of how many times you prepend.

This is why prepending has more impact on peer networks than on customer networks of your upstreams, and why excessive prepending often produces much less effect than operators expect.

Prepend Stripping

Some networks actively strip repeated ASNs from received paths before installing or re-advertising routes. The rationale is that duplicate ASNs in a path carry no topological information — they only encode the sender's traffic engineering intent, which may conflict with the receiver's own policies. Stripping is a legitimate local policy and is permitted by RFC 4271, which says only that a router must not modify the AS_PATH it received from an eBGP peer in ways that corrupt loop detection; removing duplicates does not affect loop detection because a single occurrence of the AS remains.

Networks known to strip or limit prepends include some large European IXP route servers and certain tier-1 providers. Operators who rely heavily on prepending should verify its effect using looking glasses, including this one — look up your prefix and compare AS paths visible via multiple vantage points.

Excessive Prepending as a Hijack-Amplification Risk

Prepending introduces a subtle security risk: a BGP hijacker announcing your prefix without prepending will produce a shorter path than your own heavily-prepended announcements. Networks that would normally prefer your legitimate path (because it originated from you) may switch to the hijacker's announcement if it appears shorter. The hijack succeeds more broadly because prepending has pre-weakened your own routes in the global table.

A documented pattern in BGP hijacking is for an attacker to identify prefixes with heavy prepending and specifically target them, knowing that even a simple origin-only announcement will be competitive. Prepending more than 3 times should be considered carefully in any network that values resilience against hijacking. Deploying RPKI ROAs for your prefixes is the correct countermeasure — ROV-enforcing routers will drop the hijacker's announcement regardless of its path length.

Alternatives to Prepending for Inbound Traffic Engineering

MED (Multi-Exit Discriminator) — If your two upstreams are the same provider (e.g., two PoPs of the same ISP), you can set different MED values to tell the provider which entry point you prefer. MED is only compared between routes from the same neighboring AS by default, so this works only in that specific topology. See best-path selection for MED details.

BGP communities — Many transit providers expose community strings that let customers remotely influence local-pref or MED within the provider's network. For example, Lumen (AS3356) accepts well-known communities to set local-pref on a per-region basis. This is far more powerful than prepending because it affects step 2 of best-path selection, not step 4. See BGP communities for how this works.

Selective announcement — Instead of announcing the same prefix everywhere, announce a more-specific prefix (e.g., a /25 carved out of your /24) only to the preferred upstream, and announce the /24 to both. Remote networks route to the more-specific via the preferred upstream. This is very effective but requires that the more-specific meet minimum announceable size requirements (typically /24 for IPv4) and that you have sufficient address space to split.

No-export community — Announcing a prefix with NO_EXPORT (65535:65281) to an upstream tells them not to re-advertise it beyond their AS. Used in combination with announcing a full aggregate elsewhere, this can control reachability at an AS level rather than just biasing path selection.

Implementation

On Cisco IOS/XE, prepending is configured in a route-map applied to a neighbor's outbound updates:

route-map PREPEND-TO-TRANSIT-B permit 10
 set as-path prepend 64500 64500 64500

router bgp 64500
 neighbor 198.51.100.1 route-map PREPEND-TO-TRANSIT-B out

On Junos, the equivalent is a policy with as-path-prepend:

policy-options {
    policy-statement PREPEND-TO-TRANSIT-B {
        term 1 {
            then {
                as-path-prepend "64500 64500 64500";
            }
        }
    }
}

You can prepend any number of times, but more than 3–5 is rarely useful and increases hijack exposure. Some operators prepend exactly once to create a mild preference without dramatically altering path length. RFC 4271 places no explicit limit on AS_PATH length, though extremely long paths (20+ hops) may be filtered by some networks as anomalous.

Prepending and Route Reflectors

Inside an AS, iBGP sessions distribute external routes to all edge routers. Route reflectors (RFC 4456) are a common way to avoid the full-mesh requirement. When a route reflector receives a route with a given AS path and distributes it internally, the AS path is preserved — your prepend configuration on the outbound eBGP session toward Transit-B will correctly produce a longer path as seen by the internet, but internally your iBGP peers will see only the route as you received it from Transit-A (which has the original, un-prepended AS path). This means prepending has no effect on which path your own routers prefer for outbound traffic — that is controlled by local preference and other inbound-facing attributes.

Interaction with ADD-PATH

RFC 7911 (BGP ADD-PATH) allows a BGP speaker to advertise multiple paths for the same prefix to an iBGP peer. In networks running ADD-PATH, edge routers receive both the Transit-A path (shorter) and the Transit-B path (longer, because you prepended) via iBGP. The iBGP speaker can then make a local best-path decision using both options, potentially installing both in the FIB for load-sharing. Prepending still controls which path remote networks prefer inbound; ADD-PATH controls which paths are available to your own routers for outbound load balancing.

Detecting Prepending in the Wild

Repeated ASNs in a path are the telltale sign of prepending. In BGP output, the path is shown as a space-separated list, for example:

3356 174 64500 64500 64500

This shows that the path transited Lumen (3356) then Cogent (174) then reached AS 64500, which prepended itself twice. The prefix is reachable via this path but a competing path through a different upstream with 3356 64500 (if one existed) would be strongly preferred by most routers.

A path where the same ASN appears more than 5 times is almost always either aggressive traffic engineering or a configuration error. Some route servers at IXPs set policies to strip repeated prepends beyond a limit (commonly 3–5 occurrences) to prevent prepend abuse from distorting route selection for all IXP members.

Verifying the Effect

After configuring prepending, verify that the intended paths appear in the global routing table by checking multiple looking glasses and route collectors. The path seen from a vantage point near each upstream will differ — that is expected. What you want to confirm is that the majority of the internet (and particularly traffic-heavy networks like large content providers) sees the shorter, preferred path. Tools like RIPE RIS and RouteViews collect routes from hundreds of BGP peers worldwide and let you compare visibility.

Prepending in the Context of Traffic Engineering

Prepending is one of several levers described in BGP traffic engineering. It is the coarsest lever — it influences the path length globally and relies on remote networks' policy not overriding step 4 of best-path selection. For targeted, surgical inbound traffic engineering, provider communities are almost always more effective. For broad, simple primary/backup scenarios with a cold-potato topology and predictable upstream policies, prepending works reliably.

A common operational approach is to use both: set local-pref via communities with providers that support it, and use prepending as a fallback for the long tail of networks that reach you through providers without community support. This layered approach maximizes the fraction of traffic that actually shifts as intended.

When evaluating whether prepending is working, compare the ratio of inbound traffic on each link before and after the change — raw looking glass data shows path preference per vantage point, but actual traffic ratios depend on the distribution of traffic sources across the internet. A path preferred by 80% of looking glass peers may carry 95% of your traffic if those peers represent the dominant traffic-originating networks in your region.

Prepending at IXPs via Route Server Communities

At large Internet Exchange Points, route servers provide community mechanisms that let members request prepending on distribution to other route server participants. Rather than prepending in your own route-map before sending to the IXP, you send the route to the route server with a specific community tag, and the route server inserts the prepend on your behalf when advertising to other members.

For example, at an IXP where the route server AS is 9999, community 9999:101 might mean "prepend once to all peers," 9999:102 twice, and 9999:103 three times. The advantage is that a single session configuration handles all bilateral-equivalent prepending at that exchange — you don't need separate route-maps per peer. The disadvantage is that the prepend applies uniformly to all route server participants at that IXP; granular per-peer control still requires bilateral sessions.

Related articles: BGP AS paths, BGP best-path selection, BGP communities, traffic engineering, IXP route servers, and RPKI.

Explore It Live

Look up prefixes from well-known networks to observe real AS path lengths and spot prepending in the wild:

• 1.1.1.1 — Cloudflare's DNS; look for any repeated ASNs in the path
• AS3356 (Lumen/Level 3) — a major transit AS whose customers frequently prepend toward its peers
• 8.8.8.8 — Google DNS; Google's extensive peering means short paths almost universally, no prepending needed

Use the BGP looking glass to compare AS paths seen by different route collectors for the same prefix — length differences often reveal prepending.