Live BGP Data · Multi-ASN · 15 Export Formats

ASN IP Ranges:
Every CIDR Block an AS Announces

Pull every IPv4 and IPv6 prefix a network advertises, merge the ones that sit next to each other, and export straight into iptables, ipset, nginx, Cisco or a dozen other formats. Several AS numbers at once, no signup, no rate-limit wall.

Quick Answer: How Do You Get an ASN's IP Ranges?

Enter one or more AS numbers and this tool returns every CIDR block those networks are announcing in BGP, taken from the RIPE NCC routing dataset. Switch aggregation on and adjacent prefixes merge into larger blocks, which usually cuts the line count substantially. Then export the result in the exact syntax your firewall, web server or router expects.

Presets:

Presets come from each operator’s own published list where one exists — Google’s seven AS numbers are the set it publishes in PeeringDB. Check the holder names in the results before you deploy anything.

Address family
Rule action

Last verified 8 August 2026. Prefix data comes live from the RIPE NCC RIPEstat routing dataset and is cached for six hours per AS number. Aggregation runs in your browser and was verified against a property test proving the merged set covers exactly the same addresses as the input. Nothing you enter is stored.

Robert Harrison, OSINT and Network Utility Expert, explaining how to download ASN IP ranges at TrustMyIP.com
Written & Verified By

Robert Harrison

OSINT & Network Utility Expert

The week BGPView went dark in November 2025 I had three clients whose firewall automation broke overnight. Rebuilding it taught me something I had been sloppy about for years: I had been feeding raw prefix lists straight into iptables. One client's list was 4,800 lines. After merging the adjacent blocks it was 790, covering identical address space, and their rule evaluation time dropped enough to show up in monitoring. Same coverage, one sixth of the rules, and I had been leaving that on the table since forever.

The limitation worth stating plainly: this shows what is announced in BGP right now, as seen by RIPE's route collectors. A network can announce a prefix from a second AS, withdraw one for maintenance, or use a more specific route that never reaches every collector. I have watched a prefix vanish from one dataset and stay visible in another for six hours. Treat the output as strong current evidence, not a legal record of who owns what.

View all articles by Robert Harrison

What Is an ASN IP Range List and When Do You Need One?

Every network on the public internet announces a set of address blocks over BGP, written in CIDR notation. Going from ASN to IP ranges means pulling that set for one AS number: every IPv4 and IPv6 prefix the network is currently advertising to the rest of the world. People also call it an ASN prefix list, an ASN CIDR list, or simply IP ranges by ASN — same thing, different vocabulary depending on whether you came at it from routing or from firewalls.

You reach for one when a single address is not the unit you care about. A scraper rotating through a hosting provider gives you a different IP every few minutes, but the same AS number every time. A cloud partner you want to allowlist does not publish a stable address, but its AS announces a knowable set of blocks. In both cases the AS is the handle you can actually grip.

If you only need to know which network a single address belongs to, our ASN lookup tool answers that in one query. This page is for the other direction: given the network, give me everything.

The short version: paste one or more AS numbers, choose whether to merge adjacent blocks, pick your firewall's syntax, and copy. The prefix data is read from the RIPE NCC routing dataset rather than a repository snapshot. It is near-current rather than instantaneous: the feed can lag by a day, and it deliberately leaves out routes that fewer than ten of RIPE’s full-feed peers can see. Any warning RIPE attaches to a response is shown above the results rather than hidden.

The part most tools skip is what happens to that list before it reaches your firewall, and it is worth understanding.

Why CIDR Aggregation Shrinks Your Firewall Rule Count

Networks rarely announce one tidy block. They announce whatever they were allocated, in whatever order they got it, often as many small consecutive prefixes. A list of 4,800 lines is common for a mid-size hosting provider, and every one of those lines becomes a rule your firewall evaluates.

Aggregation fixes that without changing what is covered. It is the step between a raw dump of BGP prefixes and a list you would actually deploy. Two blocks that sit next to each other become one larger block. A prefix already contained inside a bigger one is dropped, because it was never adding anything. The result covers exactly the same addresses in far fewer lines.

What the merging actually looks like

