Why BGP communities are better than AS-path prepends

BGP's toolkit for steering traffic

The Internet is a collection of independently operated networks, each identified by an Autonomous System Number (ASN) and announcing reachability for its IP prefixes via BGP. When a network announces a prefix, it includes metadata about the path, most notably the AS-path — the sequence of autonomous systems a packet must traverse to reach the destination. Receiving networks use this information to pick a route, and a shorter AS-path is generally preferred because it implies fewer hops.

Operators who want to influence which paths inbound traffic takes toward their network have a limited but powerful set of tools inherited from BGP. Two of these tools — AS-path prepending and BGP communities — are frequently compared, but they operate at very different levels of granularity and control. Understanding the distinction starts with how BGP selects the best path among multiple options.

How BGP picks a path

A BGP announcement carries more than just the prefix and the AS-path. It also includes attributes such as the origin code and MED (Multi-Exit Discriminator). The origin code indicates how the prefix was injected into BGP: IGP for a locally originated route, EGP for the obsolete Exterior Gateway Protocol, or Incomplete when redistributed from another routing protocol like OSPF or IS-IS. MED is an optional hint to directly connected peers about which path to prefer, with lower values winning.

When a network learns multiple routes to the same prefix from different peers, it runs the BGP best path selection algorithm. This algorithm evaluates attributes in a defined order across 15 discrete steps, terminating as soon as a tie is broken. The first four steps do most of the work:

1. Highest local preference
2. Shortest AS-path length
3. Lowest origin code
4. Lowest MED

Local preference is the first and most powerful attribute. It is non-transitive, meaning it is never carried in EBGP messages between different autonomous systems. An operator sets local preference when a route is learned from a peer, and higher values win. Because this attribute is invisible outside the local AS, an operator cannot directly set local preference for their own prefixes inside a neighboring network. That restriction is the core reason inbound traffic engineering is inherently more difficult than outbound engineering.

Prepending: a blunt instrument

Since local preference cannot be influenced remotely, the earliest point in the selection algorithm where a remote operator can change the outcome is AS-path length. AS-path prepending achieves this by artificially inflating the length of the path. An operator announces a prefix with their ASN repeated multiple times, making the path look longer than it actually is. A path that was length 1 might become length 255. Since the algorithm prefers shorter paths, other networks will be less likely to select the prepended route.

The technique works, but only under a specific condition: all other attributes must be equal across the competing routes. In large, well-connected networks where multiple paths exist with differing local preferences, origin codes or MED values, prepending may never become the decisive factor. The longer path has no effect if a higher local preference already breaks the tie earlier in the algorithm. Prepending is therefore a coarse tool that offers control only when the playing field is otherwise level.

The case for communities

BGP communities are transitive, optional path attributes that attach extra information to a route. Unlike local preference, they travel with the route across EBGP sessions, allowing an operator to signal preferences to neighboring networks. A community is a 32-bit value, often written as two 16-bit halves: the first half typically identifies the ASN that defines the community's meaning, and the second half carries the specific action or value.

This mechanism allows an operator to tell a peer, for example, "do not advertise this prefix to any other network" or "prefer the path through this particular peer." Communities are interpreted by the receiving network according to mutually agreed policies, which makes them flexible and granular. The same prefix can carry different communities toward different peers, each peer applying a different local preference or export policy on import.

The advantage over prepending is resolution. A community-based policy can influence a neighbor's routing decision at the local preference step — the very first step in best path selection — rather than at the AS-path length step, which comes second. By signaling a desired local preference value via a community, an operator effectively reaches into the neighbor's decision process far earlier and with more precision than any prepending technique allows.

Communities also scale better operationally. Instead of maintaining separate announcements with different AS-path prepends for each peer relationship, an operator can announce the same route with a set of communities and let each neighbor interpret the relevant community according to an agreed policy. The signaling stays in-band, but the interpretation is outsourced to the receiving network's local configuration.

Prepending still has a place in BGP operations as a simple, widely understood fallback. But for networks that need fine-grained control over how other networks view their prefixes — which paths to prefer, which to filter, and how to react to redundancy — communities provide a far more expressive and precise mechanism.

