Openmetal BYOIP Integration Overview
This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with OpenMetal private cloud and bare metal infrastructure. OpenMetal supports BYOIP by originating your public IPv4 prefix from OpenMetal edge routers (provider-announced model), enabling you to preserve IP-based identity (allowlists, API endpoints, email reputation) while running workloads on OpenMetal. OpenMetal also supports provider-allocated dedicated IP blocks (e.g., /28) when you do not bring your own space. BYOIP can be used across OpenMetal’s networking stack, including direct attachment to instances and use with load balancers, with DDoS protections available at the edge.
Provider Details
| Field | Information |
|---|---|
| Provider Name | OpenMetal |
| Website | OpenMetal Homepage | Cloud Networking Feature Details (BYOIP /24+) | BYOIP Architecture Article (Anycast, DDoS, /24+) | Data Center Locations | OpenMetal Central: Add Public IP Address Blocks | Contact |
| ASN(s) | OpenMetal originates BYOIP announcements from its own ASN (documented publicly as AS400956, “OPENMETAL-AS”). In BYOIP scenarios, you typically authorize OpenMetal’s origin ASN for your prefix (e.g., via RPKI ROA) so the announcement is not RPKI-invalid. |
| Regions Supported |
OpenMetal infrastructure is offered from Tier III data center spaces in: - United States: Ashburn, Virginia (US East) and Los Angeles, California (US West) - Europe: Amsterdam, Netherlands - Asia: Singapore BYOIP practicality improves when you can deploy the same addressing across multiple locations (including anycast patterns) while keeping DNS and allowlists stable. |
| Support Contact | Contact / Sales (sales@openmetal.io) | Legal / Customer Service references (customerservice@openmetal.io / support@openmetal.io) | OpenMetal Central support request workflow (requires login): Docs navigation includes “Creating a Support Request”. |
| Tech Article & Date | Why Enterprise Workloads Need BYOIP Support That Hyperscalers Can’t Provide - OpenMetal’s overview of BYOIP for /24+ blocks, BGP edge routing, anycast use cases, and how BYOIP integrates with instances/load balancers (Updated on November 20, 2025). |
| BYOIP Scope |
OpenMetal’s BYOIP is a provider-announced prefix model: 1) Customer-owned IPv4 prefix (/24+): You bring a routable IPv4 block (minimum /24) and OpenMetal announces it from their edge routers/ASN for use within your OpenMetal environment. 2) Provider-allocated dedicated IP blocks: If you do not have your own IP space, OpenMetal can provide dedicated blocks (e.g., /28) associated with your deployment (less portable than true BYOIP, but dedicated within OpenMetal). |
| Supported Versions |
Documented: Public IPv4 BYOIP with a minimum of /24 for announcement from OpenMetal edge routers. IPv6: OpenMetal operates IPv6 on its network, but customer BYOIP for IPv6 is not explicitly documented in the public BYOIP materials above; confirm current availability/requirements with OpenMetal support. |
| Supported Services | BYOIP concepts apply to OpenMetal’s Hosted Private Cloud (OpenStack) and Bare Metal Dedicated Servers. Documented integration points include attaching BYOIP addresses to instances, using OpenStack load balancers, and applying firewall rules while maintaining dedicated VLAN isolation. |
Technical Requirements
| Requirement | Details |
|---|---|
| Prefix Size | IPv4 BYOIP minimum: /24 (256 addresses) or larger for announcement from OpenMetal edge routers. If you do not bring your own space, OpenMetal can provide dedicated provider-allocated blocks (commonly referenced as /28 as an example of dedicated allocation). |
| ASN Ownership Required | No customer ASN is required for the standard provider-announced BYOIP model. OpenMetal originates the prefix from its own ASN/edge routers. (If you maintain RPKI, you generally publish/adjust a ROA to authorize OpenMetal’s origin ASN so the route remains RPKI-valid.) |
| IRR / Route Objects | Best practice: maintain accurate IRR/route objects for your prefix (where applicable) and align them with the announced origin ASN used by OpenMetal. This improves global routing acceptance and troubleshooting. Confirm any provider-specific requirements with OpenMetal support. |
| ROA or LOA | If your prefix is protected by RPKI, publish/adjust a ROA authorizing the OpenMetal origin ASN to avoid RPKI-invalid announcements. OpenMetal may also request an LOA or equivalent proof-of-control during onboarding (common in provider-announced BYOIP workflows). |
| Service / Platform Dependencies | You should have an active OpenMetal deployment (Hosted Private Cloud and/or Bare Metal) and networking configuration that supports public IP attachment and/or load balancer integration. OpenMetal documentation shows self-service workflows to add/attach provider IP address blocks to VLANs in OpenMetal Central; BYOIP announcements typically require provider-side routing work. |
Step-by-Step BYOIP Process
Estimated Setup Time:Typically days to a few weeks depending on prefix validation, RPKI/IRR updates, and coordination/testing across applications (allowlists, DNS, partner firewalls).Tested By Us:Not yet
Provider-announced BYOIP (Customer-owned /24+ via OpenMetal edge routers)
Confirm you have a globally routable…
Choose the OpenMetal deployment region
Open a support request with OpenMetal…
If you use RPKI, publish/adjust a…
OpenMetal configures BGP announcements at their…
Assign and use BYOIP addresses within…
From OpenMetal Central, request additional public…
Assign the new public block to…
Treat these addresses as stable inside…
1
Confirm you have a globally routable…
Confirm you have a globally routable public IPv4 prefix (minimum /24) under your control (owned/leased long-term) and that you can make any required routing registry updates (IRR) and RPKI ROA changes.
Step 0 of 0
Cost and Limitations
| Item | Details |
|---|---|
| Fees | OpenMetal documents that clouds include a base public IPv4 block, and that additional blocks are available for a fee. BYOIP (customer-owned /24+) typically requires support-led onboarding to implement announcements; commercial terms and any one-time setup fees (if any) should be confirmed with OpenMetal sales/support. |
| Bundled or Standalone | BYOIP is not a standalone service; it is delivered as part of OpenMetal’s cloud/bare-metal networking capabilities (edge routing + integration with instances/load balancers/VLANs). |
| Minimum Block Size Constraints | Customer BYOIP is documented for /24 and larger IPv4 blocks. Smaller allocations (e.g., /28) are referenced as provider-allocated dedicated blocks, not portable BYOIP. |
| Operational Dependencies | You are responsible for keeping your routing hygiene current (RPKI ROA/IRR where applicable). Many enterprises also maintain abuse workflows and reputation management for customer-owned space (email reputation, API allowlists, security feeds). DDoS posture and routing policy details should be validated in design/testing. |
Automation & Developer Access
- Self-service (OpenMetal Central): OpenMetal documents a workflow to add public IP address blocks and assign them to provider VLANs from their portal, enabling day-2 IP lifecycle management for provider-allocated space.
- OpenStack APIs: Hosted Private Cloud is powered by OpenStack, enabling infrastructure-as-code patterns for networks, floating/public IP usage, load balancers, and security groups using standard OpenStack APIs/clients (subject to your OpenMetal deployment configuration).
- BYOIP onboarding automation: The public documentation describes BYOIP announcements as a provider edge-router capability; in practice, initial prefix onboarding/announcement is typically implemented via support engagement rather than a fully self-serve workflow.