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

Internet routing relies on several systems that describe different parts of the same operational reality.

BGP shows which Autonomous System is actually announcing an IP prefix.

An Internet Routing Registry (IRR) route object can describe which ASN is expected to originate that prefix.

RPKI adds cryptographically verifiable routing authorization through Route Origin Authorizations, or ROAs.

Ideally, these layers agree.

But networks change.

A company may migrate to a new ASN, change upstream providers, lease a new IPv4 block, complete an IPv4 transfer, modify a ROA, or update an IRR object.

If one layer changes while another remains outdated, the same prefix may appear differently across BGP, IRR and RPKI.

The result can range from a harmless administrative inconsistency to an RPKI Invalid route, upstream filtering problem or partial reachability.

A mismatch does not automatically tell you which system is wrong. It tells you that the routing state needs investigation.

This guide explains how BGP, IRR and RPKI mismatches happen, what different combinations mean, and how network operators can restore alignment without making unnecessary changes to a running network.

BGP, IRR and RPKI Mismatch: Quick Answer

A BGP, IRR and RPKI mismatch occurs when the prefix and origin ASN observed in live BGP routing do not agree with the information published in an Internet Routing Registry, a Route Origin Authorization, or both.

For example:

• BGP may show AS64501
• The IRR route object may still list AS64500
• The ROA may authorize AS64500

That does not automatically mean AS64501 is malicious.

The network may simply have changed its origin ASN without updating the surrounding routing records.

But the mismatch can have operational consequences.

An outdated IRR record may conflict with filters generated from IRR data.

An incorrect ROA can cause a legitimate BGP announcement to become RPKI Invalid on networks performing Route Origin Validation.

The safest response is therefore:

1. Identify the intended origin ASN.
2. Verify the live BGP announcement.
3. Check the IRR route object.
4. Check the ROA and RPKI validation state.
5. Review recent network or resource changes.
6. Correct the layer that no longer reflects the intended deployment.
7. Verify global reachability after the change.

What Do BGP, IRR and RPKI Each Represent?

Understanding a mismatch starts with understanding that these systems answer different questions.

System	What It Represents	Core Question
BGP	Live routing reachability and path information	Which ASN is actually originating this prefix now?
IRR	Published routing-policy information	Which ASN is documented as the expected origin?
RPKI / ROA	Cryptographically verifiable origin authorization	Which ASN is authorized to originate this prefix?

These functions overlap, but they are not interchangeable.

BGP: What Is Actually Being Announced?

The Border Gateway Protocol is the inter-Autonomous System routing protocol used to exchange reachability information across the Internet.

The core BGP specification, RFC 4271 , describes BGP as a protocol for exchanging network reachability information between Autonomous Systems.

When an operator checks BGP for an IPv4 prefix, it can observe information such as:

• Origin ASN
• AS path
• Prefix length
• Upstream visibility
• More-specific announcements

BGP therefore tells you something extremely important:

What is the network actually announcing?

But an observed BGP route does not by itself prove that the origin ASN is authorized.

A configuration error, route leak or unauthorized announcement can also appear in BGP.

IRR: What Does the Published Routing Policy Say?

An Internet Routing Registry stores routing-policy information.

For IPv4, an IRRrouteobject typically associates:

• an IP prefix; and
• an origin ASN.

For example:

route:  203.0.113.0/24
origin: AS64500

This indicates that the IRR record associates the prefix with AS64500.

LARUS explains the structure and operational role in more detail in What Is an IRR Route Object? A Guide for Network Operators .

An IRR record describes routing-policy information. It does not itself create a BGP announcement.

Some networks use IRR information to help construct routing filters, which is why inaccurate or outdated route objects can still create operational problems.

RPKI: What Is Cryptographically Authorized?

Resource Public Key Infrastructure provides a cryptographic framework for routing-resource authorization.

A Route Origin Authorization specifies an authorized origin ASN for an IP prefix and can also define the maximum prefix length permitted by the authorization.

The current technical ROA profile is defined in RFC 9582 .

ROA data can be used through Route Origin Validation to classify BGP announcements according to whether they agree with validated authorization information.

LARUS provides a broader explanation in What Is RPKI?

RPKI therefore helps answer:

