BGP, IRR and RPKI Mismatch: What Happens When Routing Records Disagree?

When customers can reach your API from one network but not another, the route is often telling you where to look. A disagreement between BGP, IRR and RPKI can turn a routine ASN change, upstream migration or IPv4 deployment into partial reachability.

This guide helps network operators move from a confusing routing symptom to a clear production decision: identify the intended route, align the records that support it, and keep the IPv4 capacity behind the route ready for the business that depends on it.

BGP, IRR and RPKI Mismatch: Quick Answer

A BGP, IRR and RPKI mismatch means that live BGP routing does not agree with the origin information published in an IRR route object, an RPKI Route Origin Authorization (ROA), or both.

For example, BGP may show AS64501 while the IRR object and ROA still describe AS64500. The route may be a legitimate new deployment, an incomplete migration or a configuration problem. The important result for your business is the same: different networks may make different decisions about reachability.

Find the route customers need, align every layer that supports it, and verify the result from more than one network.

Use this page to get the diagnosis moving quickly. For the full protocol background, see what BGP does, how an IRR route object works, what a ROA authorizes and how RPKI supports routing security.

What BGP, IRR and RPKI Each Tell You

These systems work together, but each one answers a different operational question.

BGP, IRR and RPKI answer different routing questions

Layer	What it shows	Question for the operator
BGP	Live reachability and path information	Which ASN is announcing this prefix now?
IRR	Published routing policy	Which ASN is expected to originate this prefix?
RPKI / ROA	Cryptographically verifiable origin authorization	Which ASN is authorized, and up to what prefix length?

BGP shows what the Internet is seeing. IRR helps networks build routing filters. RPKI lets a network validate whether an origin ASN is authorized for a prefix and its permitted maximum length. A healthy deployment makes the three layers tell the same story.

BGP: what is actually being announced?

Border Gateway Protocol is the inter-domain routing protocol used to exchange reachability between Autonomous Systems. When you inspect a prefix, look at its origin ASN, AS path, prefix length, upstream visibility and more-specific announcements. The core protocol description is available in RFC 4271.

IRR: what does the routing policy say?

An Internet Routing Registry route object normally connects a prefix with an origin ASN:

route: 203.0.113.0/24
origin: AS64500

Networks can use this published policy to generate filters. If the object still names an old ASN after a migration, a valid new announcement can be filtered before it reaches customers. Learn more in What Is an IRR Route Object?.

RPKI and ROA: what is authorized?

RPKI supplies a verifiable authorization chain. A ROA states which origin ASN may announce a prefix and the maximum prefix length it may announce. RFC 9582 describes the current ROA profile. A route can be visible in BGP and still be rejected by networks that apply Route Origin Validation when its origin or length does not match the ROA.

What a Mismatch Looks Like in Production

Suppose the intended route is:

203.0.113.0/24 → AS64500

Aligned routing state

Layer	Published or observed state	Customer impact
BGP	AS64500	Reachability follows the intended announcement
IRR	AS64500	Policy filters recognize the route
RPKI	AS64500 authorized	ROV can validate the origin

After an ASN migration, the same prefix can show a different production state:

What a route mismatch looks like after a migration

Layer	Observed state	Customer impact
BGP	AS64501	Some networks may see a different Origin.
IRR	AS64500	Filters built from the record may still expect the previous Origin.
RPKI / ROA	AS64500 authorized	Route Origin Validation may reject the new Origin.
Result	The layers disagree	Customers may reach the service from one network and fail from another.

After an ASN migration, the observed state may become:

BGP: AS64501
IRR: AS64500
ROA: AS64500

Some networks may continue to accept the route, while others filter it through IRR-derived policy or RPKI validation. That is how a team can see “the route is up” while customers in another network still cannot connect.

The Routing Mismatch Scenarios Operators See Most

Common mismatch patterns and the next check

Pattern	What changed	First check
BGP differs from IRR	The live origin changed or the route object is stale	Confirm the intended origin and the filter source
BGP differs from RPKI	The announcement or ROA no longer matches	Check origin and MaxLength in the ROA
BGP and RPKI agree, IRR differs	Policy data was not updated	Check whether an IRR-generated filter is rejecting the route
ASN matches, prefix length differs	A more-specific route exceeds the permitted length	Compare the announcement with ROA MaxLength

Why This Matters to Customer APIs and Servers

Routing inconsistency does not always create a total outage. It can create a more expensive problem: a route works for one carrier, region or cloud, then fails for another. That means customer APIs time out, monitoring becomes noisy, support tickets multiply and a rollout that looked ready is not ready everywhere.

The fastest commercial answer is a route that customers can reach consistently. That requires more than an address block on a spreadsheet. It requires the address, authorization, routing policy and live announcement to move together when your network changes.

