BYOIP on OVHcloud for bare-metal fleets

Bare-metal fleets use a lot of public IPv4: at least one address per server, and often more for customers, services and virtual machines. Bringing your own addresses to OVHcloud keeps that space under your control and lets it move with you. This article covers when it is worth doing, what the registry side requires and what to plan before the first server gets an address.

Why bring your own addresses to OVHcloud?

OVHcloud charges $2.39 per IP per month for additional IPv4 and doesn’t charge extra for BYOIP addresses. At fleet scale the difference adds up: 256 additional addresses come to about $612 a month, every month.

Cost is only part of the case. Common reasons for BYOIP on bare metal include:

• Portability. Customers and partners allowlist your addresses. If you later move servers to another provider or your own datacentre, the addresses can move too.
• Control of reputation. You decide who uses the block and how abuse is handled, instead of inheriting addresses with an unknown history.
• Stable identity. Mail relays, VPN endpoints, game servers and APIs keep the same addresses through hardware refreshes and migrations.
• One address plan. The same block can serve your own infrastructure and the provider’s, with clear records of where each part lives.

If you don’t already hold a block, compare the cost of buying or leasing one against paying for additional IPv4 over the period you expect to run the fleet. Buying turns a recurring cost into an asset you can later sell or lease out; leasing keeps the commitment shorter.

What OVHcloud requires

OVHcloud accepts BYOIP prefixes from /24 to /19. The registry side follows the familiar pattern:

1. The prefix is correctly registered, with the holder matching the OVHcloud account or with written authorisation from the holder.
2. A ROA authorises AS16276 as an origin for the prefix, with a max length that matches what will be announced.
3. A route object exists for the prefix and AS16276, so IRR-based filters accept the announcement.
4. No other network is still announcing the prefix.
5. Reverse DNS delegation is planned, so PTR records can be set for the servers that need them.

Check OVHcloud’s current BYOIP documentation for the exact submission steps and any further checks, as procedures change. If the block is held through an LIR, agree with them in advance who creates the ROA and route object.

Planning the prefix for a fleet

Sizing comes first. A /24 gives 256 addresses, and a /19, the largest OVHcloud accepts, gives 8,192 in one prefix. Count what you need today across servers, customer allocations, virtual machines and management interfaces, then add realistic growth before choosing a size.

Next, decide how to carve the block up. Useful questions to answer before anything goes live:

• Will addresses be assigned per server, per customer or per service?
• Which ranges must stay stable because third parties allowlist them?
• Do mail, customer workloads and your own infrastructure need separate ranges, so a problem in one does not drag down the others?
• How will addresses be distributed across OVHcloud locations? Confirm with OVHcloud how a prefix can be split before you design around it.

Keep the plan in one place, whether an IPAM tool or a well-kept spreadsheet, and record the ROA, route object and reverse DNS status next to each range. Our subnet calculator helps when you work out the boundaries.

Reputation and abuse handling

Bare-metal fleets often host customer workloads, and with BYOIP the block’s reputation is yours to look after. Before bringing a block in, check it against the main blocklists and threat intelligence sources. A block with a poor history carries that history straight into OVHcloud.

Once the block is live:

• Make sure the abuse contact in the RIPE Database reaches someone who acts on reports.
• Monitor blocklists for all your ranges and respond to listings quickly.
• Set clear acceptable use terms for customers and enforce them consistently.
• Keep higher-risk activity, such as outbound mail from customer servers, in its own range.

Plan the exit as well as the entry

BYOIP is only portable if the records stay tidy. When you move a range away from OVHcloud, sequence the change: prepare the ROA and route object for the new origin, move the traffic, then remove the authorisation for AS16276 once OVHcloud has withdrawn its announcement.

Stale ROAs and route objects make later moves harder and keep authorising announcements you no longer intend. Review them whenever a range changes hands or purpose, and update reverse DNS delegation at the same time.

How TACS can help

TACS prepares the registry side of BYOIP on OVHcloud, from the ROA for AS16276 to route objects and reverse DNS, and can run an IP security audit on a block before it goes live. If your fleet needs more addresses, we can help you buy IPv4 or lease it.