Is this origin ASN authorized to originate this prefix according to the validated RPKI data?

RPKI origin validation does not validate the complete AS path, and it does not replace BGP monitoring, IRR hygiene or operational filtering.

What Does a BGP, IRR and RPKI Mismatch Look Like?

Consider an organization using:

203.0.113.0/24

The intended origin ASN is:

AS64500

The ideal state is:

Layer	State
BGP	AS64500
IRR	AS64500
RPKI	AS64500 authorized
Result	Aligned

But after a network migration, BGP might change to:

AS64501

while the other records remain unchanged.

Layer	State
BGP	AS64501
IRR	AS64500
RPKI	AS64500 authorized
Result	BGP differs from both IRR and RPKI

The network now has to determine whether:

• AS64501 is the legitimate new origin
• the BGP configuration is wrong
• the IRR object is outdated
• the ROA is outdated
• an unexpected announcement has occurred

That investigation is the core of mismatch troubleshooting.

Common BGP, IRR and RPKI Mismatch Scenarios

The following table provides a useful starting point.

BGP	IRR	RPKI	Possible Interpretation
ASN A	ASN A	ASN A	Records are aligned
ASN B	ASN A	ASN A	BGP origin changed; verify whether routing or records should change
ASN B	ASN B	ASN A	IRR and BGP agree; ROA may need review
ASN B	ASN A	ASN B	BGP and ROA agree; IRR may be outdated
ASN A	Missing	ASN A	RPKI aligns with BGP; IRR information may be absent
ASN A	ASN A	NotFound	No covering validated ROA may exist
ASN A	ASN A	Invalid	Check ASN and prefix-length authorization
No visible route	ASN A	ASN A	Records exist, but prefix may not currently be announced

None of these rows should be interpreted as automatic proof of wrongdoing.

They are diagnostic signals.

Scenario 1: BGP Origin ASN Does Not Match the IRR Route Object

Suppose live BGP shows:

203.0.113.0/24 → AS64501

but the IRR route object says:

route:  203.0.113.0/24
origin: AS64500

There are several possible explanations.

The Network Recently Changed ASN

A network may have:

• Changed transit architecture
• Migrated infrastructure
• Moved to a new ASN
• Changed routing providers
• Reorganized its network

BGP may already reflect the new design while the IRR record still reflects the old one.

The IRR Object Was Not Updated

The migration may have been legitimate, but IRR maintenance was omitted from the change process.

BGP Is Incorrect

The reverse is also possible.

The IRR record may still describe the intended origin while BGP contains an accidental announcement from the wrong ASN.

Why It Matters

If an upstream or peer generates routing filters from IRR data, a legitimate BGP announcement that does not match the expected IRR information may encounter filtering problems.

The route works through one provider but not another.

This is one reason routing troubleshooting should use multiple external observations rather than only checking the local router.

Scenario 2: BGP Origin ASN Does Not Match the ROA

This mismatch can have more direct routing-security consequences.

Suppose:

BGP:  203.0.113.0/24 → AS64501
ROA:  203.0.113.0/24 → AS64500

If the route is covered by the ROA but the origin ASN does not match an authorized origin, Route Origin Validation may classify the announcement as Invalid.

Networks that apply policies rejecting RPKI Invalid routes may then refuse the announcement.

The result can be:

• Partial reachability
• Different visibility across networks
• Loss of traffic from ROV-enforcing networks
• Difficult-to-diagnose regional connectivity problems

RPKI does not automatically shut down a route. Network operators decide how RPKI validation results are applied in routing policy.

This means two networks can respond differently to the same mismatch.

Scenario 3: BGP and RPKI Agree, but IRR Is Outdated

Consider:

BGP:  AS64501
ROA:  AS64501
IRR:  AS64500

This may indicate that the live route and RPKI authorization reflect the intended new origin while the IRR record was not updated.

An operator should still verify the underlying change.

Possible consequences include:

• IRR-generated filters not recognizing the new origin
• Upstream onboarding delays
• Troubleshooting confusion
• Inconsistent records across routing tools

The fix may be as simple as correcting or replacing the relevant IRR object through the appropriate authorization process.

Scenario 4: BGP and IRR Agree, but RPKI Is Invalid

