In BGP routing policy, what do a prefix list, an AS-path filter and a route map each match, and how do they combine?
answer
- three parts of a route
- prefix plus length range
- regex over AS_PATH
- ordered clauses, match then set
basics
~20 sA BGP prefix list matches the prefix and its length range, an AS-path filter matches the AS_PATH with a regular expression, and a route map is an ordered list of match-and-set clauses that combines them into a session's policy.
solid answer
~40 sThey test different parts of a route. A **prefix list** matches the destination prefix, optionally with a range of allowed lengths, so it can say "this /22 and its /23s and /24s, nothing longer". An **AS-path filter** is a regular expression over `AS_PATH`, where the leftmost ASN is the neighbour and the rightmost is the origin, so it can say "only paths made of my customer's ASN". A **route map** is an ordered list of clauses: each matches conditions such as a prefix list, an AS-path filter, a community or the RPKI state, then permits or denies and sets attributes like `LOCAL_PREF`. Usually the first matching clause wins and an unmatched route is denied. You need both filters, because each misses what the other catches.
code
pseudocode · 13 linesroute_map_eval(route, clauses):
for clause in sorted(clauses, by=sequence):
if all(cond.matches(route) for cond in clause.matches):
if clause.action == DENY:
return REJECT
for action in clause.sets:
route = action.apply(route)
if not clause.continue_to_next:
return ACCEPT(route)
return REJECT
# clause 20 for customer AS 64501, prefix 203.0.113.0/24 lengths 24..24
# as_path_filter: path is 64501 repeated one or more timesgo deeper
Recall the three tools and the one thing each matches: prefix and length, the AS path, or a set of conditions with actions.
Explain length ranges, which end of the AS_PATH is the origin, and the ordered first-match evaluation of a route map with its default deny.
Show why prefix and path checks are needed together and how a route map orders RPKI, prefix and path conditions on a real customer session.
Talk about keeping these objects generated from authoritative data rather than hand-edited, so hundreds of sessions stay consistent and reviewable.
## Policy is local, the tools are common RFC 4271 leaves BGP policy "a local matter", so no RFC defines a prefix list or a route map. Almost every implementation, though, offers the same three building blocks, and interviewers expect them by these generic names. Each one matches a **different part of a route**. | Tool | Matches | Typical use | |---|---|---| | **Prefix list** | the NLRI: prefix and prefix length | accept only a customer's own address blocks | | **AS-path filter** | the `AS_PATH` attribute, as a sequence of ASNs | accept only paths originated by a customer and its downstreams | | **Route map** | any combination of conditions, then sets attributes | the policy applied to a session, built from the other two | ## Prefix lists: prefix plus a length range A prefix-list entry names a prefix and, optionally, a **range of prefix lengths** that may match inside it: - An entry for `203.0.113.0/24` with no range matches **only** a route for exactly `203.0.113.0/24`, not `203.0.113.128/25`. - An entry for a `/22` with a length range of `/22` to `/24` matches the `/22` itself and any `/23` or `/24` inside it, and nothing longer. - Entries are evaluated in order and the first match decides permit or deny; in most implementations a route matching no entry is denied. The length bound is the important part: "permit my customer's /22" written without a range rejects the `/24`s the customer may legitimately announce, while "any length" accepts `/25`s and longer that RFC 7454 notes are generally neither announced nor accepted on the Internet (IPv4 longer than `/24`, IPv6 longer than `/48`, per one regional community's documented practice). ## AS-path filters: regular expressions over the path An AS-path filter treats `AS_PATH` as a string of AS numbers and matches it with a **regular expression**. RFC 4271 has each speaker prepend its own AS in the leftmost position, so: - the **leftmost** ASN is the neighbour that sent the route; - the **rightmost** ASN is the origin. A filter anchored at both ends to the customer's ASN, allowing it to repeat, accepts routes the customer originated (including prepended ones) and rejects anything the customer is passing on from elsewhere. A filter anchored only at the right matches every route *originated* by an AS, through any transit path. Regular-expression syntax and the token for an AS boundary differ between implementations, which is why the pattern below is pseudocode. An AS-path filter says nothing about **which prefixes** are carried, and a prefix list says nothing about **who originated** them. A customer that originates someone else's prefix with its own ASN passes an AS-path-only filter; a correct prefix arriving through an unexpected transit path passes a prefix-only filter. Production policies use both. ## Route maps: ordered match and set A **route map** is an ordered list of clauses. Each clause has: 1. a **sequence number** that fixes its order; 2. **match conditions** — a prefix list, an AS-path filter, a community, the RPKI validation state (RFC 6811 §3 requires implementations to let policy match and set it), a next hop; 3. an action, **permit or deny**; 4. **set actions** applied to a permitted route — `LOCAL_PREF`, `MULTI_EXIT_DISC`, communities, AS-path prepending, next hop. The usual evaluation model, an implementation convention rather than an RFC rule, is first-match: the route is tested clause by clause, the first clause whose conditions all match decides, its set actions run, and later clauses are skipped unless the clause explicitly says to continue. A route that matches no clause is denied in most implementations. ## Mistakes interviewers listen for - Writing a customer's block without a length range, then wondering why its `/24`s are rejected. - Anchoring an AS-path filter only on the left, which accepts everything the neighbour sends, including routes it learned from its other providers. - Forgetting the final implicit deny, so a route map with only permit clauses silently drops every route it did not anticipate. - Assuming the policy applies retroactively: routes accepted under the old import policy must be re-evaluated. ## How they combine on one session An import route map for a customer might read: clause 10 denies RPKI-invalid routes; clause 20 permits routes matching both the customer's prefix list and the customer's AS-path filter, setting a high `LOCAL_PREF` and a "learned from customer" community; anything else falls through and is denied. The prefix list and AS-path filter are reusable objects; the route map is where they meet the session.
- Why is a prefix list alone not enough on a customer session?A prefix list checks only the destination. If the customer starts passing on routes from its other provider, a correct prefix of the customer's arriving with a foreign path still matches, and the prefix list cannot tell an origination from a transit. An AS-path filter limits the path to the customer and its authorised downstreams, so the two together check both what and who.
- In an AS_PATH, which end is the origin AS, and why does that matter for a filter?RFC 4271 has each speaker prepend its own AS in the leftmost position, so the leftmost ASN is the neighbour that sent the route and the rightmost is the origin. A pattern anchored on the right selects by origin through any transit; anchored on the left it selects by the neighbour; anchored on both it accepts only a specific complete path.
saying these in an interview costs you the question
- A prefix-list entry for a /24 also matches every more-specific inside it.
- An AS-path filter alone stops a customer from announcing someone else's prefix.
- The leftmost AS in the AS_PATH is the origin of the route.
- Every matching route-map clause runs and the last one wins.
- Route maps and prefix lists are defined by RFC 4271 itself.