Skip to content

CONCEPT Cited by 1 source

IRR prefix list

An IRR prefix list is a list of BGP prefixes generated by expanding an AS-SET / as-macro object published in an Internet Routing Registry (IRR) — most commonly RIPE IRR, RADb, APNIC, ARIN, LACNIC, and AFRINIC. The expanded list is the set of prefixes an AS claims it is authorized to advertise, including everything in its customer cone.

See Cloudflare's Monitoring AS-SETs and why they matter for the canonical framing.

Generation workflow

  1. Operator publishes an aut-num (AS object) and an AS-SET enumerating the AS's customer cone: as-set: AS8048:AS-CUSTOMERS, members: AS21980, AS....
  2. Peers / upstreams run bgpq4 or similar to expand the AS-SET recursively into a prefix list from registered route / route6 objects.
  3. The expanded prefix list is loaded into the router's BGP import / export filter.

What it does well

  • Gives peers / upstreams a declarative source of truth for which prefixes may legitimately appear from a given AS, without having to accept them blindly.
  • Updated and regenerated on a regular cadence; IRR changes propagate on the order of minutes to hours.

What it does NOT do — the hygiene gap

An IRR prefix list verifies the set of prefixes. It does not verify how a given prefix was learned by the advertising router. If AS8048's router has learned AS21980's prefixes directly from AS21980 (desired) and also indirectly via AS6762 (undesired but possible during session flaps or due to iBGP propagation), both copies will match the IRR-derived prefix list.

The corrective is to combine IRR prefix filtering with BGP community tagging at the customer-ingress router, so that only the customer-learned copy carries the tag and passes the egress filter — the customer- community-tag export policy pattern. IRR-only filtering is the weaker variant and is Cloudflare's proposed explanation for what failed in AS8048's case.

Seen in

Last updated · 200 distilled / 1,178 read