What Happens When Internet Routing Goes Wrong?

The Internet usually makes routing look invisible.

A customer opens a website. An API connects to a server. A cloud workload communicates with another network. A user sends a request from one country to infrastructure located thousands of kilometres away.

Traffic may cross several independently operated networks before reaching its destination, yet the entire process often takes only milliseconds.

Behind that apparent simplicity is a global routing system built largely around the Border Gateway Protocol, or BGP.

When routing works, few users think about it.

When routing goes wrong, however, the consequences can be immediate.

A prefix may disappear.

Traffic may take the wrong path.

A legitimate network may become unreachable.

An unauthorized network may begin announcing another operator’s address space.

A Route Origin Authorization may no longer match the ASN actually originating a prefix.

And in more complex cases, technical routing reality, security authorization, registry information, and institutional processes may begin telling different stories.

For Internet service providers, cloud platforms, hosting companies, data centres, telecom operators, enterprises, and other infrastructure operators, this is not merely a networking problem.

Internet routing failure can become a business-continuity failure.

That is why routing resilience must be considered together with Internet number-resource management, RPKI, registry accuracy, operational authority, portability, and continuity planning.

How Internet Routing Works

The Internet is not one centrally controlled network.

It is a collection of independently operated networks that agree to exchange traffic.

Many of these networks operate as Autonomous Systems.

Each Autonomous System may be identified by an Autonomous System Number, or ASN.

Examples include:

• Internet service providers
• Cloud providers
• Telecom operators
• Large enterprises
• Universities
• Content networks
• Data centres
• Hosting providers

These networks exchange reachability information using BGP.

In simplified form, a network tells its neighbours:

“I can reach this IP prefix through this path.”

That information may then be propagated to other networks.

Routers evaluate available paths and decide which route to use according to BGP attributes and local routing policies.

This decentralized architecture is one of the reasons the Internet can operate at global scale.

No central router decides the path of every packet.

But decentralization also means that routing depends on the quality of information that independently operated networks exchange and accept.

When that information becomes incorrect, the consequences can spread.

What Does It Mean When Internet Routing Goes Wrong?

A routing problem occurs when traffic does not reach an IP prefix through the expected or legitimate path.

That can produce several symptoms:

• A website becomes unreachable
• Customers lose access to applications
• Traffic is sent through an unexpected network
• Latency suddenly increases
• Packet loss appears
• Only some geographic regions can reach a service
• A prefix disappears from the global routing table
• An unexpected ASN begins originating the prefix
• A legitimate route becomes RPKI-invalid

The cause may be accidental.

It may be malicious.

It may result from inconsistent technical records.

Or it may occur because an administrative or registry-layer change no longer reflects the live network.

Understanding the difference matters because fixing the wrong layer may not restore continuity.

BGP Route Leaks

A BGP route leak happens when routing information is propagated beyond the scope where it was intended to be advertised.

Consider a network that learns a route from one provider.

Because of an incorrect routing policy, it advertises that route to another provider.

That second provider accepts the route and propagates it further.

Traffic that should have followed a different path may suddenly be attracted through the wrong network.

The consequences can include:

• Increased latency
• Congestion
• Packet loss
• Partial outages
• Large-scale reachability problems

A route leak does not necessarily involve an attacker.

A simple configuration error can cause significant disruption.

That is why BGP policy, prefix filtering, and change control are essential parts of network operations.

BGP Hijacking

A BGP hijack occurs when a network announces an IP prefix that it is not legitimately expected to originate.

If other networks accept that announcement, traffic may begin travelling toward the wrong Autonomous System.

Depending on the incident, this may cause:

• Service outages
• Traffic redirection
• Connectivity loss
• Potential interception risk
• Security alerts
• Customer disruption

Traditional BGP was not originally designed with cryptographic proof that every origin announcement was authorized by the relevant resource holder.

That limitation is one of the reasons mechanisms such as RPKI have become important.

But BGP hijacking also illustrates a larger point:

A route announcement, a registry record, and legitimate operational control are related—but they are not identical things.

The routing system still requires networks to evaluate what they receive.

Incorrect BGP Configuration

Many routing incidents are less dramatic than hijacking.

Simple configuration mistakes can cause serious consequences.

Examples include:

• Advertising the wrong prefix
• Forgetting to announce a required prefix
• Incorrect prefix filters
• Using the wrong ASN
• Withdrawing a route accidentally
• Incorrect local-preference settings
• Advertising unintended more-specific prefixes
• Failing to update routing after a network migration

A small configuration error in a large network can affect thousands of customers.

