October 18, 2026
·
7 minutes read
Enter your AS number and see whether your prefixes can be diverted to a scrubbing centre during a DDoS attack, what is wrong with your AS-SET and who else has put your AS into theirs. Step-by-step fixes for all five RIRs, ten languages, no account.
We are releasing a free tool that shows a network operator or data centre, from nothing more than an AS number, whether its prefixes are ready to be diverted to a scrubbing centre during a DDoS attack — and walks it through every fix in its own registry. It also checks the hygiene of the AS-SET that upstreams use to filter your routes. It runs in ten languages and is open source.
Open the scrubbing centre readiness test · Source code on GitHub
We have just returned from PLNOG 2026 in Kraków (15–16 October). After our talk there, we added a few more checks to the tool, inspired by talks given at other NOGs that we watched during the conference. Thank you to their authors — their talks made this knowledge public. Every source is listed at the end of this post, with a link to the presentation and the author’s name.
A problem that surfaces only during an attack
When an attack is bigger than your links, traffic is diverted to a scrubbing centre: /24 prefixes (IPv6: /48) carved out of your larger blocks are announced from there, the traffic is cleaned and sent back. For that to work, the registries must be ready beforehand. The ROA has to allow those /24s, a route object has to exist in the RIR database, the AS-SET has to contain the right networks and, if the address space belongs to someone else, the scrubbing centre will ask for an LOA.
The most common gap we see is a ROA created exactly on the aggregate, without maxLength. Everything works while only the aggregate is announced. During an attack every /24 split out of it becomes RPKI-invalid and validating networks drop it. The fix takes minutes; reaching the filters takes hours, sometimes two days. RFC 9319 says it plainly: a ROA for a DDoS mitigation service has to exist before the attack.
What to check — and what to fix
| What the test checks | What you get to fix it | |
|---|---|---|
| 🛡️ | ROAs — will every /24 (/48) split out of your blocks be RPKI-valid? | ready-to-paste ROAs: one per /24 (RFC 9319) or maxLength on the aggregate |
| 📒 | Route objects — are they in a RIR database, not only in RADB or another registry operators do not accept? Any stale objects with another origin? | ready route objects in RPSL; which objects to remove |
| 📝 | LOA — does the address space belong to another organisation, or is it PA space from a LIR? | an LOA draft listing the prefixes and their holders |
| 🧹 | AS-SET hygiene — how many ASes does your set really pull in? Are IXP or peer lists hiding inside? Members that left? | what to trim, and the rule of thumb: would you re-advertise this in BGP? |
| 🕵️ | Who includes your AS — which networks with no BGP relationship to you have put your AS into their AS-SETs? | the list of sets to review, whom to ask for removal, ASPA and monitoring |
| 🔗 | ASPA, abuse contact, PeeringDB, upstreams — including the scrubbing centre’s AS, if you enter it | the exact place to set each of them in your registry |
| 📏 | Prefix length — anything longer than /24 or /48 that will be filtered? | which prefixes to replace |
| 🧾 | What cannot be checked from outside — LOA wording, tunnel and MSS, propagation time, announcement and withdrawal, routing loops, customer filtering, dry run | a checklist to go through with your scrubbing centre |
Everything ends in a verdict — ✅ ready, ⚠️ ready with reservations, ❌ not ready — and an 🔧 action plan in the order worth following, with instructions for your own registry.
Your AS-SET is a security object, not documentation
Upstreams — and scrubbing centres — build the filter for routes they accept from you out of your AS-SET. RPKI ROAs validate only the origin AS; the transit part of the path is protected by these registry-based filters. That makes the AS-SET a security object. The tool checks it from three angles.
Size. If your AS-SET expands to thousands of networks, a route leak from one of your customers passes your upstream’s filter. We compare the expanded set with the customers actually visible in BGP and flag sets that are many times bigger, deeply nested or dominated by a single member set.
Content. A set used for filtering should list your customer cone and nothing else. IXP member lists and peer lists inside it make it explode. The rule of thumb is simple: would you re-advertise this in BGP? If not, it does not belong in your AS-SET. The tool also lists members that are no longer visible as your customers.
Who includes you. Anyone can add your AS to their AS-SET. With a spoofed origin the announcement is ROA-valid and passes registry-based transit filters. The tool lists every AS-SET that contains your AS and flags those of networks with no BGP relationship to you, together with what to do: ask for removal, publish ASPA and monitor the registries.
Five registries, ten languages
The steps differ from registry to registry, and the tool knows it. In APNIC one form creates the ROA and the route object together; in LACNIC route objects are generated from ROAs, so a /24 route object needs a ROA per /24; in ARIN the IRR has no maintainer objects and access follows your organisation’s contacts. Instructions cover RIPE NCC, ARIN, APNIC, AFRINIC and LACNIC, each with a link to the registry’s own documentation.
The interface works in Polish, English, German, French, Spanish, Portuguese, Italian, Dutch, Czech and Romanian, in a light and a dark theme.
Run it on your own computer
The tool runs in the browser and has no server: the browser queries public services directly — the RIPE Database, RIPEstat, the RIR registries (RDAP), IRR Explorer and PeeringDB. You can also download it and run it locally: start.bat on Windows, start.sh on Linux and macOS, or Docker. With bgpq4 installed — it is already inside the Docker image — the local version adds prefix lists built from your AS-SETs: prefix counts, a Junos prefix-list and the full list as a file.
The code is published under AGPL-3.0, the content under CC BY-SA 4.0. Instructions for downloading and running it are in the README.
What the tests are based on
Every check follows a published source: IETF RFCs (6811, 9319, 9582, 7454, 6483, 2622 and the ASPA drafts), RIPE NCC documents and the documentation of all five RIRs, MANRS, and the public onboarding requirements of well-known scrubbing centre operators. The AS-SET checks build on talks by Lasse Jarlskov (Telia Company) — „Securing your AS-set” at BalticNOG 2025 and „Prelude to a BGP hijack?” at DKNOG15 — and on „The Scourge of Excessive AS-SETs” by Doug Madory and Job Snijders. The full list, with authors and links, is in the sources section of the README.
When to call us
The tool shows what to fix in the registries. Diversion is only one part of protection: first the attack has to be detected within seconds and filtered at the edge of your own network, and the hand-over to a scrubbing centre needs a procedure agreed in advance. If you would like to go through it with us before the first attack, get in touch.