Input prefixesBecomesWhy
10.0.0.0/25 + 10.0.0.128/2510.0.0.0/24Two halves of the same /24, aligned
10.0.0.0/24 + 10.0.1.0/2410.0.0.0/23Adjacent and aligned on a /23 boundary
10.0.0.0/8 + 10.1.2.0/2410.0.0.0/8The smaller block was already inside
10.0.1.0/24 + 10.0.2.0/24both keptAdjacent but not alignable into one block
1,024 consecutive /2410.0.0.0/14A whole aligned run collapses to one line

How much you save depends entirely on how the network chose to announce its space, so there is no honest general figure to quote. The tool shows the real before and after count for whatever you queried, which is better evidence than any claim on this page.

That fourth row is the one people get wrong. Two blocks touching each other does not automatically mean they can be written as one, because a CIDR block has to start on a boundary that matches its size. The tool handles that correctly: it merges the address ranges first, then rebuilds the smallest set of properly aligned blocks that covers them.

Why the saving is worth having: a shorter list is not just tidier. Fewer rules means faster packet evaluation on a firewall that walks its rules in order, smaller configuration files, faster deployment, and less chance of hitting a platform limit. Windows Firewall in particular caps how many addresses fit in one rule, which is why the netsh output on this page splits into chunks automatically.

Aggregation only helps if the list it starts from is complete, and that is where most people trip.

One Company, Many AS Numbers: The Mistake That Leaves Gaps

Filtering on a single AS number and assuming you have covered an organisation is the most common way these lists fail. Large operators acquire networks, run separate regions, and split corporate infrastructure from cloud infrastructure. Each of those often carries its own AS number.

The clearest evidence is public: an open source project called MSFT-IP-Tracker exists purely to poll more than twenty separate Microsoft AS numbers and publish them as one list. If one AS number were enough, that project would not need to exist.

OrganisationCommonly cited AS numbersWhy more than one
GoogleSeven, including AS15169 and AS396982Published by Google itself in PeeringDB
CloudflareAS13335, AS209242Main network plus a separate edge network
AmazonAS16509, AS14618, AS8987, AS7224Regional and legacy allocations
MicrosoftAS8075 plus twenty or more othersAzure, corporate networks, acquisitions
MetaAS32934, AS63293Platform and a secondary network

Enter several numbers at once and the tool fetches each one, removes duplicate prefixes across all of them, and aggregates the combined set. The panel above the results names the holder of each AS so you can confirm you got what you expected before you paste anything into a firewall.

Verify the list, do not trust the label. The preset buttons are starting points drawn from commonly cited sets, not an authoritative registry of who owns what. AS numbers change hands, and an organisation can announce from a network it does not obviously appear to own. Check the holder names the tool returns, and if the block matters, cross-check it with our WHOIS lookup.

Once you have a list you trust, getting it into your specific platform is the next step.

How to Block or Allow an Entire ASN

The tool writes the syntax for you — iptables, ipset, nftables, nginx, Apache, Cisco IOS and ASA, MikroTik RouterOS, pfSense and OPNsense aliases, Windows netsh, JSON and CSV. But understanding what each platform does with those ASN IP blocks saves you from the two mistakes that cause outages: loading thousands of individual rules, and choosing to block an ASN before checking what else lives in that address space.

Blocking an ASN, in the right order

1 Confirm the AS is the one you mean

Take an offending address from your logs and run it through the ASN lookup first. Blocking the wrong network because two providers share a data center is an expensive afternoon.

2 Allowlist your own integrations first

Payment webhooks, uptime monitors, CI runners and search crawlers frequently sit inside the same cloud AS you are about to block. Write those allow rules before the deny rule, not after.

3 Use a set, not thousands of rules

On Linux that means ipset or an nftables set. A hash set matches in constant time no matter how many entries it holds. Thousands of individual iptables rules are walked in order and will show up in your latency graphs.

4 Stage it, then schedule the refresh

Apply to one host and watch the logs before you roll it out. Then automate the refresh, because the prefix list changes constantly and a stale list quietly stops matching new blocks.

Linux: ipset is the right tool

# Create a hash set sized for a large prefix list

ipset create asn-block hash:net maxelem 200000

