RPKI invalid: why your prefix is being dropped, and how to fix it
You announce your prefix, and it works, mostly. Some networks reach you fine and others cannot reach you at all, with no pattern you can see from your own routers. Before you chase a routing bug, check one thing: RPKI. Partial unreachability that follows no obvious topology is very often RPKI doing exactly what it is meant to, dropping an announcement that contradicts a signed record. Here is why that happens, and how to clear it.
What RPKI actually checks
A BGP announcement carries a prefix and the origin AS at the end of its path, and by itself it makes no claim about whether that origin is allowed to announce that prefix. RPKI adds the missing claim. The holder of the address space publishes a Route Origin Authorization, a ROA, which is a cryptographically signed statement with three parts: the prefix, the origin AS permitted to announce it, and a maximum prefix length the authorisation covers.
A router that does origin validation checks each announcement against the published ROAs. If a ROA covers the prefix, the announcement must match it on both the origin AS and the length. If it does, the route is valid. If a ROA covers the prefix but the announcement contradicts it, the route is invalid, and a growing number of networks, including several of the largest transit providers, simply drop invalid routes. That drop is the whole story behind your missing reachability.
Valid, invalid, not-found
There are three outcomes, and the difference between two of them is where most confusion lives.
| State | Meaning | What networks do |
|---|---|---|
| Valid | A ROA covers the prefix and the announcement matches it. | Accepted, often preferred. |
| Invalid | A ROA covers the prefix and the announcement contradicts it, on origin or on length. | Dropped by filtering networks. |
| Not-found | No ROA covers the prefix at all. | Accepted. It is unsigned, not wrong. |
Not-found is not a mild form of invalid. It simply means nobody has signed a statement about the prefix, which is still common in older IPv4 space and is accepted everywhere. Invalid is the active problem, because it means a signed record exists and your announcement is on the wrong side of it.
Why it looks like partial reachability
An invalid route is not rejected by the whole internet, only by the networks that have turned on filtering. So the prefix reaches everyone whose path does not cross a filtering network, and vanishes for everyone whose path does. From your side that reads as maddening inconsistency: it works from your phone, fails from a customer's office, works from one monitoring probe and not another. That specific shape, reachable from some networks and not others with no local cause, is the signature RPKI invalidity leaves, and it is worth checking before you touch your own configuration.
The two causes you will actually hit
In practice, invalid announcements come from two mistakes, and one of them is especially common on space you did not always hold.
An inherited ROA. You bought or leased the block, you announce it from your AS, and a ROA the previous holder published still authorises their AS. Your announcement now contradicts a signed record, so it is invalid, through no fault of your configuration. This is one of the quiet ways a transferred range arrives broken, and it is the reason RPKI belongs on every pre-acquisition checklist.
A maxLength mismatch. The ROA authorises the prefix at one length and you announce something more specific. A ROA for a /22 with a maximum length of 22 does not cover the /24 you carved out of it, so the /24 is invalid even though it is your own space announced from your own AS. Getting maxLength right, and no looser than you need, is both a correctness and a security matter: an over-broad maxLength lets someone hijack a more-specific inside your block and still validate.
Diagnosing it
Confirm the state before you change anything. Any RPKI validator will tell you whether a prefix and origin pair is valid, invalid or not-found, and you can read the same thing on a routing report that shows the RPKI status alongside the ROAs that cover the prefix, each with its authorised origin, its covered prefix and its maximum length. Look the prefix up, read the ROAs, and the mismatch is usually obvious at a glance: the ROA names an origin that is not you, or a length that does not reach yours. If you inherited the block, this is also where you see whose AS the leftover ROA still points at, which is the fact you will need when you ask for it to be fixed.
Fixing it
The fix depends on which cause you have, and one of them is not entirely in your hands.
- Publish or correct your own ROA. For space you control, create a ROA at your RIR (hosted RPKI in the RIR portal is the simplest path) authorising your AS for the prefix, with a maxLength that matches what you announce and no looser. Once it propagates, your route validates.
- Get an inherited ROA revoked. You cannot revoke somebody else's ROA. Only the previous holder or the RIR can, and until one of them does, your announcement stays invalid at every filtering network. On a transfer this should be part of the handover; if it was not, that is a conversation to have with the seller or the RIR, and a dated record of the leftover ROA makes it a short one.
- Fix the maxLength. If the ROA is yours but too tight, reissue it with a maximum length that covers your more-specifics, or stop announcing the more-specific. Keep it as tight as your real announcements allow.
Then wait, and verify. RPKI is not instant: validators refresh their data and networks rebuild their filters on their own schedules, so a corrected ROA takes minutes to hours to clear everywhere rather than seconds. Re-check the validation state until it reads valid, and confirm reachability from a network you know was filtering you before. Getting this right is not only about reachability; a validly signed announcement is also the strongest routine evidence that the space is yours to announce, which is worth having on record long after the reachability problem is gone.
Look up any prefix on the front page to see its RPKI status and the ROAs that cover it, each with its authorised origin and maximum length. The report shows the source and date behind each fact, and says plainly when nobody has checked something.