What Causes Records to Fall Out of Sync?

• an origin ASN changes during an infrastructure migration;
• a transit provider or upstream path changes;
• a leased or transferred IPv4 block moves into a new production network;
• an IRR object is updated but the ROA is not, or the reverse;
• a ROA MaxLength does not cover the prefix actually announced;
• an old route object remains active after an address or network change;
• automation updates one routing system and skips another.

These are normal network changes. The business risk appears when the change reaches production before every routing layer describes the same intended state.

How to Troubleshoot a BGP, IRR and RPKI Mismatch

1. Define the route customers must reach

Write down the prefix, intended origin ASN, allowed prefix length and the network that should announce it. Start with the customer outcome: which API, server or service must become reachable?

2. Check live BGP

Compare origin ASN, AS path, prefix length, more-specifics and visibility from multiple collectors or networks. A single looking glass can show only one part of the route.

3. Check the IRR route object

Confirm that the route object names the intended origin and belongs to the routing policy your upstreams use. If a filter is generated from IRR data, identify when it will rebuild and apply the change.

4. Check the ROA and RPKI state

Verify the origin ASN and MaxLength. Valid means the announcement matches a covering authorization. Invalid means a relevant authorization exists but the origin or length does not match. NotFound means no validated ROA covers the route.

5. Review the latest network change

Look at ASN moves, upstream changes, address transfers, lease activation, automation runs and planned maintenance. The newest change usually explains which layer is now behind the production route.

6. Correct the layer that no longer describes the deployment

Coordinate the order with the network and upstream teams so the route keeps a usable path while records update. Avoid changing a working layer blindly; the target is one consistent production story.

7. Verify from more than one network

Check BGP visibility, IRR-derived filtering and RPKI validation again after the update. Confirm that the customer API, server or service works from the networks that matter to your business.

Routing Readiness Before an IPv4 Lease or Migration

Before putting a new prefix into production, confirm five layers together:

Five layers that keep an IPv4 deployment ready

Layer	Customer-facing question
Resource	Is the address capacity ready for the workload?
Authorization	Can the intended network announce it?
Policy	Will upstream filters recognize the route?
Security	Will RPKI validation accept the origin and prefix length?
Operation	Can customers reach the service from the networks that matter?

For a deeper deployment path, see how to lease an IPv4 address block. For the operational context behind changes in registry records, see Heng Lu's note on unexpected registry changes.

Keep Production IPv4 Moving with LARUS

LARUS connects first-party IPv4 supply with the routing work that makes capacity useful in production. During a new deployment, ASN change or upstream migration, customers need more than an available prefix: they need the address, route policy, ROA, reverse DNS and continuity path to move with the service.

That is the role of LARUS IPv4 Leasing & Continuity. It gives network operators a direct path to capacity and a team focused on keeping the resulting deployment usable as the network grows. Build with Unlimited IPv4 and move from a routing diagnosis to a continuity plan.

Frequently Asked Questions

What is a BGP, IRR and RPKI mismatch?

It is a disagreement between the live BGP origin and the origin information published in an IRR object, an RPKI ROA or both.

Does a mismatch mean the BGP route is wrong?

No. The BGP announcement may be the correct result of a recent network change while a policy or authorization record is stale. The intended production state tells you which layer needs to move.

What happens when BGP and RPKI do not match?

A route can be classified as RPKI Invalid and rejected by networks using Route Origin Validation. The result can be partial reachability even when some networks still see the announcement.

What happens when BGP and IRR do not match?

Networks using IRR-derived filters may reject or fail to recognize the announcement. The impact depends on the policy data and filter generation used by each upstream.

Can a route be RPKI Valid but missing from IRR?

Yes. IRR and RPKI are separate systems. A valid ROA does not create an IRR route object, and an IRR object does not create a ROA.

Is RPKI NotFound the same as Invalid?

No. NotFound means no covering ROA was found. Invalid means a covering authorization exists but the origin or permitted length does not match.

Does RPKI replace IRR?

No. RPKI authorizes the origin cryptographically; IRR publishes routing-policy information used by many operational filters. Production routing benefits when both describe the same intended route.

How do I fix a BGP, IRR and RPKI mismatch?

Define the intended prefix and origin, compare live BGP with the IRR object and ROA, update the stale layer in the right order, then verify route propagation from multiple networks.

Conclusion

BGP shows what is being announced, IRR shows the expected routing policy and RPKI verifies the authorized origin. When they disagree, the customer sees the result as a route that works in some places and fails in others.

Align the records around the production route, verify the customer path, and choose IPv4 capacity that can keep pace with the network. LARUS Continuity connects that operational work with direct IPv4 supply, so your next deployment can keep moving.