Getting Your Own ASN and IP Space: How to Join an Internet Exchange Point

When your data center starts buying transit from more than one provider or hosting customers who bring their own prefixes, provider assigned addresses stop being enough. You need address space that stays with you when a provider changes and an identity on the global routing system that other networks recognize as you. That identity is an Autonomous System Number, and the space is provider independent IP allocated directly by a Regional Internet Registry.

Getting both is less exotic than it sounds, but it is a formal process with contracts, justification, and technical prerequisites. The exchange part is where the investment pays back, because once you can speak BGP as yourself you can peer directly with content networks, clouds, and other operators in your metro instead of paying transit for every bit. This guide walks through when you qualify, how the RIR process works for ASN and IP space, what you must prepare to announce, and how joining an internet exchange actually works for a data center operator.

Why an Operator Needs Its Own ASN and IP Space

An ASN is your network’s identity in BGP, the protocol that stitches the internet together. Without it you are borrowing identity from a provider, which means every prefix you use is part of their aggregate and leaves when you do. With your own ASN you can originate your own prefixes, set your own routing policy, and make decisions about transit and peering that survive a contract change.

The practical trigger is usually multihoming or colocation. If you plan to connect to two transit providers for resilience, host multiple tenants who expect stable addresses, or operate in a facility where you want to peer at the local exchange, you need provider independent space that both providers can announce and an ASN that can be the origin. Even a single homed operator benefits when public services depend on addresses that must not renumber, such as authoritative DNS, VPN concentrators, or customer assigned subnets. Provider independent space removes renumbering from the provider change, and the ASN is what lets you control how that space is announced.

What an ASN Is and When You Qualify

An ASN is a 32 bit number that identifies your network as a distinct routing domain. The original 16 bit space ran from 1 to 65535 and the modern 32 bit space extends to over four billion, so new assignments are 32 bit by default and the distinction only matters if you peer with very old equipment that still negotiates 16 bit only. Private ASNs in the 64512 to 65534 and 4200000000 to 4294967294 ranges exist for internal use, but a globally visible ASN must be public and registered to your organization.

Every Regional Internet Registry uses a similar qualification test even though the paperwork differs. You must show that you have a need for a unique routing policy, most often because you will multihome to two providers, exchange routes with another ASN without transit in between, or operate an internet facing network that must be addressed independently from any single provider. A single homed network that merely buys transit from one provider and never peers does not normally qualify, and the RIR will ask you to use that provider’s ASN and address space instead. For a data center operator hosting third party equipment or offering interconnection, that test is usually easy to meet, because the facility itself is a natural place for multiple providers and local peering.

Expect to provide organization details, contact roles, at least two upstream ASNs or a peering plan, and a description of your routing policy. In the RIPE region you need membership or a sponsoring LIR that holds the registration on your behalf, while ARIN, APNIC, LACNIC and AFRINIC allow direct requests from organizations that justify the need. Fees are annual and modest compared to port and cross connect costs, but the registration must stay current or your objects risk being marked as inconsistent.

Getting IP Space From Your RIR

IP space comes in two forms and the distinction decides whether a provider change is a routing update or a renumbering project. Provider aggregatable space is carved from a provider’s larger block and must be returned when you leave. Provider independent space is assigned directly to your organization by the RIR and stays with you across providers, which is what most operators mean when they say they want to own their addresses.

IPv4 PI is scarce in every region. RIPE, ARIN and APNIC have exhausted their free pools, so new IPv4 PI usually comes from a waiting list, a transfer market, or a small recovery pool with strict justification. Expect to document immediate need, utilization of any existing space, and a plan that respects the /24 filtering floor, since most networks filter IPv4 announcements longer than a /24 and a /25 may be unreachable even when perfectly valid. IPv6 PI is more available. Most RIRs assign a /48 for a single site PI or a larger block if you can justify multiple sites, and filtering typically allows /48 and shorter to propagate globally.

Your RIR request will ask for organization verification, intended use, assignment size, and how the space maps to your ASN. Keep your registration data, abuse contacts, and reverse DNS delegation accurate from day one, because exchange admission, transit provisioning and later RPKI creation all pull from the same registry objects. For planning and audit purposes, model every aggregate with its source, type, RIR handle, and current utilization in your IP address management hierarchy so the portable portion of your space is obvious before any contract is signed.

Preparing to Announce: IRR, RPKI, and Routing Policy

Before peers accept your routes, they will check two databases that describe your intent. The Internet Routing Registry is a distributed database of route and aut num objects that document which prefixes your ASN is authorized to originate and which peers you intend to peer with. RPKI is a cryptographic system that binds your prefix to your ASN through a Route Origin Authorization signed by the RIR. An incorrect or missing entry in either system is the most common reason a new announcement is filtered, even when BGP is configured correctly.