This is why routing changes should be treated as controlled production changes.

Operators should understand both:

What should be announced

and

Which ASN should be authorized to announce it.

RPKI and ROA Misconfiguration

Resource Public Key Infrastructure, or RPKI, provides cryptographically verifiable information that networks can use to determine whether an ASN is authorized to originate a particular IP prefix.

A resource holder can create a Route Origin Authorization, or ROA.

A ROA normally identifies:

• The IP prefix
• The ASN authorized to originate it
• The permitted maximum prefix length

Networks performing Route Origin Validation can compare a BGP announcement against this information.

A route may then be classified as:

• Valid
• Invalid
• Not Found

This provides an important additional security signal.

But RPKI itself must remain synchronized with operational reality.

Imagine that an organization changes its origin ASN.

The BGP configuration is updated.

The new route is operationally legitimate.

But the ROA still authorizes only the old ASN.

The result?

A legitimate production route may now appear RPKI-invalid.

Similarly, if a network announces a more-specific prefix that is not permitted by the ROA’s maximum-length configuration, that announcement can also become invalid.

The important principle is therefore:

Routing authorization must track running-network reality.

RPKI Should Protect Security, Not Become an Enforcement Weapon

RPKI exists to improve routing security.

Its purpose is to help networks evaluate whether an ASN is authorized to originate an IP prefix.

It should not become a general-purpose enforcement mechanism for unrelated commercial, institutional, membership, or policy disputes.

This distinction is critical.

A disagreement about:

• Commercial use
• Customer geography
• Leasing
• Registry policy
• Institutional membership
• Business structure

is not automatically a routing-security failure.

If a network continues legitimately operating a resource, security assertions should remain tied to technical validity and recognized operational control rather than being used as leverage in an unrelated dispute.

Otherwise, security infrastructure itself becomes a potential continuity risk.

For network operators, the principle should be straightforward:

RPKI should protect routing integrity, not punish policy disagreement.

RPKI Does Not Solve Every Routing Problem

RPKI is valuable, but it is not a complete solution to Internet routing security.

Route Origin Validation primarily helps answer:

“Is this ASN authorized to originate this prefix?”

It does not independently verify every element of the full AS path.

It also does not eliminate:

• Route leaks
• Every form of path manipulation
• Incorrect internal routing
• Upstream configuration failures
• Physical network outages
• Poor routing policy

This is why RPKI should be treated as one component of a larger routing-security framework.

Other controls include:

• Prefix filtering
• IRR information
• BGP monitoring
• Route-policy management
• Accurate registry data
• Operational change control

NRS.help explores this relationship further in its guide to RPKI and IRR and why network operators may need both.

Outdated IRR Records Can Affect Routing

Internet Routing Registries, or IRRs, contain routing-policy information that operators can use to construct route filters.

For example, a provider may use an IRR route object to help determine which prefixes it expects a customer ASN to advertise.

If the information is outdated, a legitimate announcement may be rejected.

Alternatively, inaccurate records may make filtering less effective.

Problems can arise when:

• A customer changes ASN
• A prefix changes operators
• Old route objects remain
• New route objects are never created
• Network architecture changes without record updates

This demonstrates an important principle:

Routing information is operational infrastructure.

Registry and routing records should reflect reality accurately enough that other networks can rely on them.

Why WHOIS and RDAP Accuracy Still Matters

WHOIS and RDAP do not route packets.

But they play an important role in understanding Internet number resources.

During an incident, operators may need to determine:

• Which organization is associated with a prefix
• Which contacts are responsible
• Which Regional Internet Registry maintains the record
• Which ASN is expected to originate the resource
• Whether organizational details have changed

If the records are inaccurate, incident response becomes more difficult.

An incorrect contact record might not cause the original outage.

But it can make the outage harder to resolve.

This is why NRS.help recommends maintaining accurate Internet number-resource information rather than treating registry data as administrative paperwork.

Read more: How Outdated WHOIS Records Put Your Network at Risk.

A Registry Record Describes Reality—It Does Not Create It

This distinction is fundamental.

Internet registries are necessary because number resources must remain unique.

Operators need reliable information about:

• Resource relationships
• Contact information
• Registration status
• Transfers
• Security assertions
• Disputes

But the database is not the live network.

Packets do not move because a registry entry tells them to move.

BGP routers exchange routes.

Networks apply routing policies.

Operators maintain infrastructure.

Customers depend on services.

A registry record should therefore attempt to reflect operational and legal reality accurately.

It should not be treated as though changing the database automatically rewrites every other layer of reality.

