RPKI Invalid Routes: A Safe Troubleshooting Workflow

An RPKI-invalid route is a routing authorization mismatch, not automatically proof of an attack. Troubleshooting starts by comparing the actual BGP announcement with the relevant route origin authorization, or ROA. Check the prefix, origin autonomous system number, and permitted prefix length before changing routing policy.

The IETF's RFC 6811 defines route origin validation states. Keep the scope clear: origin validation concerns whether an origin is authorized for a prefix. It does not validate every hop of the AS path or guarantee that a reachable application is safe.

Understand the three outcomes

In simplified terms, a route is valid when a covering authorization permits its origin and prefix length. It is invalid when relevant authorization exists but does not permit that announcement. It is not found when there is no applicable authorization available to the validator.

Do not collapse invalid and not found into a single operational label. They call for different investigation. Also remember that a local validator and a remote network may not have exactly the same data at the same instant. Record the observer, timestamp, and validation data source with your result.

A monitoring system that says only “routing broken” leaves too much ambiguity. Capture the announced prefix, prefix length, origin ASN, and reason for the validation result where your tooling supports it. Keep those details separate from unrelated packet loss or DNS symptoms.

Compare the announcement with the ROA

Imagine an organization authorizes 203.0.113.0/24 for an illustrative origin ASN. The documentation prefix here is not a real deployment recommendation. If it later announces a more specific /25 without an authorization allowing that length, the origin number alone is not enough to make the announcement valid.

Likewise, if a new provider originates the existing prefix under a different ASN, the old authorization may no longer match. A migration can therefore create an invalid route even when the organization legitimately owns the address space and intended the change.

Retrieve the actual announcement from an appropriate route observation tool and compare it with the address registry's authorization records. Avoid using an old diagram or ticket as the source of truth. The ticket describes intent; the announcement and validation records describe current state.

Check prefix length deliberately

The maximum permitted length should follow the intended announcement plan. Making it extremely permissive simply to clear an alarm can authorize more specific announcements that the organization never needed. A troubleshooting fix should restore intended authorization, not expand it blindly.

Write down the aggregate and the specific prefixes that will be originated during normal service and failover. Check each planned origin. If a DDoS mitigation or backup provider may originate the prefix, include that authorized scenario in the review before an emergency forces a rushed change.

Do not change every ROA in a large address block at once. Resolve the exact affected prefix and planned origins, review the proposed record, and use the registry's supported change process. Some organizations need a second reviewer for routing authorization changes; keep that control in place.

Investigate freshness and distribution

After a correct authorization change, confirm that the local validator has refreshed its data and that routers are receiving the intended validation information. Check the validator's health rather than assuming the newest registry record has already reached every consumer.

Compare observations from more than one network when available. A single remote observer can lag or have a separate policy issue. Preserve both the old and new observations with timestamps so you can explain whether the incident was a record mismatch, stale validation data, or router policy.

Do not promise a universal propagation interval. Operational timing depends on publication, refresh, caching, and consumer behavior. State what you observed in your environment. If a network remains unreachable after the route is valid, continue investigating routing and application symptoms separately.

Avoid disabling protection as the first fix

Removing origin validation can make the immediate symptom disappear while hiding the underlying mismatch. Prefer correcting the authorization or intended announcement. If an emergency exception is necessary under your organization's policy, scope it narrowly, give it an expiry, and record who approved it.

Maintain an incident note that distinguishes the confirmed facts from assumptions. “This provider sees our /25 as invalid because the covering authorization allows only /24” is actionable. “RPKI caused the internet outage” is too broad and may be false.

Our incident clock synchronization guide helps align observations from different systems. For a redacted before-and-after authorization manifest, JSON Diff can expose an origin or prefix-length change. It is not an RPKI validator and cannot determine route validity itself.

Build prevention into migrations

Add authorization checks to provider changes, prefix deaggregation, mitigation onboarding, and ASN transitions. Test the planned announcements before the cutover where possible. Include a rollback plan that restores both the routing announcement and the matching authorization rather than only one of them.

Give the register an owner and a review date. Address ownership, routing operations, and provider contracts may sit with different teams. A shared change checklist closes the gap between those responsibilities and reduces avoidable invalid announcements.

Conclusion

Safe RPKI troubleshooting compares actual announcements with intended authorizations, checks validator freshness, and preserves protection while resolving the mismatch. Treat invalid as a precise diagnostic state. It is neither a complete security verdict nor a reason to disable validation across the network.