The RPKI and IRR checklist nobody hands you with your first prefix

Getting address space feels like the hard part. It is the slow part, which is different. The hard part is everything between “the RIR says this prefix is yours” and “networks around the world accept your announcement.”

Here is the list, roughly in order.

Before you announce anything

Create IRR route objects. Many networks build prefix filters from Internet Routing Registry data. No route object, no acceptance — and the failure is silent from your side. Create route and route6 objects in the registry your RIR provides, with the correct origin ASN.

Sign RPKI ROAs. A Route Origin Authorisation cryptographically binds your prefix to your ASN with a maximum prefix length. Prefixes with no ROA are treated as not-found — increasingly second class. Prefixes with a wrong ROA are invalid and get dropped outright by validating networks, which is worse than having none.

Get maxLength right. This is the most common ROA mistake. If you set maxLength to 24 on a /24 you only ever announce as a /24, you are fine. If you set it loosely to allow longer prefixes you do not announce, you have authorised a hijacker to announce a more-specific inside your space and have it validate. Set maxLength to exactly what you announce.

Register in PeeringDB. Not a protocol requirement, but it is where peers look to find out who you are, what you announce and where you are present. An empty PeeringDB record makes peering conversations harder than they need to be.

Session configuration

Validate inbound. Reject RPKI-invalid routes from transit. This protects you from accepting a hijack, which matters more than most people assume.

roa4 table r4;

protocol rpki validator {
    roa4 { table r4; };
    remote "rtr.rpki.example" port 8282;
    retry keep 90;
}

filter transit_in {
    if roa_check(r4, net, bgp_path.last) = ROA_INVALID then reject;
    if net.len > 24 then reject;            # no more-specifics than you want
    if net ~ [ 0.0.0.0/0 ] then reject;     # default route, if you do not want it
    accept;
}

Filter outbound explicitly. Announce only what you originate. Not “everything from this table” — an enumerated list, or an origin-based filter you can read in one glance.

Set a max-prefix limit. If a peer suddenly sends you ten times their usual prefix count, something is wrong on their side. Tear the session down rather than installing it.

Decide what happens when the validator is unreachable. If your RPKI cache dies and your policy defaults to rejecting everything, you have built an outage trigger. Most designs should treat validator failure as “fall back to not-found behaviour”, not “reject”.

Before you call it done

Check from outside. Your own router’s view tells you nothing about acceptance. Use public looking glasses, RIPE RIS and RouteViews to confirm the prefix is visible from multiple networks and that the AS path is what you intended.

Verify ROA state propagated. ROA publication is not instant. Confirm validators around the internet see your prefix as valid, not not-found, before you depend on it.

Test withdrawal. Pull the announcement from one site, under supervision, during business hours, with a rollback ready. Measure where traffic goes and how long it takes. A failover path that has never been exercised is a hypothesis.

Check your monitoring noticed. This is the step everyone skips. If you withdraw a prefix and no alert fires, your monitoring has a hole exactly where you least want one.

The alerts you want

• BGP session state per peer, with a short for duration — flapping is a signal, not noise
• Received and accepted prefix count per peer, alerting on sudden deltas in either direction
• ROA validity state for your own prefixes, checked from an external validator
• Prefix visibility from at least two external vantage points

None of this is exotic, and all of it is the difference between a routing problem you find in two minutes and one you find from a customer email.

If you are going through this for the first time, we have done it for ourselves and we are happy to review a design before it goes live.