phoenixNAP BYOIP Integration Overview
Location
This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with phoenixNAP Bare Metal Cloud (BMC) and its global network. phoenixNAP productizes BYOIP as Bring Your Own (BYO) Public IPs for Bare Metal Cloud and as BYOIP prefixes via BGP. You can import your own IPv4/IPv6 blocks into BMC, assign them to servers or public networks, and optionally advertise them globally using BGP (with either phoenixNAP’s regional ASNs or your own public ASN). BYOIP onboarding is semi-automatic: initial import and removal of BYO ranges are handled via phoenixNAP Support, while day-to-day assignment and BGP routing of those prefixes are fully self-service via portal and API.
Provider Details
| Field | Information |
|---|---|
| Provider Name | phoenixNAP (Bare Metal Cloud & Global Network) |
| Website | phoenixNAP Homepage | Bare Metal Cloud Platform Overview | BMC Public IP Management (BYO Public IPs) | How to Use BGP on Bare Metal Cloud (BYOIPs & ASN) | Global Network & Data Center Locations |
| ASN(s) |
phoenixNAP operates a global backbone with multiple public ASNs, including: – AS12189 (phoenixNAP) – primary global network with presence across IXPs such as AMS-IX, DE-CIX, Equinix Ashburn/Chicago/Los Angeles, SIX, Ninja-IX Phoenix, etc. – AS11572, AS46385, AS400672, AS59210 – additional phoenixNAP ASNs used in specific regions/PoPs. Within Bare Metal Cloud, BGP also uses internal ASNs (phoenixNAP ASN 65400 and default tenant ASN 65401) for local/global routing between BMC and your servers. Region-specific public ASNs are exposed via the rpkiRoaOriginAsn field for ROA creation when phoenixNAP originates your prefixes. |
| Regions Supported |
phoenixNAP’s BYOIP capabilities are tied to Bare Metal Cloud regions and the global phoenixNAP backbone. Documented Bare Metal Cloud BYOIP/BGP locations include: – North America: Phoenix (PHX), Ashburn (ASH), Chicago (CHI), Seattle (SEA), Austin (AUS). – Europe: The Netherlands / Amsterdam (NLD). – Asia-Pacific: Singapore (SGP). These sit on top of a wider phoenixNAP footprint (data centers in Phoenix, AZ and Amsterdam, NL plus Network PoPs in Ashburn, Atlanta, Belgrade, Frankfurt, Helsinki, Los Angeles, Madrid, Milan, São Paulo, Seattle, Singapore, Sofia, Sydney, Taipei, Warsaw, and more). BYOIP prefixes can be onboarded and advertised per-location, enabling regional or multi-regional Anycast deployments. |
| Support Contact | phoenixNAP Knowledge Base (technical docs) | Contact & Sales | Support phone (US): +1-855-330-1509 | General Support via BMC portal or ticketing. |
| Tech Article & Date |
BMC Public IP Management via Portal and API – February 22, 2022 (introduces BYO Public IP blocks, supported prefix sizes, and locations). How to Use Border Gateway Protocol on BMC – September 5, 2024 (details BGP, Local vs. Global BGP, BYOIPs and prefixes, BYO ASN, RPKI/ROA, Anycast, and BGP APIs). |
| BYOIP Scope |
phoenixNAP supports BYOIP in two main ways on Bare Metal Cloud: 1) Bring Your Own (BYO) Public IPs to BMC: You can import your own public IPv4 and IPv6 blocks into BMC. After Support onboards them, they appear as labeled BYO allocations in the Public IP Allocations page and can be assigned to servers or public networks like native phoenixNAP IP blocks. BYOIP blocks are not billed and do not count against your PNAP public IP quota; supported BYO sizes are IPv4 /31 to /16 and IPv6 /48 to /20. 2) BYOIP Prefixes via BGP (Local & Global BGP): Any IP block (phoenixNAP-provided or BYO) associated with your account can be advertised over BGP from your servers, with options for: – Local BGP: internal routing within BMC (IPv4 /25–/32, IPv6 /49–/64). – Global BGP: Internet-visible routes using BYO prefixes (IPv4 /24 or larger; IPv6 /48 or larger) either with phoenixNAP as origin, with the default tenant ASN 65401, or with your own public ASN. Multi-location onboarding enables Anycast designs. BYOIP onboarding is semi-automatic: BYO blocks and their splits/merges are imported/removed via Support; ongoing assignment, tagging, and BGP use of those blocks are managed via portal and API. |
| Supported Versions | IPv4 and IPv6. BMC supports public IPv4/IPv6 allocations, BYOIPv4/IPv6 blocks, and dual-stack BGP sessions. Global BGP is supported for prefixes visible in the global routing table (IPv4 /24 or larger; IPv6 /48 or larger). Local BGP supports longer-match advertisements down to IPv4 /32 and IPv6 /64 for internal steering. |
| Supported Services |
The documented BYOIP feature set is focused on Bare Metal Cloud and related BMC networking services: – BMC servers and public networks using BYO public IP allocations for direct Internet access. – BMC BGP integration (Local & Global BGP) using BYO prefixes with PNAP or BYO ASN for transit across the phoenixNAP backbone. In traditional colocation / dedicated server scenarios, BYO prefixes and BGP peering may also be available through phoenixNAP’s carrier-neutral Meet-Me Rooms and IP transit offerings, but these are typically scoped and provisioned on a case-by-case basis with the network team. |
Technical Requirements
| Requirement | Details |
|---|---|
| Prefix Size |
For BYO public IP blocks in BMC: – IPv4: supported BYO block sizes from /31 to /16. – IPv6: supported BYO block sizes from /48 to /20. For BGP advertisements in BMC: – Local BGP: IPv4 /25–/32, IPv6 /49–/64 (internal to BMC, not visible on the global Internet). – Global BGP: IPv4 /24 or larger, IPv6 /48 or larger to appear in the global routing table; prefixes must be onboarded to your account and at the correct location before they can be advertised. |
| ASN Ownership Required |
For BYO Public IPs used as static addresses or with phoenixNAP as route origin, you do not need your own public ASN; phoenixNAP’s regional ASNs and internal ASNs (65400/65401) can be used for BGP where phoenixNAP is origin. For BYO ASN scenarios, you must own a public ASN with a corresponding RIR registration. phoenixNAP validates ASN control using the abuse contact and IRR objects for that ASN, and will only accept aut-num / AS-SET objects from the RIR where the ASN is registered. Private ASNs are not supported for BYO ASN in BMC. |
| IRR / Route Objects |
When you use BYO ASN with BYO prefixes over BGP, phoenixNAP requires that: – The ASN and its prefixes are correctly represented in the appropriate RIR Internet Routing Registry (IRR) database using route and/or AS-SET objects. – The organization object (org:) and abuse contact are properly referenced from the aut-num object. phoenixNAP validates IRR data for your ASN when enabling BYO ASN and may reject or delay onboarding if IRR objects do not align with the requested prefixes. For phoenixNAP-originated BYO prefixes, ROA + RPKI information (rather than customer IRR) is the primary trust anchor. |
| ROA or LOA |
phoenixNAP recommends maintaining RPKI Route Origin Authorizations (ROAs) for all Global BGP prefixes as a best practice for hijack prevention. When phoenixNAP originates your BYO prefix on the Internet, you must: – Use the phoenixNAP region ASN (exposed as rpkiRoaOriginAsn via API) as the origin ASN in your ROA entries.– Ensure ROAs remain valid and aligned with your BGP configuration to avoid route rejection. Formal LOAs are not described as part of the BMC BYOIP workflow; any LOA requirements are handled case-by-case through phoenixNAP Support and Network Operations, especially for non-BMC IP transit or custom peering arrangements. |
| RIR Limitations |
BYOIP space and BYO ASN must be public, globally routable resources registered with one of the major RIRs (ARIN, RIPE, APNIC, LACNIC, AFRINIC). You must: – Be listed as the resource holder for the prefix(es) you want to onboard. – Maintain accurate RIR registration data, including an active abuse contact mailbox. – For BYO ASN, ensure the org object, aut-num, and AS-SET/route objects are consistent and up-to-date. phoenixNAP uses the RIR-registered abuse contact as part of its BYO ASN vetting process and will fail the request if required confirmations are not received within their stated time window. |
Step-by-Step BYOIP Process
Estimated Setup Time: Typically ranges from a few days to several weeks, depending on RIR/IRR/RPKI hygiene, internal change control, and whether you are using phoenixNAP as route origin, your own ASN, or a multi-region Anycast design.
Tested By Us: Not yet
A) Bring Your Own (BYO) Public IP Blocks to Bare Metal Cloud
B) BYOIPs with Local/Global BGP and Optional BYO ASN
Cost and Limitations
| Item | Details |
|---|---|
| Fees |
phoenixNAP does not publish a separate price list for BYOIP itself. Current documentation highlights: – BYO Public IP blocks are not billed and do not count against the allowed quota of phoenixNAP public IP allocations. – Standard BMC public IP blocks (phoenixNAP-owned) are billed per block size and location, as described in BMC network/IP pricing and billing docs. – BGP support is part of the Bare Metal Cloud networking feature set; any design, professional services, or advanced peering arrangements are subject to commercial discussions with phoenixNAP Sales/Support. |
| Bundled or Standalone |
BYOIP is embedded into Bare Metal Cloud and phoenixNAP’s global network; it is not sold as a standalone “prefix hosting” product: – BYO Public IPs: Used with Bare Metal Cloud servers and public networks, managed via BMC portal and IP APIs. – BYOIPs & BGP: BMC acts as a transit and compute platform for your prefixes, combining compute, storage, and routing inside phoenixNAP data centers and PoPs. For colocation or pure IP transit, phoenixNAP can often accommodate customer-owned prefixes via dedicated network services, but these fall under broader colocation/network contracts rather than the BMC BYOIP feature alone. |
| Traffic/Peering Restrictions |
Key documented constraints include: – BGP peering is supported only with IP blocks associated with server public addresses or public networks; no peering over private IPs or loopback peering on servers at this time. – One BGP Peer Group per location per account; each peer group can serve both IPv4 and IPv6 families. – Global BGP visibility is limited to prefixes that meet standard Internet routing constraints (typically IPv4 /24+, IPv6 /48+) and are correctly originated and authorized in RPKI/IRR. – phoenixNAP may apply standard routing policies, prefix limits, and dampening for unstable advertisements; customers must keep advertisements stable and within documented limits. |
| Other Limitations |
– BYOIP blocks cannot be split or merged after import; changes require re-onboarding via Support. – BYOIP blocks cannot be added or deleted via API; only phoenixNAP Support can onboard or remove them from your account. – BYO ASN onboarding includes a vetting window; if phoenixNAP does not receive confirmation via your RIR abuse contact within the stated timeframe, the BYO ASN request fails. – Misconfigured or expired ROAs, incorrect IRR objects, or unstable BGP advertisements can lead to reachability issues and may require coordinated changes with phoenixNAP and upstream networks. – As with any BGP-based design, you are responsible for your internal high availability, capacity planning, and change management to avoid traffic blackholing. |
Automation & Developer Access
Abuse & Reputation Management
Related Resources
phoenixNAP Homepage
Bare Metal Cloud Platform Overview
BMC Public IP Management via Portal and API (includes BYO Public IPs)
How to Use Border Gateway Protocol on BMC (BYOIPs, BYO ASN, Local vs Global BGP)
Data Center Network Services: Global Locations
Global Data Center Locations (Phoenix & Amsterdam)
phoenixNAP Developers Portal
Terraform Provider: phoenixNAP
Ansible Collection: phoenixnap.bmc