When an IPv4 or IPv6 prefix is announced on the public Internet, one of the most useful pieces of information is the origin ASN. The origin ASN identifies the Autonomous System that is currently announcing the prefix through BGP.
Finding the origin ASN can help with network troubleshooting, IPv4 transfers, IPv6 deployment, BGP monitoring, RPKI validation, provider migrations, and IP prefix verification. It can also show whether a prefix is being announced by the ASN you expected.
For example, a company may own or lease an IPv4 block and plan to announce it from its own ASN. Before moving production traffic, the network team may want to confirm whether the prefix is visible in BGP, which ASN currently originates it, and whether the result matches the registry and routing plan.
The process is relatively simple, but several concepts are often confused. The origin ASN is not always the organisation listed in the registry. It is not necessarily the same as the transit provider carrying the route. It is also different from every ASN that appears in the complete BGP path.
This guide explains what an origin ASN means, how to find it with public tools, how to query RIPEstat, and how to investigate multiple or unexpected origin ASNs.
What Is an Origin ASN?
An Autonomous System Number, or ASN, identifies an independent network that exchanges routing information with other networks using BGP. Internet service providers, cloud platforms, hosting companies, enterprises, universities, content networks, and other operators may use ASNs.
The origin ASN is the ASN that appears to be the source of a specific IP prefix in a BGP announcement. If a route for 198.51.100.0/24 has origin AS64500, the Internet is being told that AS64500 can reach or deliver traffic for that prefix.
The word “origin” refers to the end of the AS path closest to the advertised prefix. It does not automatically mean that the ASN owns the address space. An organisation may hold the IP resource while another ASN announces it through a hosting, transit, sponsorship, or managed routing arrangement.
A route can pass through several autonomous systems before reaching the origin. A simplified BGP path may look like this:
AS3356 AS64510 AS64500In this example, AS3356 may be an upstream transit provider, AS64510 may be another network, and AS64500 is the origin ASN for the prefix.
Why Is the Origin ASN Important?
The origin ASN helps explain how an IP prefix is currently connected to the Internet. If a company expects its prefix to be announced by its own ASN but public BGP data shows a different origin, the routing design may not be complete or may require further investigation.
Origin ASN information is especially useful during an IPv4 transfer. The receiving organisation may plan to announce the transferred block from a new ASN. Checking the current origin before the transfer and the new origin after the transfer helps confirm that the routing change happened as planned.
It is also useful during an ASN migration. A business may move from a provider-managed ASN to its own ASN or change the organisation responsible for announcing a prefix. If the old origin remains visible after the migration, the previous route may still be active.
Origin ASN information is also connected to RPKI. A Route Origin Authorization identifies which ASN is authorised to originate a prefix. If the BGP origin does not match the RPKI authorization, the route may be classified as Invalid.
Origin ASN vs Registered Organisation
The organisation shown in a registry record and the ASN shown as the BGP origin are related but not identical.
A registry database records information about Internet number resources, such as an inetnum, inet6num, organisation reference, resource status, country, and abuse contact. BGP shows which network is currently announcing a route. The registered holder may use a sponsoring LIR, transit provider, cloud platform, or managed routing provider to announce the resource.
For example, a company may be listed as the holder of an IPv4 prefix while a network provider announces the prefix from the provider’s ASN. This may be a legitimate arrangement if the contract, routing permissions, and registry records support it.
The opposite situation is also possible. An ASN may announce a prefix without an obvious relationship to the organisation shown in the registry. This does not automatically prove that the route is malicious, but the difference should be investigated, especially if the origin is unexpected or the prefix is being evaluated for purchase or transfer.
A reliable review should compare the registry organisation, current origin ASN, IRR route object, RPKI status, and the actual commercial or technical arrangement.
How to Find an Origin ASN with RIPEstat
RIPEstat is a public network information service that provides information about Internet resources, BGP routing, RPKI, and other operational signals. Its BGP State data can be used to check whether a prefix is currently announced and which origins have been observed.
Open RIPEstat and enter an IPv4 or IPv6 prefix. The result may show the announcement state, observed origin ASNs, route information, and timestamps.
You can also query the RIPEstat API directly:
https://stat.ripe.net/data/bgp-state/data.json?resource=193.0.0.0/21For an IPv6 prefix, use:
https://stat.ripe.net/data/bgp-state/data.json?resource=2001:67c:2e8::/48The API returns JSON data. Depending on the prefix and the current information available, the response may contain origin information, announcement status, routing observations, and timestamps.
The result is a public routing snapshot. It may change over time, and different monitoring systems may display different information because they use different route collectors and update schedules.
How to Use the RIPEstat API
A basic request can be made with curl:
curl "https://stat.ripe.net/data/bgp-state/data.json?resource=193.0.0.0/21"On Windows PowerShell, use:
Invoke-RestMethod `
-Uri "https://stat.ripe.net/data/bgp-state/data.json?resource=193.0.0.0/21"When an application accepts a prefix from a user, the value should be URL-encoded before it is added to the API request. This is important because IPv4 and IPv6 prefixes contain characters such as / and :.
A simple JavaScript request looks like this:
const prefix = "193.0.0.0/21";
const url =
"https://stat.ripe.net/data/bgp-state/data.json?resource=" +
encodeURIComponent(prefix);
fetch(url)
.then(response => response.json())
.then(result => {
console.log(result);
});The API response should be treated as public routing data rather than a permanent record. If you use it for an incident report, transfer review, or migration checklist, record the query time.
Step-by-Step Origin ASN Lookup Tutorial
The following process can be used by a beginner to check the origin ASN of a public prefix.
Step 1: Enter the Prefix in CIDR Format
Start with the complete IPv4 or IPv6 prefix, such as:
193.0.0.0/21or:
2001:67c:2e8::/48Do not enter only one individual IP address if you want to investigate the entire allocation. A single address may return information about a larger block but may not clearly identify the exact range you want to review.
Step 2: Check Whether the Prefix Is Announced
Review the BGP state result and look for an announced or visible status. If the prefix is not announced, an origin ASN may not be available.
A prefix may not be announced because it is new, reserved, used privately, withdrawn, or waiting for deployment. Lack of visibility does not automatically mean that the resource is invalid.
Step 3: Record the Origin ASN
Write down every origin ASN returned by the tool. If only one ASN is shown, compare it with the expected network design. If several ASNs appear, determine whether the multiple origins are intentional.
Also record the lookup date and the data source. Routing information changes, so a result without a timestamp is difficult to interpret later.
Step 4: Compare the Origin With Registry Data
Check the relevant RIR or registry record. Confirm whether the organisation, sponsoring provider, and resource status are consistent with the prefix owner or supplier.
The organisation listed in the registry does not always have to match the origin ASN, but the relationship should be explainable.
Step 5: Check RPKI and IRR Data
Review the RPKI status and the relevant IRR route object. A Valid RPKI result and matching route object provide stronger evidence that the origin is expected.
If the origin conflicts with RPKI or IRR data, pause the deployment and investigate before announcing the route.
How to Read the Lookup Result
The most important field is the origin ASN. Record it together with the prefix and the time of the lookup.
The announced status tells you whether the API currently sees an active BGP announcement. If the prefix is not announced, the tool may not return an origin ASN. This does not necessarily mean that the prefix cannot be used.
If more than one origin ASN appears, do not immediately assume that the data is incorrect. Many networks intentionally use multiple origins for redundancy, anycast, multi-site services, traffic engineering, or controlled migrations.
The result should be compared with the expected deployment plan. If the plan expects one origin but the public data shows several, ask the network provider or resource holder to explain the difference.
How to Find an Origin ASN with Other BGP Tools
RIPEstat is useful, but it is not the only public source. BGP.tools can show announced prefixes, origin information, AS paths, and routing relationships.
Hurricane Electric’s BGP Toolkit also provides information about prefixes and autonomous systems. Route collectors and looking glasses can provide additional observations from different networks.
Different tools may not return exactly the same result. They may use different collectors, locations, update times, and filtering policies. One system may see a route that another has not yet observed.
For important decisions, compare several sources. This is especially useful during an IPv4 transfer, a BGP migration, a provider change, or an outage investigation.
Why Can a Prefix Have Multiple Origin ASNs?
Multiple origin ASNs can be intentional. A company may announce the same prefix from different data centres to improve resilience. An anycast service may announce the prefix from many geographic locations. During a migration, both the old and new ASN may be visible for a limited period.
Multiple origins can also result from a configuration mistake. An old provider may continue announcing a route after a migration, or an engineer may configure the prefix on the wrong router.
In some cases, an unexpected origin may represent a route hijack or route leak. The correct response is to compare the observed origins with the documented routing plan and check whether the corresponding RPKI records authorize the announcements.
A multiple-origin result is therefore a signal for investigation, not an automatic conclusion.
Origin ASN and RPKI
RPKI helps validate whether an origin ASN is authorized to announce an IP prefix. The resource holder publishes a Route Origin Authorization that identifies the expected ASN and the allowed prefix length.
If the BGP origin matches the ROA, the route can be classified as Valid. If the origin does not match, or if the route is more specific than allowed, the route may become Invalid. If no applicable ROA exists, the result is generally Not Found.
This is why an origin ASN lookup should be combined with RPKI validation. Knowing that AS64500 is announcing a prefix does not tell you whether that ASN is authorised to do so.
You can continue reading with:
- What Is RPKI? A Beginner’s Guide to Secure BGP Routing
- What Is a ROA in RPKI?
- RPKI Valid, Invalid and Not Found Explained
Origin ASN and IRR Route Objects
An Internet Routing Registry, or IRR, stores routing policy information used by many network operators when building prefix filters.
An IRR route object describes which ASN is expected to originate a prefix. If the route object says that AS64500 should originate a prefix but BGP shows AS64510, the difference should be investigated.
The IRR object may be outdated, the BGP announcement may be incorrect, or the network may be in the middle of a controlled migration.
IRR data and RPKI data are separate. An IRR route object does not replace a ROA, and a Valid RPKI result does not automatically create an IRR route object. Many networks use both systems because they provide different types of routing information.
When Should You Check the Origin ASN?
Check the origin ASN before accepting a new IPv4 or IPv6 prefix, especially when the resource comes from a third party. The result can help confirm whether the route matches the provider’s explanation.
Check it again before and after an ASN migration. The old origin should disappear when the migration is complete, and the new origin should become visible according to the planned schedule.
Origin checks are also useful after an IPv4 transfer, provider change, data-centre move, or BGP policy update. A scheduled monitoring check can reveal unexpected changes before customers report an outage.
For ongoing operations, automated BGP monitoring is more useful than occasional manual lookups. Alerts can identify a new origin, a withdrawn route, an unexpected path change, or a change from Valid to Invalid RPKI status.
Limitations of Public Origin Lookups
Public BGP data is valuable, but it has limitations. It represents observations from selected route collectors and monitoring systems rather than every router on the Internet.
A route may be visible from one network and absent from another. A new announcement may not have reached every collector. A route may also be filtered by prefix length, provider policy, or regional routing rules.
The origin ASN returned by a lookup does not prove legal ownership of the prefix. It does not confirm that the resource can be transferred, leased, or used for a specific service. It also does not prove that the prefix has a clean operational reputation.
For a complete review, combine origin data with registry records, RPKI, IRR information, BGP history, abuse contacts, reputation checks, and contractual documentation.
Frequently Asked Questions
Is the origin ASN the owner of the IP prefix?
Not necessarily. The origin ASN is the network currently announcing the prefix in BGP. The registered holder may use another organisation or provider to announce the resource.
Can one prefix have two origin ASNs?
Yes. Multiple origins may be used for anycast, redundancy, migration, or traffic engineering. They can also indicate a configuration error or an unauthorised announcement.
How often does an origin ASN change?
There is no fixed schedule. It may change during an ASN migration, provider change, IPv4 transfer, data-centre move, or routing redesign. A stable network may keep the same origin for years.
Does a different origin ASN always mean a hijack?
No. It may be intentional or caused by a normal migration. However, an unexpected origin should be investigated, especially when it conflicts with registry, IRR, or RPKI data.
Does an origin ASN lookup require an API key?
Many public tools, including RIPEstat, provide basic routing data without an API key. Usage limits and service availability may change, so applications should handle errors and avoid excessive requests.
Is origin ASN information available for IPv6?
Yes. BGP origin information can be checked for IPv6 prefixes in the same general way as IPv4 prefixes. The prefix must be entered in valid IPv6 CIDR notation.
Conclusion
The origin ASN identifies the autonomous system currently observed as the source of a BGP announcement for an IP prefix. It is an important piece of information for troubleshooting, migration planning, IPv4 transfers, IPv6 deployment, RPKI validation, and route monitoring.
You can find the origin ASN through RIPEstat, BGP.tools, Hurricane Electric, route collectors, or other public routing services. A basic lookup should record the prefix, announcement status, origin ASN, observation time, and any additional origin information.
The result should never be read in isolation. Compare the origin ASN with the registry organisation, expected routing plan, IRR route object, and RPKI authorization. If the data does not agree, determine whether the difference is caused by a planned migration, an outdated record, a configuration error, or an unauthorised announcement.
For a broader technical review, use the IP Resource Readiness Checker. It can help bring registry, origin, route-object, RPKI, and BGP visibility signals together for a public IPv4 or IPv6 prefix.