Consider:

BGP:  AS64501
IRR:  AS64501
ROA:  AS64500

The network may have updated its routing and IRR information correctly but forgotten to update the ROA.

This can happen during:

• ASN migration
• Transit-provider changes
• IPv4 leasing deployments
• IPv4 transfers
• Network restructuring

This is an especially important mismatch because the route can appear perfectly normal in BGP while still being classified as RPKI Invalid.

Scenario 5: The ASN Matches but the Prefix Length Does Not

Not every RPKI mismatch involves the origin ASN.

ROAs can also specify an allowed maximum prefix length.

Suppose a network is authorized for:

203.0.112.0/23

but announces:

203.0.113.0/24

Whether that announcement is RPKI Valid depends on the authorization and permitted prefix length.

A ROA that is too restrictive can therefore make a legitimate more-specific announcement Invalid.

When troubleshooting RPKI, always check both:

• Origin ASN
• Prefix length / MaxLength

Do not check the ASN alone.

Why Can a Routing Mismatch Cause Partial Reachability?

A common misconception is that routing either works globally or fails globally.

Real Internet routing is more complicated.

Different networks can use different:

• IRR databases
• Filter-generation processes
• RPKI validators
• ROV policies
• Cache update schedules
• Transit policies
• Peering policies

As a result, one network may continue accepting a route while another rejects it.

Network A → reachable
Network B → reachable
Network C → unreachable
Network D → reachable
Network E → unreachable

This can be more difficult to diagnose than a total outage.

The service may appear healthy from the operator's own location while some customers cannot reach it.

That is why routing validation should use several external perspectives.

What Causes BGP, IRR and RPKI Records to Become Misaligned?

Most mismatches do not require a dramatic explanation.

Networks change constantly.

Origin ASN Changes

A network begins announcing a prefix from a different ASN.

Transit Provider Migration

Routing architecture changes, but related authorization data is not reviewed.

IPv4 Leasing

A leased prefix is moved into a customer's network, requiring coordination between the IPv4 provider, customer ASN, IRR and RPKI.

For organizations preparing a leased-prefix deployment, LARUS provides a step-by-step guide on how to lease IPv4 addresses .

IPv4 Transfers

After an IPv4 transfer, registration records may change before or after operational routing is migrated.

For a transfer-specific explanation, i.lease discusses what happens to IPv4 records after an IP address transfer .

Human Error

A network engineer may update one system but miss another.

Automation Failure

An intended synchronized change may only partially complete.

Incorrect MaxLength

The origin ASN is correct, but the ROA does not permit the announced prefix length.

Old IRR Objects

A route object remains after the actual routing relationship has changed.

Unexpected Administrative Changes

Registry-account, RPKI or IRR changes may occur separately from the intended routing plan.

Heng Lu discusses this broader continuity scenario in Preparing for an Unexpected Change in Registry Records .

IRR vs RPKI: Which One Should Network Operators Trust?

This is the wrong question.

IRR and RPKI are not competing versions of the same database.

They provide different information through different trust models.

IRR helps publish routing-policy information.

RPKI provides cryptographically verifiable origin authorization.

BGP shows the route being propagated by the operational network.

A better question is:

Do these layers accurately describe the network we intend to operate?

If not, investigate the difference.

NRS.help provides a deeper comparison in RPKI vs IRR: What’s the Difference and Why You Need Both .

How to Troubleshoot a BGP, IRR and RPKI Mismatch

A disciplined troubleshooting process reduces the risk of fixing the wrong system.

Step 1: Define the Intended Routing State

Before changing anything, answer:

• Which prefix should be announced?
• Which ASN should originate it?
• Which prefix lengths are expected?
• Is the change permanent or temporary?
• Has a migration recently occurred?

Without an intended state, there is no reliable baseline.

Step 2: Check Live BGP

Verify:

• Current origin ASN
• Prefix length
• AS path
• More-specific routes
• Global visibility
• Multiple route collectors or looking glasses

Do not rely on only one network view.

Step 3: Check the IRR Route Object

Confirm:

• Prefix
• Origin ASN
• Source IRR
• Maintainer
• Last modification
• Whether multiple or conflicting objects exist