A useful way to think about the relationship is:

Running network → operational control → routing authorization → registry record

These layers should agree.

When they do not, the correct objective is reconciliation.

Not destruction.

What Happens When Registry Reality and Routing Reality Diverge?

This is one of the more difficult continuity problems.

Imagine a network is actively using an IPv4 block.

Its customers depend on that block.

DNS records reference it.

Security systems allowlist it.

Its ASN announces it.

Applications rely on it.

But an administrative dispute arises around the resource.

Now several different realities may exist at the same time:

• The network is running
• Customers continue using the service
• BGP announcements remain visible
• A registry record is disputed
• Security authorization may be under review
• Contractual claims may conflict

The wrong response is to assume that the registry record should automatically override all other reality layers.

The safer principle is:

Preserve the last verified operational state while the underlying dispute is resolved independently.

The goal should be to avoid turning an administrative disagreement into a routing outage.

That means protecting:

• Existing routes
• Customers
• Security assertions
• DNS
• Reverse DNS
• Registry history
• Evidence
• Neutral dispute resolution

Network continuity should not become collateral damage.

Registration and Routing Are Different Functions

An organization may be recognized in registry records as the holder of an IPv4 block.

That alone does not cause the block to become reachable.

The prefix must still be announced through BGP.

Likewise, a network can technically announce a prefix even if other information about the resource is wrong.

This means several questions need separate answers:

Who is recorded?

Who controls the resource operationally?

Which ASN is authorized?

Which ASN is actually announcing it?

Which networks are accepting the announcement?

Confusing these layers can make incident response slower.

Routing engineers need to understand registry information.

Resource administrators need to understand routing.

Security teams need to understand RPKI.

Organizations should therefore avoid placing each function into a separate silo.

What Happens to Users During a Routing Failure?

Users do not see BGP messages.

They see symptoms.

A customer might report:

“Your site is down.”

Another may say:

“We can reach you from one country but not another.”

A third may find that mobile connectivity works while fixed broadband does not.

Different networks may receive and select different BGP paths.

That can create partial failures such as:

• One ISP reaches the service correctly
• Another ISP follows an incorrect route
• Another rejects the announcement
• Some countries retain connectivity
• Other regions lose access

This is why routing incidents can be confusing.

Application monitoring may show healthy servers while customers remain unable to reach them.

From the customer’s perspective, however, the distinction rarely matters.

The service is unavailable.

Why Routing Failures Become Business-Continuity Events

A routing incident can rapidly move beyond the network engineering team.

Revenue

If customers cannot reach a service, transactions may stop.

This is particularly serious for:

• SaaS
• Cloud platforms
• Hosting
• Fintech
• E-commerce
• ISPs
• Gaming
• Online services

Customer Support

A routing failure can create a flood of tickets even when application servers remain healthy.

Service-Level Agreements

Infrastructure companies may have uptime commitments.

A routing outage can create an SLA event even when internal systems are working.

Customer Trust

Customers generally do not distinguish between a failed server and a failed route.

They know only that the service was unavailable.

Operational Cost

A routing incident may require coordination among:

• Network engineering
• Upstream providers
• Security teams
• Registry/resource administrators
• RPKI administrators
• Customer support
• Management
• External operators

This is why Internet number-resource continuity belongs inside the broader business-continuity framework.

How Do You Know When Routing Is the Problem?

When a service becomes unreachable, operators should avoid immediately assuming that the application or server has failed.

Start with several questions.

Is the Prefix Still Visible?

Check whether the affected prefix is present in global routing views.

If it disappeared, investigate the BGP announcement.

Which ASN Is Originating the Prefix?

Compare the observed ASN with the expected origin.

An unexpected origin may indicate:

• Misconfiguration
• Migration error
• Hijacking
• Stale authorization
•  

What Is the RPKI Status?

Determine whether the route is:

• Valid
• Invalid
• Not Found

If a legitimate routing change suddenly creates an invalid state, check the ROA.

Are More-Specific Prefixes Appearing?

A more-specific route can attract traffic away from an aggregate.

Operators should inspect both the expected prefix and any sub-prefixes.

Did Anything Change?

Review recent:

• Router changes
• Provider migrations
• ASN changes
• RPKI updates
• Prefix-filter changes
• Infrastructure migrations
• Registry updates

Timing can reveal the cause.

Are Registry and IRR Records Accurate?

Check whether supporting resource and routing records still reflect the production network.

What Should Operators Do When Internet Routing Goes Wrong?

A structured response reduces confusion.

