Skip to content

PATTERN Cited by 1 source

IRR-prefix-filtering export policy

IRR-prefix-filtering export policy is the BGP export configuration pattern in which a router's outbound policy toward a given neighbor filters routes against only an IRR-derived prefix list — with no additional constraint on how a matching route was learned.

It's the baseline bar that most of the Internet has cleared. It is also the minimum-viable policy below which you are not filtering at all — and, per the Cloudflare Venezuela post, it is the level at which a subtle class of route leaks becomes possible.

Mechanism

  1. Operator publishes an AS-SET in the IRR covering their customer cone.
  2. Upstream / peer uses bgpq4 or similar to expand the AS-SET into a prefix list.
  3. Outbound policy: "advertise any route whose prefix matches this prefix list."

The prefix set is correct — only customer-cone prefixes pass.

Why it's insufficient

It validates which prefixes but not how they were learned. A prefix legitimately in the IRR prefix list can appear in the router's RIB through multiple paths:

  • Direct customer BGP session — desired; the operator intended this.
  • Via another provider / peer — undesired; an indirect copy that should not be re-exported upstream.

If both copies match the IRR prefix list, both satisfy the policy. The route leak becomes possible the moment the direct session flaps and the indirect copy remains in the RIB: the indirect copy gets re-advertised to the other provider, producing a Type 1 hairpin leak.

Strengthening: gate on provenance

The stronger variant is the customer- community-tag export policy pattern — require both prefix-list match and a customer-ingress BGP community tag. Routes learned via providers / peers do not carry the tag and are filtered out, even if their prefixes are in the customer cone.

Seen in

Last updated · 200 distilled / 1,178 read