Compare the object with the intended routing state.

Step 4: Check RPKI / ROA

Verify:

• Does a covering ROA exist?
• Which ASN is authorized?
• What prefix is covered?
• What MaxLength is permitted?
• Is the observed route Valid, Invalid or NotFound?

ARIN's ROA documentation provides additional information about ROA management.

Step 5: Review Recent Changes

Look for:

• ASN migrations
• Prefix moves
• Transit changes
• IPv4 transfers
• IPv4 leases
• ROA modifications
• IRR updates
• Registry-account changes

Step 6: Identify Which Layer Needs Correction

Do not automatically modify every system.

If the intended ASN is AS64501 and:

BGP = AS64501
IRR = AS64500
RPKI = AS64500

then IRR and RPKI may both require coordinated updates.

But if:

Intended ASN = AS64500
BGP = AS64501
IRR = AS64500
RPKI = AS64500

the BGP configuration may be the actual problem.

Step 7: Coordinate Changes in the Right Order

For a planned origin-AS change, an operator may need to coordinate:

1. Authorization
2. ROA
3. IRR
4. Upstream filters
5. BGP announcement
6. Validation
7. Removal of obsolete records

The important principle is to avoid creating a period in which the legitimate route becomes unintentionally Invalid or filtered.

Step 8: Verify From Multiple Networks

After correcting the mismatch, verify:

• BGP origin
• RPKI validation
• IRR information
• Global route propagation
• Regional reachability
• Customer connectivity

Do not assume a database update means the operational problem has disappeared.

BGP, IRR and RPKI Mismatch Troubleshooting Checklist

BGP

• Correct prefix is announced
• Correct origin ASN appears
• Expected prefix length is used
• No unexpected more-specific announcement exists
• Route appears from multiple collectors
• Upstream providers accept the route

IRR

• Correct route object exists
• Correct origin ASN is listed
• Correct IRR source is being used
• No obsolete conflicting object is causing confusion
• Maintainer authorization is understood

RPKI

• Correct ROA exists
• Correct origin ASN is authorized
• Correct prefix is covered
• MaxLength supports intended announcements
• Route is not unexpectedly Invalid

Operations

• LOA is current where required
• Transit-provider filters are updated
• Changes are documented
• Multiple external routing views have been checked
• Rollback procedure exists for major migrations

Why Registry and Routing Accuracy Matter

A routing system can continue operating even while some surrounding records are stale.

That does not mean those records are irrelevant.

Accurate information helps operators:

• Troubleshoot routing
• Verify authorization
• Build filters
• Coordinate migrations
• Respond to incidents
• Understand resource relationships
• Maintain network continuity

LARUS Foundation discusses this broader coordination principle in Why Accurate Registry Data Supports a Stable Internet .

Registry and authorization systems support the network. They do not replace the network.

A healthy operational model therefore keeps coordination records aligned with legitimate running-code reality.

Why This Matters During IPv4 Leasing

A BGP, IRR and RPKI mismatch is particularly important when deploying leased IPv4.

Imagine a business leases a/22and intends to announce it through its own ASN.

IPv4 Resource
      ↓
Lease Authorization
      ↓
LOA
      ↓
IRR Route Object
      ↓
RPKI / ROA
      ↓
Customer ASN
      ↓
BGP
      ↓
Global Reachability

If the provider supplies the resource but the routing layers are not coordinated, the block may not behave as expected.

Before deploying leased IPv4, businesses should therefore clarify:

• Which ASN will originate the prefix?
• Who creates or updates the IRR object?
• Who controls the ROA?
• Which MaxLength is required?
• Who provides the LOA?
• Who handles routing changes?
• What happens if the customer changes ASN?
• How quickly can an incorrect record be corrected?
• Who is responsible during renewal or termination?

This is why a production IPv4 lease should not be evaluated only by monthly price.

Operational control matters.

A Five-Layer View of Routing Alignment

For production networks, it can be useful to think about routing readiness across five layers.

Layer	Key Question
Resource	Who controls or administers the IPv4 resource?
Authorization	Who has authorized the network to use and announce it?
Policy	Do IRR records describe the intended routing relationship?
Security	Does RPKI authorize the intended origin ASN and prefix length?
Operation	Does live BGP reflect the intended running network?

