What Is an ASN and How Do You Get One?
An Autonomous System Number (ASN) is a globally unique number assigned to a network that operates under a single, clearly defined routing policy and exchanges routing information with other networks using BGP. You need one when your network must present a consistent identity to the global routing table — most commonly for multi-homing, peering, or running your own address space. You request it from the Regional Internet Registry (RIR) that covers your region; for Africa, that is AFRINIC, which is responsible for the allocation and management of IPv4, IPv6, and ASNs across the continent.
ASN vs. IP address: what each one does
An IP address identifies an interface or a host. An ASN identifies a network — the whole routing domain behind it. The two work together but answer different questions:
| Resource | Identifies | Used by |
|---|---|---|
| IP address (IPv4/IPv6) | A host or interface | Endpoints sending and receiving traffic |
| ASN | A routing domain with one policy | BGP speakers announcing routes to neighbours |
A useful way to think about it: the IP prefix tells the world where your addresses are, and the ASN tells the world who is announcing them. When you announce a prefix to a transit provider or an internet exchange, the route carries both your prefix and your origin ASN.
When does a network actually need its own ASN?
Not every organisation needs one. You generally do not need an ASN if you simply connect to a single upstream provider and use addresses that provider assigns to you — your provider's ASN covers your traffic.
You do need your own ASN when:
- You multi-home. You connect to two or more upstream providers or exchanges and want traffic to fail over between them. Without your own ASN, you cannot announce a consistent prefix from multiple paths.
- You peer. You want to exchange traffic directly with other networks at an internet exchange point, which requires a BGP session identified by your ASN.
- You run your own address space. If you hold provider-independent addresses and want to announce them yourself, you need an ASN as the origin.
- You want a stable routing identity. Your ASN stays with you if you change transit providers, so your routing presence does not depend on any single carrier.
How the request process works
The exact forms and portal differ by registry, but the logic is the same everywhere. The general sequence is:
- Confirm you are in the right region. AFRINIC serves the African region. If your network is elsewhere, you apply to the RIR covering that area instead.
- Check eligibility. Registries expect you to be an organisation operating a network, not an individual reselling connectivity. You will typically need to show that you are multi-homed or have a concrete plan to become multi-homed.
- Prepare justification. You explain why you need the ASN: your upstream providers, your peering plans, and the routing policy you intend to run. This is the part most first-time applicants underestimate.
- Submit the request through the registry's member or resource request process, along with the supporting documentation the registry asks for.
- Receive the assignment and register it. Once assigned, the ASN is recorded in the registry's public database, and you use it to configure BGP with your neighbours.
AFRINIC's own service pages group this under registry services, alongside IPv6 resource management and the member registration portal, so the ASN request sits within the same membership and resource-management workflow as addresses.
After you get it: what actually matters
Getting the number is the easy part. The ongoing work is what determines whether it is useful:
- Keep your registration data current. Your ASN record, contacts, and associated address objects should reflect reality. Stale records cause failed peering requests and confusion in routing databases.
- Appear in routing databases. Networks commonly list their ASN, prefixes, and peering details in PeeringDB so that potential peers can find them. PeeringDB's own update notes describe ongoing work such as improved ASN comparison and expanded API query export, which reflects how central ASN records are to peering decisions.
- Understand transfer and policy rules. ASNs can be transferred under registry policy, but the conditions are set by the RIR and can change through the policy development process. If you are acquiring or disposing of one, check the current policy rather than assuming.
- Plan for the routing policy you declared. If you told the registry you would multi-home, you should actually do it. Registries can review whether assignments are being used as justified.
Common pitfalls
- Applying without a real multi-homing plan. "I might want it later" is usually not sufficient justification.
- Confusing an ASN with an IP allocation. They are separate resources with separate requests and separate justification.
- Forgetting the public database. Your ASN is visible to the global routing community; inaccurate entries create operational problems for you and your peers.
- Assuming regional rules are identical. Each RIR has its own policies and procedures. AFRINIC's apply to Africa; the same concept elsewhere is handled by a different registry with different requirements.
If you are in the AFRINIC region and want to move forward, the practical starting point is AFRINIC's registry services and membership pages, where the resource request process and the member registration portal are documented.