There is a moment in every hosting career when you realise an IP address is not a property of your server. It is a property of the network, and the network can take it back, move it, or stop announcing it to the world at any time. Understanding when and why that happens is the difference between designing failover that works and designing failover that works until the day you need it.
This guide covers how IP addresses actually reach your UK dedicated server — the BGP announcement chain from your provider to the rest of the internet — what a failover IP really is, how null-routing interacts with both, and what to ask a provider before you build anything that depends on an address staying stable.
How your server's IP address actually works
Your server does not own its IP address. Your provider does. They own or lease a block of addresses — allocated to them by a regional internet registry, in the UK's case RIPE NCC — and they announce that block to the rest of the internet using BGP, the Border Gateway Protocol.
Here is the chain. RIPE allocates, say, 185.99.254.0/24 to your provider. Your provider's edge routers announce that prefix via BGP to their upstream transit providers. Those upstreams propagate the announcement to their peers, and within minutes every router on the internet knows that traffic for 185.99.254.x goes to your provider's network. Inside that network, your provider routes the specific address — say 185.99.254.42 — to the physical server you rent.
Three things follow from this, and all of them matter operationally:
- Your IP lives in your provider's routing tables. If they withdraw the BGP announcement for the block — deliberately, or because of a router misconfiguration — your server becomes unreachable from the internet while remaining perfectly healthy. From your server's point of view, nothing is wrong. From everyone else's, you do not exist.
- Routing changes propagate in minutes, not instantly. BGP updates travel hop by hop, and stale routes can linger for minutes to hours depending on path attributes. This is why "the site is down for some users but not others" is a classic routing-failure symptom, not user imagination.
- The address is only yours by contract. Move providers and you generally cannot take it with you, unless you own your own PI (provider-independent) space and announce it yourself — which is a different, more expensive game involving your own ASN and either your own routers or a BGP-capable transit arrangement.
What a failover IP actually is
Most UK providers sell, or include, a "failover IP" or "floating IP" alongside the server's main address. The marketing implies magic. The reality is simpler and still useful: a failover IP is an address that the provider can re-route, at their network layer, from one physical server to another, usually through their control panel or an API call.
The mechanism is internal routing, not BGP. The address stays inside the provider's announced block. What changes is the internal next-hop — which rack, which switch port, which physical machine the traffic is delivered to. Because the change happens inside one autonomous system, it takes seconds to minutes, not the propagation time of a fresh BGP announcement to the world.
What this buys you is decoupling: your customers and your DNS records point at the failover IP, and you can move the service behind it from machine to machine without touching DNS. DNS TTL is the thing that usually betrays you in a failover — a cached A record with a 24-hour TTL keeps sending users to a dead box long after you have moved. A failover IP sidesteps that entirely, because the address never changes even though the machine does.
What a failover IP does not buy you
It is not high availability on its own. The re-route is a manual or scripted action — something has to detect the failure and trigger the move. If your monitoring does not notice the primary is down for ten minutes, your failover IP moves ten minutes late. And the failover IP is only as good as the provider's internal network; if the failure is upstream of their edge rather than at your server, moving the IP changes nothing.
The other silent limitation: failover IPs move between servers, not between providers. If your entire provider has an outage — and single-datacentre providers do, several times a year, somewhere — a failover IP routed inside their network fails with the network. Real cross-provider failover requires either DNS-based failover with honest, low TTLs, or provider-independent IP space you announce yourself.
Anycast: the same address, everywhere
The biggest DNS services and CDNs run a trick that inverts everything above: they announce the same prefix from many locations at once. Because BGP routing is shortest-path by nature, each user's traffic goes to whichever announcing node is network-closest. If a node dies, its announcement is withdrawn and traffic re-converges on the surviving nodes within seconds — automatically, because BGP does the failing-over.
You cannot set this up on a single dedicated server. What you can do is put an anycast service in front of one: this is precisely what Cloudflare and similar CDNs are. Your visitors hit anycast edge nodes around the world; the edges pull from your UK origin over fixed routes. Your origin IP never appears in public DNS at all, which also hides it from direct-to-origin attacks.
Null-routing: where DDoS meets routing
When a provider null-routes an address under DDoS, they are doing the most blunt thing routing allows: announcing your own address to the blackhole. Every packet heading for your IP is dropped at the provider's edge. It protects their network and their other customers. It also takes your server off the internet completely, which is why attack-driven null-routes feel so much like outages — they are outages, administratively imposed.
Two practical consequences. First, null-routes usually have a fixed duration (commonly 1 to 24 hours) because the announcement needs actively withdrawing afterwards; ask your provider both their null-route threshold and the duration. Second, this is another reason a failover IP is worth having: when your main address is blackholed, moving the service to a failover IP restores reachability immediately, as long as the attack is targeting the address and not your whole server's uplink.
Reverse DNS and email: the routing detail that bites later
One thing people discover only when their mail stops delivering: reverse DNS (PTR records) for an IP are controlled by whoever the registry believes controls the address — normally your provider, not you. If you move a service to a failover IP and start sending mail from it without a matching PTR record and a sane HELO, receiving mail servers will spam-folder or reject you. Before using any IP for outbound mail, ask your provider to set the PTR, and check it with a dig -x lookup before your first send.
What to ask a provider before you depend on any of this
- How many failover IPs are included, and how fast does a re-route take effect? Answers range from "instant, API-driven" to "open a support ticket." The first is an automation tool; the second is a suggestion.
- Can failover IPs move between servers in different racks or only within one chassis/switch? A failover IP that can only move within the same physical host protects you against almost nothing.
- What is your null-route threshold and duration? This number determines how small an attack takes your address off the internet, and for how long.
- Do you support BGP sessions for customers? If you ever want to announce your own PI space from their rack, you need a provider that offers this — most budget hosts do not.
- Who controls PTR records, and is there a self-service panel? If it is ticket-only, factor days into any mail-serving migration.
What ServerCabin does
Our approach, plainly stated: every dedicated server includes a routable failover IP that can be re-pointed between servers via our control panel, with changes taking effect within seconds because the re-route happens at our edge rather than through a ticket queue. We publish our null-route threshold rather than hiding it, and we support customer PTR updates in the same panel. We do not offer customer BGP sessions on standard dedicated plans — if you need to announce your own address space, tell us during the sales conversation and we will tell you honestly whether we are the right provider for that, because sometimes we are not.
If you are evaluating providers and want the broader checklist, our guide to choosing a UK dedicated server provider covers the questions beyond networking, and our DDoS protection guide covers the attack side of the null-route problem in detail. You can also email us with your workload details and we will tell you what fits, including when the answer is not us.
The bottom line
An IP address is a routing decision that happens to be stable most of the time. Failover IPs make the decision movable within one provider's network, anycast front-ends make it movable globally, and null-routing shows you exactly how movable it is when the network is under pressure. Design your failover knowing which layer moves and which layer does not, and you will not be the person whose "high availability" setup turned out to depend on a ticket queue answering at 3am.