skip to content

A BGP transit provider is onboarding a customer AS that holds one /22; what should the import filter on that eBGP session accept and reject?

level: seniorimportance: must knowfreq 30%

answer

  1. only the customer's own space
  2. length bounds, not exact match
  3. first AS must be the peer
  4. a prefix ceiling as backstop
  5. IRR-generated, RPKI-checked

basics

~20 s

Accept only the customer's verified /22 and its agreed more-specifics down to /24, on AS paths made solely of the customer's ASN; reject everything else, drop RPKI-invalid routes, and cap the session with a maximum-prefix limit.

solid answer

~40 s

RFC 7454 says to accept only customer prefixes and discard all others. So: verify the customer holds the /22, then permit it with a length range of /22 to /24 — exact match would drop its /24s, an open range would accept /25s and longer. Add an AS-path filter: the first ASN must be the customer's, and the path may contain only that ASN (prepends allowed) or downstreams it is authorised to transit. Drop routes RPKI marks Invalid. Set a maximum-prefix limit with some headroom, so a leaked full table tears the session down instead of propagating. Generate the lists from the IRR and refresh them daily, and tag accepted routes with a customer community so export policy can use it.

go deeper

for a junior

Recall the rule of thumb: accept from a customer only the address space it holds, and nothing else.

for a middle

Explain length-bounded prefix entries, why the first ASN must be the customer's, and what a maximum-prefix limit does when crossed.

for a senior

Walk the layered filter end to end, say what each layer catches and misses, and show how it is generated and refreshed from the IRR with RPKI on top.

for a principal

Treat customer filtering as a provider-wide process: who verifies resources at onboarding, how filters are generated and audited, and how exceptions are tracked.

## The scenario A transit provider, AS 64500, connects a new customer, AS 64501, over eBGP. The customer holds one **/22** from its regional registry and plans to announce the /22 and, at times, some of the /24s inside it. The provider will carry those routes to its peers and upstreams. Whatever the provider accepts here it may pass on to the whole Internet, so the **import filter on this one session** is the control that matters. RFC 7454 (BCP 194, "BGP Operations and Security") states the inbound rule for customers plainly: "only customer prefixes SHOULD be accepted, all others SHOULD be discarded." ## Layer 1: the prefix filter - **Verify first.** Check that the customer really holds the /22 — RFC 7454 says the list can be validated "with the appropriate IP address management authorities" — and that the RPKI and the Internet Routing Registry agree. - **Permit with length bounds.** Permit the /22 with prefix lengths /22 to /24 and deny everything else. An exact-match entry would drop the customer's legitimate /24s; an open-ended range would accept /25 and longer, which RFC 7454 notes are generally neither announced nor accepted (IPv4 longer than /24, IPv6 longer than /48, in one regional community's documented practice). - **Implicit rejects.** Everything else is denied, which covers the default route, special-purpose and private space, and the provider's own prefixes (RFC 7454 §6.1.4: a network SHOULD filter its own prefixes inbound). ## Layer 2: the AS-path filter RFC 7454 §9 recommends accepting from customers only AS paths "containing ASNs belonging to (or authorized to transit through) the customer", and rejecting a route whose first AS is not the peer's own. For a single-AS customer that means: 1. The leftmost ASN must be 64501 — the session's own neighbour. 2. The path may consist only of 64501, repeated if the customer prepends. 3. If the customer later sells transit to its own customers, their ASNs are added from the customer's registered AS-SET — not by loosening the pattern to "anything after 64501". The two layers catch different mistakes. The prefix filter stops the customer announcing **someone else's address space**; the AS-path filter stops it passing on **routes it learned elsewhere** — for instance re-announcing its other provider's table, which is how a route leak begins. ## Layer 3: limits and origin checks - **Maximum prefixes.** RFC 7454 §8 recommends a per-peer limit "according to the number of routes they are supposed to advertise, plus some headroom"; if the customer suddenly sends a full table, crossing the limit shuts the session down. It is the backstop for the day a filter is wrong. - **RPKI route origin validation.** Drop routes whose state is Invalid (RFC 6811): a /24 inside the /22 whose ROA authorises a different origin, or a length beyond the ROA's maximum length, is rejected even if the prefix list would allow it. - **Tag on import.** Add the provider's own "learned from customer" community and set the customer `LOCAL_PREF`, so the export policy toward peers and upstreams can act on the tag. ## Building and maintaining the filter Hand-written filters go stale. RFC 7454 §6.1.2.2.1 describes generating them from the **Internet Routing Registry**: start from the customer's ASN or registered AS-SET, expand it recursively to ASNs, and collect the route objects registered for each. Refresh daily — RFC 7454 says daily refresh "SHOULD be considered" because registries are updated at the last moment. IRR objects are not cryptographically tied to the address holder, so the RPKI layer catches what a careless or forged registry entry lets through. | Check | Catches | Misses | |---|---|---| | prefix list with length bounds | prefixes the customer does not hold | a held prefix arriving via a foreign path | | AS-path filter | routes learned from elsewhere | the customer originating a foreign prefix | | max-prefix limit | a full table pushed by mistake | a few wrong routes under the limit | | RPKI origin validation | a wrong origin where a ROA exists | space with no ROA (NotFound) | ## The export side Toward the customer, RFC 7454 §6.2.2.2 has the provider send what the customer asked for: a default route only, or the full table minus special-purpose prefixes, overly specific routes and, unless requested, the default.

  • The customer later starts selling transit to two small networks; what changes in your import filter?
    Both layers grow, but from data, not by loosening patterns. The customer registers an AS-SET containing its ASN and its customers' ASNs, plus route objects or ROAs for their prefixes. The provider expands that AS-SET to build the AS-path filter and the prefix list, keeps the first-AS check on the customer, and raises the maximum-prefix limit to the new expected count plus headroom.
  • Why is an IRR-generated prefix list not sufficient on its own?
    IRR data is published by network operators and, in many registries, is not cryptographically tied to the address holder, so stale or wrongly registered objects end up in the filter. RFC 7454 recommends implementing RPKI origin validation on top of existing filters: a ROA is signed under the address allocation, so it catches a wrong origin the registry would have accepted.
  • What does a maximum-prefix limit protect against that the prefix filter does not?
    It protects against the filter itself being wrong or missing — a bad generation run, a policy left off after a change. If the customer suddenly sends hundreds of thousands of routes, crossing the limit shuts the session down, so the mistake never reaches the provider's routers' memory or its peers.

saying these in an interview costs you the question

  • An exact-match entry for the /22 is enough to accept the customer's /24s.
  • An AS-path filter alone proves the customer holds the prefixes it announces.
  • Accept any prefix length the customer sends, since filtering lengths is the peer's job.
  • IRR route objects are signed by the address holder, so RPKI adds nothing.
  • A maximum-prefix limit is pointless once an exact prefix filter is in place.