When Local Preference Outweighs Path Length

BGP is often described as a business policy engine as much as a routing protocol. It does not pick the best path for performance reasons; it picks the path that best matches a network's commercial and contractual obligations. That could mean preferring a port that's cheaper per megabit, a settlement-free interconnection, or a customer over a peer. This is by design: BGP gives each operator a way to encode decisions that pure engineering metrics can't capture.

Many networks, including Cloudflare, assign local preference based on the type of connection the route arrives on. Higher values are preferred. For outbound traffic, Cloudflare's defaults look like this:

• Transit-learned routes: local pref 100 (most expensive)
• Backbone-learned routes: 150
• Internet exchange (IX) routes: 200
• Private network interconnect (PNI) routes: 250

So a route learned over a PNI wins even if an IX or transit neighbor advertises a shorter AS path. Reliability is one reason: a PNI avoids third-party switching hardware that could fail. Port efficiency is the other. The rough economics are captured by:

((cost_of_switch / port_count) + transceiver_cost)

combined with the cross-connect cost (monthly recurring or one-time). Higher utilization of a PNI port lowers the cost per megabit, which is why PNI is attractive. Similar thinking is widespread among transit providers, making BGP as much about cost and policy as about latency or throughput.

Why Prepends Don't Move Transit Traffic

Traditional tier-1 transit networks typically maintain two classes of neighbors: customers and settlement-free peers. The distinction matters because transit providers usually assign customers a higher local preference than peers. When that's the case, no amount of AS-path prepending will offload your inbound traffic to a different transit or peer—the transit network's own local preference will always win.

Prepending can still be effective in narrow circumstances. It works when you have multiple distinct links with the same transit and want to shift traffic between them, or when the source of traffic is multihomed behind several transits that treat each other equally. But even in those cases, the returns diminish quickly: after about three prepends, further additions rarely change anything.

In the scenario above, Cloudflare's AS-path changes have no effect: even though Origin A → Transit B → Transit A → Cloudflare is shorter by AS-path count, traffic still flows through the Transit B ↔ Cloudflare link because Transit B assigns its customer a higher local preference than its peer.

If Origin A is multihomed behind both transits and treats them equally, however, the prepending does matter. Origin A sees both the prepended and non-prepended path and, absent its own egress engineering, picks Origin A → Transit A → Cloudflare.

Communities as a Steering Mechanism

This is the core operational problem: traditional tools don't always let you dictate how traffic enters your network. BGP communities offer a more direct solution. A community is an optional transitive attribute on a route. It can be informative—carrying, say, the location where a prefix was learned—or it can trigger a receiving-side action.

Some transit providers let their customers tune the local preference inside the transit network via documented community values. Cogent, for example, publishes these action communities:

Knowing that Cogent assigns local preference 100 to peers and 130 to customers, prepending is largely futile for traffic arriving through them. The transit side of the route will carry a customer or peer local preference that prepending can't equalize or override.

Say Cloudflare was prepending its ASN twice toward Cogent, producing an AS path of three. If traffic was still coming in too heavily on the Cogent link, adding more prepends wouldn't do much—with a network this well connected, four or five prepends don't achieve what two or three didn't. The right move is to use Cogent's documented community on the advertised route:

term ADV-SITELOCAL {
    from {
        prefix-list SITE-LOCAL;
        route-type internal;
    }
    then {
        community add COGENT_LPREF70;
        accept;
    }
}

That snippet changes the in-transit local preference, rerouting traffic to exactly where it should go:

Practical Guidance

AS-path prepending retains a place in the operator's toolkit, but use it sparingly and monitor its effects. Excessive prepending broadens exposure to route hijacks, which is a serious enough downside to avoid as a default tactic. Community-based ingress traffic engineering is the preferred approach; if a transit provider doesn't offer useful communities, be ready to roll back prepends that don't produce results.

For broader context, avoid an excellent academic study of prepending practices and trends is well worth reading.