Start with the IRR. Create a route object for each prefix bound to your ASN, an aut num object that describes your import and export policy, and as set objects if you will maintain a peer group or customer cone. Many networks build prefix filters directly from IRR data, so a typo in the prefix length or an object created in the wrong IRR source will silently reduce your reach. Next create RPKI ROAs for every prefix you will originate, with the correct origin ASN and maximum length that matches your announcement plan. A ROA that authorizes AS 64520 for 203.0.113.0/24 with max length 24 will mark a more specific 203.0.113.0/25 as invalid if you later try to deaggregate, so be deliberate about whether you need to allow more specifics.

Operationally you also need a BGP speaker. That can be a dedicated router, a pair for resilience, or a virtual router hosted in your data center, plus at least one transit session that will carry your traffic before peering is established. Document the ASN, prefixes, ROA status, IRR objects, and peering contacts together where your operations team can see them, because a future provider change or exchange application will ask for the same details.

Joining an Internet Exchange: How It Works

An internet exchange is a physical switching fabric where many networks meet to exchange traffic directly. You connect a router port to the fabric, establish BGP sessions, and traffic to destinations behind fellow members stays local instead of traversing transit. The fabric itself is usually a pair of redundant switches per peering LAN run by the exchange, and your port is an access port on that fabric provisioned at a fixed speed.

Peering at the exchange takes two forms. Multilateral peering through route servers lets you exchange routes with dozens or hundreds of members over one or two BGP sessions. Each member advertises its prefixes to the route server, the route server redistributes them according to each member’s filtering policy, and you gain broad reach without negotiating each session individually. Bilateral peering is a direct BGP session between your ASN and one other ASN over the same fabric. It gives you full control over filtering, communities, and capacity and is common for high volume peers where you want predictable performance outside a shared route server.

As a data center operator you have two ways to reach the fabric. A direct physical presence means you order a cross connect from your rack to the exchange switch inside the same building or campus, which is the lowest latency and most controllable option. Remote peering uses a transport provider or reseller that extends the exchange VLAN to your router over a long haul circuit, which lowers cost and avoids a new point of presence but adds another network to monitor for congestion and maintenance windows. Most exchanges support both, and you can start remotely and move to a direct port when volume justifies it.

What It Costs and How to Choose Your First Exchange

Costs are straightforward but easy to underestimate when you add transport. Expect a one time setup fee, a recurring port fee that scales with speed, and a cross connect fee if you are in an exchange building. A 1 Gbps port is the typical entry point, 10 Gbps is the common next step, and 100 Gbps ports are priced for operators who move serious peering volume. Remote peering replaces the cross connect with a transport fee to a reseller or carrier that already has a presence, which trades a lower upfront cost for dependency on their backbone and their maintenance calendar. Transit is not replaced by any of this, so budget for at least one transit session alongside the exchange port to cover prefixes that no peer at that exchange originates.

Choose your first exchange by where your traffic actually goes, not by headline member counts. List the networks that carry your heaviest volume and your strictest latency requirements, such as primary cloud regions, critical SaaS endpoints, and eyeball networks that serve your customers in the metro. A fabric that hosts those exact networks will move the needle more than a larger exchange whose members are irrelevant to your traffic. Check which building or campus the fabric lives in, whether your data center already has fiber to that building, and what diverse paths exist if a single facility fails. Ask for available peering LANs, route server communities, and whether the exchange enforces filtering based on IRR and RPKI, because the discipline of the fabric directly affects your experience as a new member.

Bringing Your Prefixes Live on the Exchange Fabric

Once your ASN, prefix, and ROAs are in place, sequence the turn up to avoid surprises. First announce your prefix through transit and confirm it propagates with the expected AS path. Validate RPKI status through a public validator and query the IRR to confirm your route objects are visible from the sources your future peers filter on. Confirm reverse DNS and abuse contacts, then apply to your chosen exchange with your ASN, prefixes, contact roles, and peering policy. The exchange will provision your port, assign you addresses on the peering LAN, and share route server session details and any communities that control redistribution.

Bring up the BGP sessions to the route servers, advertise your prefix, and watch for the routes you expect to receive in return. Use the exchange looking glass and public route collectors to verify that your prefix is visible from multiple vantage points, and use traceroutes from inside your network toward peer prefixes to confirm traffic leaves via the exchange rather than transit. Set up monitoring on session state, prefix counts, and traffic ratios, and document the port, VLAN, peering LAN addresses, and session credentials where your team tracks circuits and interconnections. A useful practice is to keep the same rigor for peering as for any other circuit, with the exchange port, cross connect, and BGP details recorded as a single linked record so a future audit can prove the path diversity you intended.

Over time tune the balance. Keep transit for global reach, let exchange peering carry the heavy local flows, and move individual high volume peers to bilateral sessions when route server performance or community control justifies it. The goal is not to peer with everyone, it is to peer where it measurably lowers latency or cost for traffic you actually carry.

Getting an ASN and portable space changes your relationship with providers from tenant to peer, and joining an exchange is where that change becomes operational. Start with clear justification for the RIR, treat IRR and RPKI as part of the build rather than paperwork after the fact, and choose the fabric where your real traffic lives. With those pieces in place, your prefixes stay yours, your routing policy stays yours, and your data center can exchange traffic on your own terms.