A mismatch usually means one of these layers has changed without the others following.

For critical infrastructure, knowing who can correct each layer is just as important as discovering the mismatch itself.

How LARUS Approaches Production IPv4 Deployment

For businesses that depend on stable public IPv4, obtaining a prefix is only the beginning.

Once address space enters production, it may become connected to:

• BGP routing
• RPKI / ROAs
• IRR records
• Reverse DNS
• Customer configurations
• Firewall rules
• Partner allowlists
• Geolocation
• Reputation
• Abuse workflows

LARUS's IPv4 leasing model is designed around this wider operational lifecycle, including routing and continuity considerations rather than treating every prefix as interchangeable inventory.

Organizations evaluating leased IPv4 can review LARUS IPv4 Leasing & Continuity Assurance to understand available deployment and continuity options.

IPv4 capacity should not only be available. It should be deployable, supportable and aligned with the network that depends on it.

Frequently Asked Questions

What is a BGP, IRR and RPKI mismatch?

A BGP, IRR and RPKI mismatch occurs when live BGP routing information does not agree with the origin information published in an IRR route object, an RPKI ROA, or both.

Does a mismatch mean the BGP route is wrong?

No. BGP may reflect a legitimate new network configuration while IRR or RPKI data remains outdated. Conversely, BGP itself may be incorrectly configured. The intended routing state must be verified first.

What happens if BGP and RPKI do not match?

If a BGP announcement is covered by a ROA but does not match the authorized origin ASN or permitted prefix length, it may be classified as RPKI Invalid. Networks applying ROV rejection policies may reject it.

What happens if BGP and IRR do not match?

Networks using IRR-derived route filters may not recognize the announcement as expected. The operational impact depends on which IRR data and filtering policies each network uses.

Can a route be RPKI Valid but missing from IRR?

Yes. IRR and RPKI are separate systems. A route may have valid RPKI authorization even when a corresponding IRR route object is missing.

Can the IRR be correct while RPKI is wrong?

Yes. For example, an operator may update an IRR route object during an ASN migration but forget to update the ROA.

What does RPKI Invalid mean?

RPKI Invalid generally means a covering validated authorization exists, but the observed route does not match an authorized origin ASN or allowed prefix length.

Is RPKI NotFound the same as Invalid?

No. NotFound generally indicates that no validated ROA covers the route. Invalid indicates that relevant authorization exists but the announcement does not satisfy it.

Does RPKI replace IRR?

No. RPKI provides cryptographically verifiable origin authorization, while IRR provides routing-policy information that may be used for filtering and operational coordination.

Should BGP always be treated as the source of truth?

No. BGP shows what is being announced, but the announcement may be legitimate, misconfigured or unauthorized. Live routing should be evaluated alongside intended network configuration and authorization information.

Can BGP, IRR and RPKI mismatch cause partial reachability?

Yes. Different networks may apply different IRR filters and RPKI validation policies. A route can therefore be accepted by some networks and rejected by others.

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

First define the intended origin ASN and prefix. Then compare live BGP, IRR and RPKI information, identify which layer is outdated or incorrect, coordinate the required changes, and verify route propagation afterward.

Conclusion

BGP, IRR and RPKI describe different layers of Internet routing.

BGP shows the route being announced.

IRR publishes routing-policy information.

RPKI provides cryptographically verifiable origin authorization.

When all three agree, operators have a clearer and more consistent picture of the intended route.

When they disagree, the correct response is not to assume automatically that one system must override the others.

Instead:

1. Determine the intended network state.
2. Observe the live route.
3. Verify the routing-policy record.
4. Verify the cryptographic authorization.
5. Identify the stale or incorrect layer.
6. Correct it through the appropriate process.
7. Confirm that the running network remains reachable.

Routing records are most useful when they accurately describe and support the legitimate network that is actually intended to run.

For network operators, cloud providers, ISPs, hosting companies and enterprises, maintaining that alignment reduces uncertainty during routing changes, IPv4 leasing, transfers and infrastructure migrations.

And when an IPv4 prefix becomes part of production infrastructure, that alignment becomes more than administrative hygiene.

It becomes part of network continuity.