Why AS-SETs still matter in BGP
An AS-SET is an Internet Routing Registry (IRR) object that groups related networks together. It is not to be confused with the BGP AS_SET path attribute, which was recently deprecated in RFC 9774. Network operators have historically used AS-SETs to bundle downstream customers — for example, Cloudflare uses AS13335:AS-CLOUDFLARE to collect its own ASNs and downstream Bring-Your-Own-IP (BYOIP) customer networks, so peers know which prefixes to accept.
In practice, AS-SETs are currently the only way for an operator to attest which networks they provide service for. That system is entirely trust-based, which makes it best-effort at best. The eventual replacement, RPKI-based ASPA (Autonomous System Provider Authorization), is still working its way through the IETF, so AS-SETs remain essential.
Given that reliance, operators need visibility into valid and invalid AS-SET memberships. Cloudflare Radar now offers a public listing on each ASN's routing page to expose that data.
How AS-SETs feed route filters
AS-SETs pair with Routing Policy Specification Language (RPSL) to describe how an ASN accepts and propagates routes. Most often they are used to express which downstream networks a provider will announce on behalf of its customers. Cloudflare publishes AS13335:AS-CLOUDFLARE on PeeringDB, and transit providers build prefix filters from it when new service is turned up.
Because BGP prefixes are also created in IRR registries via route or route6 objects, peers and providers can determine exactly which prefixes to accept or reject. Tools like bgpq4 generate prefix lists from AS-SETs and IRR databases. For example, to build a Juniper IPv4 prefix-list for what AS13335 may legitimately propagate for Cloudflare and its customers:
% bgpq4 -4Jl CLOUDFLARE-PREFIXES -m24 AS13335:AS-CLOUDFLARE | head -n 10
policy-options {
replace:
prefix-list CLOUDFLARE-PREFIXES {
1.0.0.0/24;
1.0.4.0/22;
1.1.1.0/24;
1.1.2.0/24;
1.178.32.0/19;
1.178.32.0/20;
1.178.48.0/20;
That prefix list can then be applied in an eBGP import policy, ensuring AS13335 can only announce its own prefixes and those of its customers.
Accurate AS-SETs stop route leaks
A concrete example shows how accuracy matters. Suppose AS64502 has two providers, AS64501 and AS64503. If AS64502 misconfigures its export policy toward AS64503 and sends all routes — including those learned from AS64501 — that is a classic Type 1 hairpin route leak.

AS64503 can stop that leak if its import policy was generated from IRR data (AS-SETs and route objects). Such a policy only accepts prefixes originating from the AS Cone of AS64502, its customer. Without filtering, the leak would propagate widely; with it, the bad routes are rejected at the provider edge. The catch is that this strategy only works when the AS-SET data is accurate.
Keeping an eye on AS-SET memberships
AS-SETs are not only used for downstream customers. They can also represent peers, transits, or IXP participations. For instance, the Tier-1 network Telecom Italia / Sparkle (AS6762) appears in 76 AS-SETs directly, most of which appear to represent peer or transit groupings based on their names.

Defining AS-SETs that include peers or upstreams is fine — as long as those objects are not submitted upstream for customer-to-provider session filtering. They can be useful for expressing RPSL policies. But some AS-SETs in the AS6762 list appear to attest customer relationships that cannot be valid, such as AS-10099:
% whois -h rr.ntt.net AS-10099 | grep "descr"
descr: CUHK Customer
Since AS6762 is transit-free, any claimed customer membership is obviously incorrect. Such entries are prime candidates for cleanup. Operators are usually willing to fix invalid AS-SETs when asked. Each stale or wrong membership is a latent risk for bigger route leak propagation during an incident.
What Cloudflare Radar exposes per ASN
Cloudflare Radar now adds IRR AS-SET data to its routing section, accessible by website or API. Visiting an ASN's routing page (e.g., https://radar.cloudflare.com/routing/as13335#irr-as-sets) shows all AS-SETs an AS is a member of, whether directly or indirectly through other AS-SETs.
The raw IRR data only tells you which ASNs and AS-SETs are members. Radar enriches the table with additional context:
Inferred ASN— the ASN likely responsible for the AS-SET, matched against PeeringDB when possible, otherwise inferred from the AS-SET name.IRR Sources— the registries containing the AS-SET:AFRINIC,APNIC,ARIN,LACNIC,RIPE,RADB,ALTDB,NTTCOM, andTC.AS MembersandAS-SET members— counts of each member type.AS Cone— the unique ASNs included directly or indirectly.Upstreams— the count of distinct AS-SETs that include the given AS-SET.
The table is searchable by AS-SET name or ASN, with a toggle to isolate direct or indirect memberships.

Radar also provides a tree view showing how an AS-SET includes a given ASN — for example, how AS-DELTA indirectly reaches AS6762 through seven intermediate AS-SETs. That view can be copied or downloaded as text for sharing.

This feature was built using the same publicly available Radar API used for other Radar pages. The API also opens possibilities for external developers to build additional visualizations, such as full AS-SET trees.
The path ahead: RFC 9234, ASPA, and hierarchical AS-SETs
Even with better monitoring tools, AS-SET mistakes will keep happening. The community still needs to push adoption of RFC 9234, which embeds BGP roles and an Only-To-Customer (OTC) attribute directly into the protocol, allowing route leaks to be detected in-line. ASPA will eventually provide an authoritative source for provider relationships, but it is not ready yet.
Meanwhile, operators who manage AS-SETs should prefer hierarchical objects like AS13335:AS-CLOUDFLARE over flat ones like AS-CLOUDFLARE. Only the proper maintainer of AS13335 can create the hierarchical form, while anyone could register the flat name in an IRR database. Hierarchical AS-SETs therefore offer a degree of ownership protection and reduce the risk of poisoning routing data.
Keeping AS-SET memberships clean is tedious but worthwhile — accurate data reduces the blast radius of BGP incidents like route leaks. Every cleanup effort, however small, makes the Internet's routing system more resilient.