# Load the file this page generated

ipset restore < asn-block.txt

# One rule references the whole set

iptables -I INPUT -m set --match-set asn-block src -j DROP

# Persist on Debian and Ubuntu

ipset save > /etc/ipset.conf

nftables: the modern equivalent

# The nftables export defines the set and the rule together

nft -f asn-block.nft

# Check what landed

nft list set inet filter asn_block_v4

For web-server level filtering the nginx and Apache exports drop straight into a server block or a .htaccess file. That is slower than filtering at the firewall, because the request has already reached your application server, but it is the only option on shared hosting.

If you are filtering to stop abusive traffic rather than a specific network, our IP blacklist and DNSBL checker and IP fraud score tool often identify the problem more precisely than an AS-wide block.

Keeping the List Fresh: Automation That Only Wakes You When It Matters

An ASN prefix list is not static. Networks add allocations, withdraw routes during maintenance, and reconfigure constantly. A list exported six months ago has quietly stopped matching whatever the network added since.

The pattern that works is a scheduled fetch that diffs against the previous run and stays silent unless something changed. Noisy automation gets muted, and muted automation is the same as no automation.

#!/bin/sh

# Refresh an ipset from RIPEstat and report only on change

ASN=15169

NEW=/tmp/as$ASN.new

OLD=/var/lib/asnlists/as$ASN.txt

curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS$ASN" \

| jq -r '.data.prefixes[].prefix' | sort > "$NEW"

if [ -s "$NEW" ] && ! cmp -s "$NEW" "$OLD"; then

diff "$OLD" "$NEW" | mail -s "AS$ASN prefixes changed" you@example.com

cp "$NEW" "$OLD"

ipset flush asn-block

while read -r p; do ipset add asn-block "$p"; done < "$NEW"

fi

Two details in that script matter more than they look. The -s "$NEW" test refuses to replace a good list with an empty one when the API has a bad day, which is the failure mode that takes a firewall down. And flushing before reloading removes prefixes the network has withdrawn, which a plain append would leave behind forever.

On polling politely: the RIPEstat documentation sets no cap on request volume but asks you to register a sourceapp identifier if you regularly exceed a thousand calls a day, and limits each IP to eight concurrent requests. A daily cron for a handful of AS numbers sits comfortably inside that. This page caches every AS for six hours for the same reason.

Automation assumes the data is right in the first place, which deserves its own section.

Where This Data Comes From, and What It Cannot Tell You

The BGP prefixes come from the RIPE NCC routing dataset, which aggregates feeds from route collectors around the world. It is the same public source that operators, researchers and most of the tools in this space rely on. There is no proprietary database here and no key required.

Announced, not allocated

This list shows what a network is advertising right now, not everything it has been allocated. An organisation can hold registry space it never announces, and that space carries no traffic and does not need a firewall rule. If you want the registry side of the picture, that is a WHOIS question rather than a routing question.

A snapshot from collectors, not ground truth

Route collectors see what their peers show them. A more specific route can exist without reaching every collector, a network can announce the same prefix from a second AS, and a withdrawal takes time to propagate. In practice the picture is very good and occasionally lags by hours.

Low-visibility routes are filtered out

RIPE excludes routes that fewer than ten of its full-feed peers can see. That is a sensible default, because a route only one collector observes is often a transient leak rather than a real announcement. It does mean the list is not exhaustive: a genuinely obscure prefix can be missing. For firewall work that is almost always what you want. For forensic work, know that the filter exists.

Announcing is not owning

A prefix appearing under an AS means that AS is announcing it, which is usually but not always the same as holding it. Address space is leased, transferred, and occasionally hijacked. If the distinction has consequences, check the RPKI validity and the registry record rather than assuming.

What is genuinely computed here: the prefix list is fetched, not guessed. The merge is arithmetic on address ranges and was verified against a property test proving the aggregated set covers exactly the same addresses as the input. The address count is the sum of block sizes. Nothing on this page is a stored default.

Five Mistakes That Turn an ASN Block Into an Outage

Every one of these has taken down something real. They are ordered by how often they happen rather than how bad they are.

1. Blocking a cloud provider without checking who else lives there

