IRR hygiene and pitfalls

Filters built from IRR data are only as good as the data. Two lists: what to do for your own objects, and what to watch for in other people's.

Your own objects

• A route or route6 object for every prefix you announce, in the authoritative IRR of the RIR that manages it. Include space you originate for customers. Without them, your neighbours' filters will drop your announcements.
• One accurate as-set, hierarchically named (AS64500:AS-CUSTOMERS), containing exactly your customer cone. Remove customers when they leave.
• Publish it: set IRR as-set/route-set in PeeringDB and keep your aut-num export consistent.
• Protect your maintainer: use SSO with two-factor or PGP keys, never shared passwords, and review who has access.
• Delete stale objects, including old registrations in non-authoritative IRRs that you no longer control.
• Check regularly with tools such as IRR Explorer (NLnet Labs) or bgp.tools, which compare what you announce with what you've registered.

Other people's data

Pitfall	What happens	Defence
Proxy or stale objects in non-auth IRRs	Someone registers a route object for space they don't hold, and filters accept their hijack	Prefer authoritative sources (-S); combine with RPKI
Set bloat	A customer's set expands to a large part of the internet	Alert on large changes; limit expansion depth; max-prefix
Flat-name collisions	AS-FOO in RADb isn't the AS-FOO in RIPE	Use hierarchical names; restrict sources
Empty expansion	Deny-all filter, so the customer goes dark after a typo	Treat empty or tiny results as an error, not a config
Unsigned data	Anyone with maintainer access can change a set	RPKI adds cryptographic origin checks; see the next lesson

The IRR tells you what a network intends to announce. It doesn't prove the network is allowed to announce it. That is the gap RPKI fills.