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 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.
Reading the global routing table…
Large networks announce thousands of prefixes, so give it a moment
Output format
—
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 & 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 HarrisonEvery 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.
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.
| Input prefixes | Becomes | Why |
|---|---|---|
10.0.0.0/25 + 10.0.0.128/25 | 10.0.0.0/24 | Two halves of the same /24, aligned |
10.0.0.0/24 + 10.0.1.0/24 | 10.0.0.0/23 | Adjacent and aligned on a /23 boundary |
10.0.0.0/8 + 10.1.2.0/24 | 10.0.0.0/8 | The smaller block was already inside |
10.0.1.0/24 + 10.0.2.0/24 | both kept | Adjacent but not alignable into one block |
1,024 consecutive /24 | 10.0.0.0/14 | A 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.
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.
| Organisation | Commonly cited AS numbers | Why more than one |
|---|---|---|
| Seven, including AS15169 and AS396982 | Published by Google itself in PeeringDB | |
| Cloudflare | AS13335, AS209242 | Main network plus a separate edge network |
| Amazon | AS16509, AS14618, AS8987, AS7224 | Regional and legacy allocations |
| Microsoft | AS8075 plus twenty or more others | Azure, corporate networks, acquisitions |
| Meta | AS32934, AS63293 | Platform 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.
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.
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.
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.
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.
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.
# 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
# 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.
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.
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.
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.
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.
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.
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.
Every one of these has taken down something real. They are ordered by how often they happen rather than how bad they are.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Continue the investigation with the rest of the TrustMyIP toolkit.
Several AS numbers at once, adjacent blocks merged, fifteen export formats. Free, no account, no rate-limit wall.