{"id":24833,"date":"2026-10-04T13:20:12","date_gmt":"2026-10-04T13:20:12","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=24833"},"modified":"2026-10-05T09:39:30","modified_gmt":"2026-10-05T09:39:30","slug":"byoip-for-dedicated-servers","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/fr\/byoip-for-dedicated-servers\/","title":{"rendered":"BYOIP for Dedicated Servers: Requirements and Responsibilities"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Moving to a new dedicated server can mean updating customer allowlists, API connections, and services tied to existing IP addresses. Bring Your Own IP, or BYOIP, can reduce that work by letting you use eligible public address space with a different hosting provider.<\/span><\/p>\n<p><b>BYOIP for dedicated servers requires control of the address block, provider approval, correct routing authorizations, and a working connection between the announced prefix and your servers.<\/b><span style=\"font-weight: 400;\"> Each party also needs a clear role during migration and after launch.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At Atal Networks, we recommend checking these requirements before setting a migration date. Keeping your addresses helps with continuity, but it does not automatically move applications, preserve connections, or remove routing risks.<\/span><\/p>\n<h2><b>Understand What BYOIP Changes<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">BYOIP lets you use public IP addresses that you control, or have permission to use, on a hosting provider\u2019s infrastructure. The provider accepts the address block and delivers traffic to your servers through an agreed network arrangement.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The move changes where the addresses operate. It does not, by itself, transfer their registration or extend your rights beyond an existing lease.<\/span><\/p>\n<h3><b>A Dedicated IP Is Not Automatically Portable<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">An IP address can remain fixed for years without belonging to your organization. If your current host assigned it from its own pool, you usually cannot take it elsewhere without that host\u2019s permission and a supported routing arrangement.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">BYOIP becomes useful when you have eligible address space and need to retain:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Customer or partner IP allowlists.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Fixed service endpoints.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Network policies tied to specific addresses.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Addressing consistency during infrastructure changes.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">It may be unnecessary if provider-assigned addresses meet your needs and changing them creates little operational work.<\/span><\/p>\n<h2><b>Check BYOIP Requirements Before Ordering<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">The first task is to establish whether the receiving provider accepts your particular prefix, location, and workload.<\/span><\/p>\n<h3><b>Confirm Address Rights and Record Control<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Identify the registered resource holder and the party authorized to approve announcements.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For leased space, confirm that the agreement permits use with the intended hosting provider. Also establish who can create or change routing records. The server customer, IP lessor, and registered holder may be different organizations.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A lease payment alone does not prove that you can make every required registry change. Some platforms require direct control of public registration records, while others accept authorized coordination with the resource holder.<\/span><\/p>\n<h3><b>Check Prefix Size and IPv6 Support<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Providers commonly require at least an IPv4 \/24 for an independent public announcement. That block contains 256 addresses, although usable server capacity depends on the delivery method.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A single IP or \/29 is generally too specific for broad acceptance as an independent Internet announcement. A provider may still route smaller portions internally beneath an accepted larger prefix.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Check IPv6 separately. Support for IPv6 on a server does not necessarily mean the provider accepts customer-supplied IPv6 prefixes. Provider documentation shows real differences: the reviewed OVHcloud BYOIP service describes IPv4 only, while AWS documents public IPv4 and IPv6 imports.<\/span><\/p>\n<h3><b>Confirm the Deployment Scope<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Before ordering, ask about eligible server products, facilities, permitted workloads, and existing announcements.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Requirement<\/b><\/td>\n<td><b>Evidence or confirmation needed<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Address-use rights<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Resource records and relevant authorization<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Leased-space permission<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Agreement allowing the intended deployment<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Prefix eligibility<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Accepted address family and block size<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Location support<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Approval for the chosen facility and service<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Routing arrangement<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Agreed origin ASN and delivery method<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Workload acceptance<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Compliance with the provider\u2019s usage terms<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Migration readiness<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Current announcement details and a handoff plan<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2><b>Choose Who Announces Your IP Addresses<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">BYOIP describes the use of your address space. It does not specify who operates <a href=\"https:\/\/atalnetworks.com\/fr\/how-asn-and-bgp-planning-affect-dedicated-server-deployments\/\">BGP<\/a>, the protocol networks use to exchange routes.<\/span><\/p>\n<h3><b>Provider-Managed Announcements<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">The hosting provider announces the prefix through an agreed origin ASN and routes the addresses to your servers.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You supply the required permissions and maintain the records under your control. The provider manages its routing configuration.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This arrangement can suit businesses that need address portability without operating their own routing software.<\/span><\/p>\n<h3><b>Customer-Managed BGP<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Your routing device or software exchanges routes with the provider. You manage your side of the session, including announcement policy and route withdrawal.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Both parties must agree on accepted prefixes, session settings, security controls, and troubleshooting responsibilities.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Decision<\/b><\/td>\n<td><b>Provider-managed arrangement<\/b><\/td>\n<td><b>Customer-managed BGP<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Customer operates BGP<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Usually not required<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Required<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Customer public ASN<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Depends on the service<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Depends on the agreed design<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Announcement changes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Provider workflow<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Customer configuration plus provider policy<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Operational workload<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Lower customer routing workload<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Customer maintains routing and monitoring<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><b>BYOIP and BYOASN are separate choices.<\/b><span style=\"font-weight: 400;\"> Bringing your addresses does not always require your own public Autonomous System Number. Dedicated.com documents several announcement arrangements, while Vultr allows either a customer ASN or a private-ASN arrangement.<\/span><\/p>\n<h2><b>Prepare Authorization and Routing Records<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Proof that you may use an address block and permission for a network to announce it are related but separate requirements.<\/span><\/p>\n<h3><b>Letter of Authorization<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">A Letter of Authorization, or LOA, records permission for the specified network arrangement. Providers commonly request:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IP prefixes in CIDR notation.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The resource holder\u2019s organization name.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The authorized network and relevant ASN.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">An authorized signature and date.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Contact details and any required expiry date.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Use the receiving provider\u2019s format. If you lease the space, the provider may require authorization from the registered holder rather than a letter signed only by your company.<\/span><\/p>\n<h3><b>IRR Records and RPKI ROAs<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">An Internet Routing Registry, or IRR, stores routing information. A <\/span><span style=\"font-weight: 400;\">route<\/span><span style=\"font-weight: 400;\"> object identifies an IPv4 prefix and origin ASN; a <\/span><span style=\"font-weight: 400;\">route6<\/span><span style=\"font-weight: 400;\"> object serves the corresponding role for IPv6.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A Route Origin Authorization, or ROA, uses Resource Public Key Infrastructure, or RPKI, to authorize an ASN to originate specified address space.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Record<\/b><\/td>\n<td><b>Main purpose<\/b><\/td>\n<td><b>Party to identify<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">LOA<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Documents announcement permission<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Authorized resource representative<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">IRR route or route6 object<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Supplies routing information used in filtering<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Authorized registry maintainer<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">ROA<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Authorizes the origin ASN and prefix length<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Resource holder or authorized RPKI administrator<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Check the origin ASN and permitted prefix length before announcement. A mismatch can cause networks applying origin checks to reject the route.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">RPKI origin checks do not secure every part of the routing path. We still recommend explicit route filters and ongoing monitoring.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Some platforms use certificates, signed messages, or DNS-based checks to confirm control. Those are provider-specific procedures, not universal BYOIP requirements.<\/span><\/p>\n<h2><b>Assign Responsibilities Before Deployment<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">A BYOIP request can stall when everyone assumes another party owns the next step.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">We recommend recording responsibilities across the customer, resource holder, and hosting provider. The table below describes a typical division; the actual service agreement takes priority.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Task<\/b><\/td>\n<td><b>Customer or resource holder<\/b><\/td>\n<td><b>Hosting provider<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Address permissions<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Maintains rights and supplies evidence<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Checks eligibility<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">LOA<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Authorized party signs<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Supplies requirements and reviews it<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">IRR and ROA changes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Makes or approves authorized changes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Supplies agreed routing details<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Provider network routing<\/span><\/td>\n<td><span style=\"font-weight: 400;\">States requirements<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Configures its network service<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Customer BGP software<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Operates it unless management is included<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Maintains the provider side<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Server addressing and firewall<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Configures and tests unless included<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Supplies the network handoff<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Reverse DNS<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Maintains records or delegates control<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Handles records where agreed<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Abuse response<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Investigates workload activity<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Applies network policy and support procedures<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Migration<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Prepares applications and rollback<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Coordinates provider-side changes<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">For leased IPs, include the lessor\u2019s response times and contact details. A hosting engineer cannot correct a ROA if another organization controls it and has not authorized the change.<\/span><\/p>\n<h2><b>Confirm How the Block Reaches Your Servers<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">An Internet announcement gets traffic to the provider\u2019s network. The provider must then deliver it to the correct server or routing device.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Common arrangements include a static-routed block, a gateway-based subnet, or customer-managed BGP. Confirm the next-hop address, subnet configuration, permitted source addresses, and management connection.<\/span><\/p>\n<h3><b>Plan for Virtual Machines and Multiple Hosts<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">A block routed to one<\/span><a href=\"https:\/\/atalnetworks.com\/fr\/bare-metal-servers\/\"> <span style=\"font-weight: 400;\">Serveur nu<\/span><\/a><span style=\"font-weight: 400;\"> does not automatically work across every host in a cluster.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For virtual machines, agree on:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Host and guest routing.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gateway placement.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VLAN requirements.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Connectivity between physical servers.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Firewall and source-address restrictions.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Cherry Servers documents one practical limitation: servers in different network segments may not share the Layer 2 connection required for a common VM gateway subnet.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Keep management access available through a separate working path during configuration. A mistake in customer routing should not remove your only way to reach the server.<\/span><\/p>\n<h2><b>Plan Migration and Acceptance Testing<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Keeping the same IP addresses can reduce configuration changes, but it does not guarantee a migration without interruption.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Consider a business moving an API that partners access through IP allowlists. BYOIP may preserve the endpoint address. The business still needs the application, certificates, data, firewall rules, and return routing ready at the destination.<\/span><\/p>\n<h3><b>Prepare the Handoff<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Use a written migration sequence:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Obtain acceptance for the prefix, workload, and target location.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Prepare the server and test the application through an available temporary path.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Align permissions, IRR records, ROAs, and provider filters.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Agree on the existing route\u2019s withdrawal and the new announcement.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Set rollback triggers and name the person who can authorize them.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Move traffic during the agreed window.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Record the result before retiring the previous service.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">Do not assume that starting a second announcement is a safe migration method. Planned anycast or multihoming can use multiple paths, but an unplanned overlap may send traffic to the wrong location.<\/span><\/p>\n<h3><b>Test Beyond Prefix Approval<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Provider approval, active advertisement, server reachability, and working applications are separate milestones.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">DigitalOcean\u2019s documentation illustrates this distinction: a provisioned prefix needs advertisement enabled before it becomes reachable through the Internet.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Check external route visibility, inbound and outbound traffic, expected source addresses, application ports, and partner access. Test both IPv4 and IPv6 where applicable.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Existing TCP connections may break during the move even when the IP remains unchanged. Application state and connection handling need their own recovery plan.<\/span><\/p>\n<h2><b>Manage Reputation, Reverse DNS, and Security<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">BYOIP carries operational responsibilities beyond routing.<\/span><\/p>\n<h3><b>Maintain Reverse DNS and Geolocation<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Confirm who controls PTR records and whether the provider needs reverse DNS delegation.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Check geolocation independently. Moving a server or changing the origin ASN does not automatically update every third-party location database. Geofeeds and correction requests may help, but each database has its own process.<\/span><\/p>\n<h3><b>Keep Reputation Checks Relevant<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Review the destinations and reputation sources that matter to your workload. Retaining an IP preserves its address identity, including potentially troublesome history.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">BYOIP does not guarantee acceptance by every service or permanent removal from blocklists. Maintain current abuse contacts and respond to compromised workloads promptly.<\/span><\/p>\n<h3><b>Confirm DDoS Coverage<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Ask whether the protection offered with the server also covers your imported prefix. Establish any routing requirements, traffic limits, or conditions.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Document who can request traffic blocking during an attack and who approves restoration. Do not assume that a standard server feature applies unchanged to every customer-address arrangement.<\/span><\/p>\n<h2><b>Review Costs, SLA Coverage, and Exit Terms<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">BYOIP can involve costs beyond the dedicated server and address lease.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ask about setup fees, per-prefix charges, additional locations, BGP sessions, managed configuration, change requests, and bandwidth.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A service advertised without an import fee may still charge for custom network work. Compare the complete scope rather than one line in a pricing table.<\/span><\/p>\n<h3><b>Separate the Server SLA From BYOIP Coverage<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">The server\u2019s availability commitment may not cover customer routing errors or every BYOIP function. Dedicated.com and OVHcloud publish service limits that show why the specific agreement matters.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Confirm support hours, incident ownership, and which changes need a network-team request.<\/span><\/p>\n<h3><b>Plan Removal Before Canceling Hosting<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Leaving a provider requires another coordinated network change.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Move services, confirm the replacement routing, withdraw the previous announcement, and remove old assignments. Update authorizations when they are no longer needed, while protecting any agreed rollback period.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Also review reverse DNS, provider access, and lease expiry. Retaining the hosting account does not extend an expired IP lease, and canceling hosting does not necessarily end every address-related agreement.<\/span><\/p>\n<h2><b>Common BYOIP Problems and First Checks<\/b><\/h2>\n<table>\n<tbody>\n<tr>\n<td><b>Problem<\/b><\/td>\n<td><b>Start by checking<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Provider rejects the request<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Address rights, block size, location, and permitted workload<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Prefix approved but unreachable<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Advertisement status, origin records, filters, and delivery route<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Traffic arrives but replies fail<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Return routing, source address, firewall, and source-address policy<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Host works but VMs do not<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Guest routes, gateway, VLAN, and network-segment requirements<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Only some destinations fail<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Remote policy, reputation, and path-specific reachability<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Traffic still reaches the old host<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Previous announcements and the agreed withdrawal sequence<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Collect source and destination addresses, timestamps, application errors, and tests from both ends where possible. This helps the provider distinguish a local configuration fault from behavior outside its network.<\/span><\/p>\n<h2><b>Prepare Your BYOIP Request for Atal Networks<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Before discussing<\/span><a href=\"https:\/\/atalnetworks.com\/fr\/dedicated-servers\/\"> <span style=\"font-weight: 400;\">Serveurs d\u00e9di\u00e9s<\/span><\/a><span style=\"font-weight: 400;\"> with our team, gather your prefixes, resource-holder details, lease status, intended ASN arrangement, and current announcement information.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Include the target location, workload, bandwidth needs, server or VM layout, security requirements, and migration window.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Notre<\/span><a href=\"https:\/\/atalnetworks.com\/fr\/lease-ipv4-ipv6-asn\/\"> <span style=\"font-weight: 400;\">IPv4, IPv6, and ASN leasing page<\/span><\/a><span style=\"font-weight: 400;\"> lists LOA, route objects, and RPKI among its IP-service features. Confirm acceptance of customer-supplied prefixes and the exact deployment scope with us before placing an order.<\/span><\/p>\n<h2><b>Questions fr\u00e9quemment pos\u00e9es<\/b><\/h2>\n<h3><b>Can I bring an IP address assigned by my current host?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Usually not without permission from the resource holder. A fixed or dedicated IP is not automatically portable. Check the address agreement first.<\/span><\/p>\n<h3><b>Can I use leased IPv4 addresses with BYOIP?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Yes, where the lease permits the arrangement and the receiving provider accepts it. The authorized resource party must support the required records and permissions.<\/span><\/p>\n<h3><b>Do I need my own ASN or BGP session?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Not always. Some providers announce customer prefixes themselves. Customer-managed BGP and public ASN requirements depend on the selected service.<\/span><\/p>\n<h3><b>Can I bring a single IP address or a \/29?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Generally not as an independent globally announced prefix. Smaller allocations may work within a larger accepted block under a provider-specific arrangement.<\/span><\/p>\n<h3><b>Can several dedicated servers use the same block?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Yes, if the provider supports the required routing and allocation method. Confirm gateway, VLAN, and location restrictions before designing the deployment.<\/span><\/p>\n<h3><b>Does BYOIP guarantee zero downtime?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">No. It preserves eligible addresses, but applications, routing changes, connection state, and recovery procedures still affect availability.<\/span><\/p>\n<h3><b>Who manages IP reputation and reverse DNS?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Assign both explicitly. Workload behavior usually remains the customer\u2019s responsibility. Reverse DNS depends on delegation and the agreed management service.<\/span><\/p>\n<h3><b>Can I keep the addresses after canceling the server?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Only while your resource rights or lease remain active. Coordinate provider withdrawal and the next deployment before cancellation.<\/span><\/p>\n<h2><b>Recommended Next Steps<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Confirm that your address space is eligible, identify who controls its records, and agree on the provider\u2019s delivery method. Then document migration, testing, support, and exit responsibilities.<\/span><\/p>\n<p><a href=\"https:\/\/atalnetworks.com\/fr\/contact-us\/\"><span style=\"font-weight: 400;\">Discuss your IP prefixes, server location, and BYOIP requirements with Atal Networks.<\/span><\/a><\/p>\n<p>&nbsp;<\/p>","protected":false},"excerpt":{"rendered":"<p>Moving to a new dedicated server can mean updating customer allowlists, API connections, and services tied to existing IP addresses. [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":24840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24833","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-grade-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/posts\/24833","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/comments?post=24833"}],"version-history":[{"count":3,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/posts\/24833\/revisions"}],"predecessor-version":[{"id":24853,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/posts\/24833\/revisions\/24853"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/media\/24840"}],"wp:attachment":[{"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/media?parent=24833"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/categories?post=24833"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atalnetworks.com\/fr\/wp-json\/wp\/v2\/tags?post=24833"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}