A BGP network announces its /22 over two upstream links; how do AS-path prepending and more-specific announcements compare for steering inbound traffic?
answer
- a hint versus an override
- LOCAL_PREF beats path length
- longest prefix wins first
- keep the aggregate on both links
basics
~20 sPrepending lengthens the AS_PATH on the less-wanted link and only nudges remote choices, since their LOCAL_PREF comes first; a more-specific on the wanted link wins by longest-prefix match but grows the global table and needs the aggregate kept as fallback.
solid answer
~40 sPrepending repeats your ASN in `AS_PATH` on one link (RFC 4271 allows it by local configuration). It only matters where a remote AS gets as far as comparing path length, and many prefer routes by `LOCAL_PREF` first, so results are partial and unpredictable; past a few copies more rarely helps, and very long paths may be filtered. Announcing a /24 from the /22 only on the wanted link is deterministic, because routers use the longest matching prefix before any BGP attribute. The cost: another entry in every full table, nothing longer than /24 is generally accepted, each more-specific needs a ROA, and the /22 must stay announced on both links so traffic falls back when the more-specific is withdrawn. Tagging the /24 `NO_EXPORT` keeps it inside one upstream.
go deeper
Recall that a network can only influence, not dictate, how others send traffic to it, and that prepending and more-specifics are the two classic levers.
Explain why longest-prefix match makes a more-specific deterministic and why a remote LOCAL_PREF can make prepending useless.
Design the announcement set: aggregate on both links, more-specifics with matching minimal ROAs, NO_EXPORT where it suffices, and the failure path for each link.
Argue the cost of deaggregation to the Internet's shared table against your own traffic goals, and when an upstream's action communities are the better lever.
## The setup A network, AS 64501, holds a /22 and announces it to two upstreams over links A and B. Its **outbound** traffic it controls itself. **Inbound** traffic is chosen by everyone else's routers, so all it can do is shape what it announces. Two classic policy tools do that, with very different strength. ## AS-path prepending: asking politely RFC 4271 §5.1.2 allows a speaker to "include/prepend more than one instance of its own AS number" in `AS_PATH`, under local configuration. AS 64501 exports the /22 on link A with its ASN repeated, say three times, and once on link B. Remote networks comparing the two paths see the B path as shorter. Why it often moves less traffic than expected: 1. **Path length is not the first thing compared.** A remote AS's own preference — typically `LOCAL_PREF` set by its policy, for example "prefer routes learned from customers" — is applied before path length, so if the upstream on link A is a customer of that remote AS, the remote AS keeps using A however long the path. The full decision order is its own subject; here it is enough that `LOCAL_PREF` outranks `AS_PATH` length. 2. **Diminishing returns.** Once the prepended path is longer than the alternatives most networks see, more copies change nothing. 3. **Collateral risk.** RFC 7454 §9 tells providers to "discourage excessive prepending", and some networks filter very long paths; a long path is also easier to imitate with a shorter one. Prepending changes probabilities, not outcomes. It is a request to the rest of the Internet. ## More-specific announcements: overriding everyone Instead, AS 64501 announces the /22 on both links and also announces one /24 from it only on link B. Routers forward on the **longest matching prefix**, and BGP attributes only ever compare routes for the *same* prefix, so traffic for that /24 arrives on B across the whole Internet. It is deterministic, which is its strength and its cost: - **Table growth.** Every more-specific is another entry in every full-table router on the Internet; the aggregate exists precisely to avoid that. - **Acceptance limits.** RFC 7454 §6.1.3 notes IPv4 prefixes longer than /24 (IPv6 longer than /48) are generally neither announced nor accepted, so you cannot split below that. - **ROAs must cover them.** With RPKI, each announced more-specific needs a ROA authorising its length; RFC 9319 recommends **minimal ROAs** listing the prefixes you actually announce rather than a loose maximum length. - **Failure behaviour.** If link B fails and the /24 is withdrawn, its traffic falls back to the /22 via A — but only because the aggregate is announced on A as well. Announce the /22 only on A and the /24 only on B, and the networks behind each link split cleanly until a failure leaves part of the space unreachable. ## The middle path: more-specifics with `NO_EXPORT` Tagging the /24 with the well-known community `NO_EXPORT` (RFC 1997) lets the upstream on link B use it inside its own network but stops it propagating further. The global table does not grow, and traffic that already enters upstream B is pulled onto link B; traffic arriving through upstream A still uses link A. It is a narrow, cheap lever. ## Originating the aggregate correctly - An aggregating router must discard packets that match the aggregate but no more-specific — RFC 4632's rule, restated in RFC 9774 §6.3 — usually with a **discard route** for the aggregate, which prevents forwarding loops. - RFC 9774 deprecates `AS_SET`: speakers MUST NOT advertise UPDATEs containing it, and aggregates use "consistent brief aggregation" with `AGGREGATOR` and `ATOMIC_AGGREGATE` but a plain sequence path. - RFC 9774 §6.2: an aggregate SHOULD NOT be announced back to the ASes that contributed to it. ## Summary | Lever | Strength | Main cost | |---|---|---| | prepend on the less-wanted link | a hint other ASes may override | unpredictable; long paths filtered | | more-specific on the wanted link | deterministic for that prefix | table growth, ROAs, /24 floor | | more-specific with `NO_EXPORT` | applies inside one upstream | only traffic entering that upstream | | an upstream's action communities | applies inside that upstream | depends on what it offers |
- What should the ROAs look like if you announce the /22 everywhere and one /24 only on link B?RFC 9319 recommends minimal ROAs: authorise exactly what you announce — the /22 and that /24 with your origin AS — rather than the /22 with a maximum length of 24. A loose maximum length authorises every /23 and /24 you do not announce, which an attacker could announce with your ASN as the forged origin and still be Valid.
- Why must the aggregate stay announced on both links when you steer with a more-specific?When link B fails, the /24 is withdrawn and traffic for it needs a covering route. If the /22 is still announced via A, routers fall back to it and the /24's traffic arrives on A. Had the /22 been announced only on B alongside the /24, losing B would leave the whole /22 with no route.
saying these in an interview costs you the question
- Prepending ten times guarantees no remote network will use that link.
- A more-specific is only used if its AS_PATH is shorter than the aggregate's.
- Announce the more-specific only, so there is no need to keep the aggregate.
- Any prefix length can be announced for traffic engineering, even a /28.
- Prepending is stripped by the first AS that receives the route.