RPKI, IRR, and why some routes still get filtered in 2026

RPKI is the cryptographic answer to “who is allowed to announce this prefix.” IRR objects are the older, still-used database answer. In 2026 both still matter, and the absence of either still causes routes to be filtered by networks that care about routing hygiene.

What we see in tickets

A customer receives space, announces it, and discovers that some networks do not see the route. The usual causes:

• No covering ROA, or a ROA with the wrong origin ASN or max length.
• Missing or stale route objects in the relevant IRR.
• The upstream has not yet propagated the announcement, or has an export policy that does not match the customer’s expectation.

The fix is almost always to create the correct objects and wait for caches and filters to update. The time that takes depends on the networks involved.

Why both still exist

RPKI is stronger when it is present and correctly configured. Many networks now drop or de-preference invalids. IRR remains relevant because not every network has moved to RPKI-only filtering, and because some operational workflows still rely on the older registries.

A complete setup creates both. LogicWeb’s leasing process includes the documentation needed for both; the tickets that remain are usually about timing or about a specific network’s filter policy.

Practical checklist

1. Create the ROA with the correct origin and a max length that matches how you will announce.
2. Create the route/route6 objects in the IRR that your upstream and peers expect.
3. Verify with looking glasses and validators after the objects have time to propagate.
4. Keep the objects updated when the origin ASN or the announcement policy changes.

Routing hygiene is not glamorous. It is the difference between a prefix that reaches the networks that matter and a prefix that is quietly dropped.

---