Step 1: Establish the Expected State

Document:

• Affected prefix
• Expected origin ASN
• Expected upstream
• Intended BGP announcement
• Current ROA
• Relevant IRR object

You cannot identify divergence without a baseline.

Step 2: Compare Multiple Routing Views

Do not rely on one local router.

Examine how the prefix appears from different networks and geographic regions.

This helps determine whether the problem is:

• Local
• Upstream
• Regional
• Globally propagated
•  

Step 3: Verify RPKI

Confirm:

• Correct prefix
• Correct ASN
• Correct maximum length
• Correct authorization period

If the network architecture recently changed, verify that the ROA changed with it.

NRS.help provides more detail in How to Use RPKI to Prevent Unauthorised Announcements.

Step 4: Review IRR and Prefix Filters

Check whether upstream filters reflect the routes the customer is legitimately expected to announce.

Step 5: Contact the Relevant Network

When coordinating with upstreams or peers, provide precise information:

• Prefix
• Expected ASN
• Observed ASN
• RPKI status
• Incident time
• Routing evidence

Specific technical information speeds resolution.

Step 6: Correct the Source

If the problem originated inside the network, correct the configuration and verify propagation.

Step 7: Protect Continuity During Disputes

If the problem involves registry or resource-control uncertainty, avoid destructive changes while the matter is unresolved.

Preserve:

• Last verified routing state
• Security information
• Registry history
• Evidence
• Customer continuity

Resolve the dispute without unnecessarily destabilizing the network.

Step 8: Monitor Recovery

Routing changes may not appear uniformly everywhere at the same time.

Continue observing reachability until the expected route is visible and customer connectivity has stabilized.

How Networks Can Reduce Routing Risk

No network can eliminate every routing incident.

But operators can reduce both probability and impact.

Maintain Correct ROAs

ROAs should reflect actual routing architecture.

Review them whenever:

• Origin ASN changes
• Provider changes
• Prefix length changes
• Network architecture changes
•  

Use Route Origin Validation

Networks receiving BGP routes can use RPKI validation as part of routing policy.

Maintain Accurate IRR Information

Routing records should match legitimate expected announcements.

Apply Prefix Filtering

A BGP neighbour should not automatically be permitted to announce any route.

Filtering can limit propagation of mistakes.

Monitor Route Announcements

Operators should detect when:

• Their prefix disappears
• A new ASN originates it
• Unexpected more-specifics appear
• RPKI status changes
• The AS path changes unexpectedly

Early detection reduces the duration of incidents.

Maintain Accurate Registry Information

Contacts, organization information, and resource records should remain current.

Audit Internet Number Resources

Organizations should periodically audit:

• IPv4
• IPv6
• ASNs
• BGP announcements
• RPKI
• IRR records
• Registry access
• Organizational contacts
• Contracts
• Network dependencies

See: How to Audit Your Company’s Internet Number Resources.

Why Portability Matters to Routing Continuity

A resilient system should not force a running network to become permanently dependent on one institutional gatekeeper.

If a registry or service provider:

• Fails
• Becomes insolvent
• Becomes technically unavailable
• Enters a serious governance dispute
• Becomes legally unable to operate
• Loses the trust of the operator

the number resource itself should still have a continuity path.

This is why resource-level portability matters.

Portability does not necessarily mean moving an entire organization or changing the location of a company.

It means that the operational registration and continuity of a specific resource should not be trapped permanently inside one failed institutional structure.

A resilient Internet-number system should make it possible to preserve:

• Proof of control
• Registry records
• Reverse DNS
• RPKI
• Routing continuity
• Historical audit information

while the administrative provider changes.

Without an exit path, institutional failure becomes a network failure.

Why Registry Failover Matters

Critical infrastructure should not depend entirely on the survival of one corporation.

The more important the function, the more carefully its failure path should be designed.

For Internet number resources, continuity planning should consider:

• Registry-state backups
• Historical records
• WHOIS/RDAP continuity
• Reverse DNS
• RPKI repositories
• Security credentials
• Transfer history
• Dispute metadata
• Successor administration

The principle is simple:

The registry function should survive the registry institution.

Protecting registry continuity therefore does not necessarily mean protecting every board, policy structure, contractual interpretation, or institutional power held by the incumbent operator.

It means protecting the technical functions the Internet actually needs.

Protect the Ledger, Not the Gatekeeper

Internet routing depends on trustworthy coordination.

That coordination is real and necessary.

IP addresses must remain unique.

Registry information should be accurate.

Routing-security assertions should remain available.

