Skip to content

phoenixNAP BYOIP Integration Overview

BYOIP SUPPORTER
ASN AS12189
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: Singapore, Netherlands, United States

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

FieldInformation
Provider NamephoenixNAP (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

RequirementDetails
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

  • Validate your IP ownership and routing strategy. Confirm you control the desired IPv4/IPv6 prefixes in your RIR portal, and decide in which BMC locations (PHX, ASH, CHI, SEA, AUS, NLD, SGP) you want to use them and how they should be split into importable blocks.
  • Create or log in to your Bare Metal Cloud account and ensure you can access the BMC portal and the Networking → Public IP Allocations page for the target locations.
  • Open a ticket or contact phoenixNAP Support/Sales requesting BYO Public IP onboarding. Provide prefix details (family, size, RIR handle), desired BMC locations, and how you want the space split into blocks. Note that BYO blocks cannot be split or merged after import.
  • Once Support completes onboarding, verify that your BYOIP blocks appear in the Public IP Allocations table with a BYO label and with the correct locations and sizes. Confirm that they are not billed and do not consume PNAP public IP quota.
  • Assign BYO blocks to BMC servers or public networks via the portal or Public IP APIs. Configure the operating system/network stack on your servers to use the assigned addresses for egress or service endpoints.
  • If you only require static source IPs, you can stop here. If you need Internet-visible routing control (Global BGP or Anycast), proceed with the BGP configuration steps in section B for Local/Global BGP and optional BYO ASN.

B) BYOIPs with Local/Global BGP and Optional BYO ASN

  • Ensure BGP prerequisites: have at least one BMC server attached to a server or public network in each region, a BGP-capable routing stack (e.g., FRR/Bird), and BMC portal/API access.
  • Onboard any BYO prefixes you plan to use (see section A) and confirm they are present in the correct BMC locations. Decide whether phoenixNAP will be the BGP origin, you will use the default tenant ASN 65401, or you will bring your own public ASN.
  • If using BYO ASN, request BYO ASN enablement through Support. phoenixNAP will validate your ASN via RIR/IRR (aut-num, AS-SET, abuse contact) and may ask for confirmations using the RIR-registered abuse mailbox before activating your ASN on BMC.
  • In the BMC portal (or via Networks API), create a BGP Peer Group in each desired location (PHX, ASH, CHI, SEA, NLD, SGP, AUS). Specify location, ASN (phoenixNAP default or your BYO ASN), BGP password, and default route behaviour, then configure BGP peering on your server using the documented PNAP loopback addresses, timers, and multihop settings.
  • Advertise your prefixes from your server towards the PNAP BGP endpoints. Use Local BGP (/25–/32 or /49–/64) for intra-BMC steering, and ensure Global BGP-eligible prefixes (IPv4 /24+, IPv6 /48+) are properly originated on the Internet. Maintain RPKI ROAs so that the correct origin ASN (phoenixNAP’s regional ASN or your BYO ASN) is authorized for those prefixes.
  • For Anycast or multi-region deployments, onboard the same BYO prefixes in each region where they should be reachable, configure BGP in each location, and carefully test failover, traffic steering, and route stability before moving production traffic. Monitor logs, flows, and performance via your observability stack and phoenixNAP metrics.

Cost and Limitations

ItemDetails
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

  • Bare Metal Cloud APIs: phoenixNAP exposes REST APIs for BMC servers, networking, and IP blocks (including listing, assigning, tagging, and managing public IP allocations, plus BGP Peer Groups). These APIs allow you to fully automate BYOIP usage once prefixes are onboarded.
  • Networks/BGP APIs: Dedicated Networks APIs let you create, update, and delete BGP Peer Groups programmatically, control advertised routes (DEFAULT/NONE), and integrate BGP setup into CI/CD or infrastructure-as-code pipelines.
  • Terraform & Ansible: phoenixNAP maintains a Terraform provider (e.g., ip_block and network resources) and Ansible modules (including BGP peer group management) so you can manage BMC servers, networks, and IPs as code, including BYOIP assignments and BGP peer group lifecycle.
  • Developers Portal & SDKs: The phoenixNAP Developers Portal provides interactive API docs, examples, and language-specific tooling. Combined with BMC and Networks APIs, this enables end-to-end automation of server deployment, IP onboarding workflows (post-Support), and BGP configuration across regions.

Abuse & Reputation Management

  • For BYO prefixes, you remain the authoritative RIR resource holder and are responsible for IP reputation, blacklist status, and abuse handling. phoenixNAP relies on the RIR abuse contact for BYO ASN validation and will use this channel for operational or security communications related to your space.
  • phoenixNAP provides DDoS protection and network-level security controls for traffic transiting its backbone, but you must operate your workloads in compliance with phoenixNAP’s acceptable use policies. Abuse events sourced from your BYO addresses (spam, scanning, attacks) must be addressed by you, including liaising with external RBL/blacklist operators where needed.
  • Maintaining accurate RPKI ROAs and IRR objects for your BYO prefixes, keeping BGP advertisements stable, and monitoring your own traffic patterns are essential to preserving long-term IP reputation and avoiding routing anomalies or hijack risk when using phoenixNAP as a transit platform for your space.

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

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.