ASN and BGP Requirements for Growing WISPs

When a growing WISP actually needs an ASN

An ASN is not a status symbol. It is an operational commitment: you become responsible for announcing routes to the Internet correctly, forever. The triggers that justify it are concrete:

• You are adding a second upstream provider. Multihoming two transit circuits with one default route each gives you crude failover at best. BGP with your own ASN gives you deterministic, automatic failover and the ability to prefer one path over another.
• You need provider-independent (PI) IP space. Addresses assigned by a single provider go back when you leave. PI space is yours, announced under your ASN, and portable between providers — no renumbering customers when you switch transit.
• You want to peer at an exchange or directly with content networks. Settlement-free peering requires an ASN and BGP sessions you control.
• A carrier or data center requires it. Many colocation cross-connects, DDoS-scrubbing services, and wholesale transit products assume you bring your own ASN.

If none of these apply yet — one provider, one tower, provider-assigned IPs — static routing is still the right answer. Revisit when a second tower or second circuit enters the plan.

Requesting an ASN from your regional registry

ASNs are issued by the Regional Internet Registry (RIR) for your geography — ARIN in North America, RIPE NCC in Europe and the Middle East, APNIC in Asia-Pacific, LACNIC in Latin America, and AFRINIC in Africa. The process is similar everywhere:

• Establish an account with the RIR and pay the registration and annual maintenance fees.
• Document that you are multihomed — or have an approved, dated plan to be — typically by naming the two distinct upstream ASNs you will connect to.
• Provide legal entity details, points of contact (admin, technical, abuse), and sign the registry's service agreement.

Approval is usually measured in days to a few weeks once the paperwork is clean. You will receive a 16-bit or 32-bit ASN; for practical purposes they are interchangeable, since every modern router and transit provider supports 4-byte ASNs.

Keep the registry contact records accurate. Abuse contacts that bounce email are a fast way to end up on blocklists, and stale technical contacts slow down trouble tickets when a route leak or hijack involves your prefixes.

Getting IP address space

An ASN without address space announces nothing. You have two sources:

Provider-assigned (PA) space

Your upstream lends you a block and announces it as part of their aggregate. This is fine for getting started, but it is not portable — change providers and you renumber every customer. Use PA space only as a bridge.

Provider-independent (PI) space

Requested from the RIR against a documented need, or acquired on the transfer market. IPv4 is exhausted at the registries, so expect modest initial allocations, justification paperwork, and — if you buy on the transfer market — meaningful cost per address. IPv6, by contrast, is effectively free: request a large allocation from day one and run dual-stack so your IPv4 needs shrink over time.

How much space do you need? That depends on customers per tower, public-versus-CGNAT policy, and growth. Size it deliberately rather than asking for the maximum you can justify: our article on how many public IPs a WISP tower needs walks through the per-tower math, and the IP block size calculator turns customer counts into a concrete subnet size. The IP addressing solution covers the procurement side of PI blocks.

Whatever you receive, register route objects in the RIR database and create ROAs (Route Origin Authorizations) in the RPKI so that your ASN is the authorized origin of your prefixes. Increasingly, networks that skip this step find their announcements deprioritized or dropped by large providers that filter on RPKI validity.

Building a routing policy

BGP without policy is a loaded router. Before the first session comes up, write down — literally, in a document — what you will announce and what you will accept:

Outbound policy (what you announce)

• Announce only your own PI prefixes, via an explicit prefix list. Never leak provider A's routes to provider B.
• Announce aggregates, not de-aggregated specifics, unless you are deliberately traffic-engineering with a longer prefix plus a covering aggregate.
• Tag routes with BGP communities your providers honor (prepend requests, blackhole triggers) so you can steer traffic without opening a ticket.

Inbound policy (what you accept)

• Reject your own prefixes, bogons, and private ASNs inbound.
• Set a max-prefix limit on every session so a misbehaving peer cannot fill your routing table.
• Default to accepting a full table or a default route from each transit provider, depending on router memory and how much path control you want.

Two routers, one per upstream, each with the full policy applied identically, is the baseline. iBGP between them keeps the network coherent when one edge fails.

Peering and transit for redundancy

The whole point of the exercise is surviving a provider failure. A resilient design has three ingredients:

• Two diverse transit providers terminating on different physical paths — different conduits, different PoPs, ideally different directions off the tower or core site. A shared duct is a shared failure. The redundant backhaul and IP transit solutions cover sourcing diverse circuits that genuinely do not overlap.
• Tuned failover behavior. Prepend on the backup provider so it is cold-standby, or split traffic deliberately with communities. The mechanics of path selection, prepends and route maps are covered in route failover between two backhaul providers.
• Tested failure, not assumed failure. Schedule a maintenance window and actually shut down the primary session. Watch convergence, verify inbound traffic shifts, and time how long customers see disruption.

Capacity matters as much as path diversity: if one circuit cannot carry peak load alone, failover keeps you online but slow. The backhaul capacity calculator helps size each circuit so that a single survivor still meets demand.

Common mistakes to avoid

• Announcing before the ROA exists. RPKI-invalid announcements are increasingly filtered; create ROAs first, announce second.
• No outbound prefix list. One typo and you are a transit path between your two providers, melting your routers and your reputation in the same afternoon.
• Skipping max-prefix limits. A full-table leak from a peer will exhaust router memory and take your edge down.
• Two providers, one physical path. Logical diversity over the same conduit fails together. Verify duct and PoP diversity in writing.
• Never testing failover. Untested redundancy is a hypothesis. Break it on purpose, in a window, before it breaks itself at 2 a.m.
• Forgetting the abuse and NOC contacts. When something goes wrong, other networks will try to reach those addresses. Monitor them.

The ongoing operational commitment

An ASN is a living thing. Budget for annual RIR fees, transfer-market renewals or lease costs if you bought IPv4 space, router software maintenance, and the staff time to watch your announcements. At minimum, subscribe to a BGP monitoring service that alerts when your prefixes are announced from unexpected origins or go RPKI-invalid — route hijacks and leaks happen to networks of every size, and the difference between an incident and an outage is usually how fast you notice.

Keep the routing policy document under version control and review it after every change window. The WISPs that run BGP well treat it like a safety system: documented, tested, and boring. Boring is the goal.

Done right, your own ASN turns backhaul from a single vendor relationship into a market: you can renegotiate, replace, or add providers without renumbering a single customer, and your redundancy becomes a property of your network rather than a promise in someone else's SLA.