Disputes should be documented.

But the institution maintaining a record should not be confused with the record itself.

If a registry organization experiences a problem, the objective should be:

Preserve the ledger.

Preserve the security chain.

Preserve the routes.

Preserve the customers.

Preserve the running network.

The system should not require preserving unlimited institutional control simply because an organization currently maintains part of the infrastructure.

The more critical a coordination function becomes, the more auditable, replaceable, portable, and resilient its operator should be.

Running-Code Primacy

Routing ultimately exists to serve running networks.

That leads to a useful principle:

Running-Code Primacy.

The common Internet coordination layer should focus on what operational interoperability actually requires.

For number resources, that includes:

• Uniqueness
• Accurate records
• Proof of control
• Security assertions
• Transfer recording
• Conflict metadata
• Operational continuity

It does not automatically require a registry to control:

• Commercial models
• Customer geography
• Leasing
• Asset financing
• Business strategy
• Every future use of a resource

These issues may be governed by contracts, law, markets, operators, or other appropriate mechanisms.

They should not be transformed into routing failures unless they actually create a technical threat to uniqueness or interoperability.

This distinction keeps the registry layer narrow and the running Internet resilient.

Network Continuity Should Come Before Institutional Continuity

When organizations speak about “Internet stability,” the phrase can hide an important question:

Stability of what?

There is institutional stability.

And there is routed-network stability.

For operators and customers, the second is usually what matters most.

A registry can have a functioning office while a customer network is offline.

That is not meaningful Internet stability.

Likewise, an institution may experience governance problems while networks continue routing successfully.

That does not automatically mean the Internet itself is unstable.

The most useful stability metric is therefore:

Can legitimate networks continue operating?

Can customers remain reachable?

Can routes continue propagating?

Can valid security assertions remain available?

Can disputes be resolved without destroying production infrastructure?

This is the continuity that Internet governance should ultimately protect.

Build a Number-Resource Continuity Plan

Organizations routinely create continuity plans for:

• Power
• Data centres
• Cloud providers
• Transit
• Hardware
• Employees
• Cybersecurity

Internet number resources deserve the same treatment.

Ask:

• What happens if our prefix disappears from BGP?
• Who can update our ROA?
• Who controls our RIR credentials?
• Which ASN should originate each prefix?
• Which customers rely on fixed addresses?
• Which applications depend on our IP ranges?
• Who can contact our upstream provider?
• What if our registry becomes unavailable?
• What evidence proves control of our resources?
• Can our registration services fail over?
• What happens during a resource dispute?

NRS.help discusses this broader resilience requirement in Why Infrastructure Operators Need Continuity Plans for Number Resources.

The Bigger Lesson: IP Addresses and ASNs Are Business-Critical Infrastructure

Organizations sometimes treat Internet number resources as background technical data.

That is increasingly unrealistic.

Public IP addresses and ASNs may be connected to:

• Customers
• APIs
• DNS
• Firewalls
• VPNs
• Partner allowlists
• Cloud systems
• Security policies
• Payment networks
• Monitoring
• Compliance documentation

A network identifier can become embedded deeply into business operations.

A server may be healthy.

The application may be running.

The data centre may have power.

But if the IP prefix cannot be routed correctly, users still cannot reach it.

That is why Internet number-resource continuity belongs inside business-continuity planning.

Final Thoughts

When Internet routing goes wrong, the symptoms can be immediate.

A prefix disappears.

Traffic follows the wrong path.

An unexpected ASN begins announcing a block.

A legitimate route becomes RPKI-invalid.

Customers can reach a service from one network but not another.

The underlying cause may be:

• BGP misconfiguration
• A route leak
• A hijack
• Incorrect prefix filtering
• An outdated ROA
• Stale IRR information
• Inaccurate registry records
• A divergence between administrative and operational reality

But the deeper lesson is broader.

Internet routing is not protected only by routers.

It depends on the relationship between:

Running networks

Number resources

Routing authorization

Registry records

Security infrastructure

Operational control

The systems surrounding IPv4, IPv6, and ASNs should therefore be designed around continuity.

Registries should preserve uniqueness.

Records should reflect reality.

RPKI should protect routing security.

Disputes should be isolated.

Portability should provide an exit path.

Failover should protect critical registry functions.

And no administrative disagreement should unnecessarily become a customer outage.

The objective is not institutional immortality.

It is Internet continuity.

Protect the running network.

Protect the customer.

Protect the security assertions.

Protect the ledger.

Do not confuse the gatekeeper with the infrastructure it was created to serve.