AS16509 is Amazon. So is a large share of the internet's webhooks, monitoring, and API integrations. Blocking it to stop one scraper takes out your payment notifications at the same time. Allowlist first.

2. Loading the list as individual firewall rules

A few thousand sequential rules on a busy host is a measurable latency cost. Use a set. The ipset and nftables exports on this page exist for exactly this reason.

3. Assuming one AS number covers the organisation

Covered above, and worth repeating because it fails silently. You block one AS, the traffic keeps arriving from another, and you conclude the block did not work.

4. Never refreshing

A list is correct on the day you exported it. Networks add blocks. Six months later you are filtering a network that has moved on.

5. Blocking outbound as well as inbound by accident

A rule in the wrong chain stops your own servers reaching that provider. If you block a cloud AS in OUTPUT as well as INPUT, your own API calls to that provider stop working, and the symptom looks nothing like a firewall problem.

A safer sequence: generate the list, apply it on one host in a logging-only mode if your platform supports it, watch for a day, then enforce. On Linux you can swap -j DROP for -j LOG to see exactly what the rule would have caught before it catches anything.

For the questions that come up most often once people start using these lists, see below.

ASN IP Ranges: Frequently Asked Questions

What is an ASN IP range list?

Every network on the public internet announces a set of IP blocks over BGP, written in CIDR notation. An ASN IP range list is that set for one AS number: every IPv4 and IPv6 prefix the network is currently advertising. It is what you need when you want to allow, block, or simply recognise all the traffic belonging to a particular operator.

How do I get every IP range for an ASN?

Enter the AS number above and the tool queries the RIPE NCC routing dataset for every prefix that AS currently announces, then hands you the list in whatever format your firewall expects. From a terminal you can do the same with whois -h whois.radb.net -- -i origin AS15169, though that returns registry objects rather than what is actually being announced right now.

What does aggregation do to the list?

It merges prefixes that sit next to each other and removes any that are already covered by a larger block, then rebuilds the smallest set of CIDR blocks that covers exactly the same addresses. Nothing is added and nothing is lost. On a network that announces many small consecutive blocks the list often shrinks by half or more, which matters because every line becomes a firewall rule.

Why does one company have several AS numbers?

Large operators acquire networks, run separate regions, or separate their corporate and cloud infrastructure. Microsoft announces from more than twenty AS numbers, and Google, Amazon and Cloudflare each use several. Filtering on one of them and assuming you have covered the organisation is a common and costly mistake, which is why this tool accepts several at once.

Is blocking a whole ASN safe?

It is effective and blunt. Blocking a large cloud provider also blocks the payment webhooks, API partners, uptime monitors and search crawlers that share that address space. Allowlist your known integrations first, apply the block on a staging host, and watch your logs before you push it to production.

How fresh is this data, and how often does the list change?

The routing feed is near-current rather than instantaneous and can lag by around a day, and RIPE filters out routes that fewer than ten of its full-feed peers can see. Any warning RIPE attaches is shown above the results. The underlying lists change constantly. Networks add blocks, withdraw routes and reconfigure daily. A list you exported six months ago is already wrong. If it feeds a production firewall rule, refresh it at least weekly, and the automation section on this page shows a cron pattern that only alerts you when something actually changed.

What replaced BGPView for this?

Nothing single-handedly. BGPView shut down on 26 November 2025 and took its free API with it. Operators moved to RIPE NCC RIPEstat for prefix data, Team Cymru for fast bulk IP to ASN mapping, and various GitHub repositories that publish daily snapshots. This page wraps the same public RIPE data so you do not have to stitch endpoints together yourself.

Does the list include prefixes the AS owns but does not announce?

No, and that is deliberate. This shows what is being advertised in BGP right now, because that is what actually carries traffic and what your firewall needs to match. Registry allocations that are held but not announced are a separate question, answered by a WHOIS lookup rather than a routing lookup.

Related Network Intelligence Tools

Continue the investigation with the rest of the TrustMyIP toolkit.

Get Every Prefix, Merged and Ready
In the Syntax Your Firewall Speaks

Several AS numbers at once, adjacent blocks merged, fifteen export formats. Free, no account, no rate-limit wall.