You contract a second line with a different ISP, set up failover on the firewall and test it by unplugging the main one: browsing comes back within seconds and the matter is closed. That test measures what leaves the office. What comes in — your VPN, your mail, the portal your customers use — is travelling towards an IP address that still belongs to the first ISP.
We are writing this as a network operator: everyWAN runs its own network, ASN, transit, peering and a public looking glass at lg.everywan.com. Which means we sell precisely what is about to be described, and that is why the article includes the list of cases where you do not need to buy it. Without that list, this would be a brochure.
The second line does not move your IP: it replaces it
The fixed IP addresses your ISP gives you belong to them. They sit inside a larger block that this ISP announces to the rest of the internet, and unless the owner authorises it in writing — which they almost never do — no other ISP is going to announce them for you. On top of that, what you are handed is usually a handful of addresses, a /29 or smaller, well below what the rest of the internet accepts as an announcement. So when the main line drops and the firewall shifts traffic to the second one, your published services change address, not path.
And changing address comes with a bill paid in several places at several different times. DNS records point at the old one until the TTL expires, and the TTL outranks anybody's urgency. Open sessions — terminal server, the ERP desktop client, the accountant's remote desktop — are dropped. Tunnels to head office or to a customer, if they are built against an IP rather than a name, stop negotiating. And then there is the step nobody writes into the minutes: the third parties holding your IP on an allow list. The bank, the e-invoicing platform, the supplier on EDI, the registry that only accepts queries from an address declared in writing. None of them updates that list within fifteen minutes because you had an outage.
It is the same trap we described in redundancy is not route diversity, one level up. There the problem was that two separately contracted lines shared the same trench. Here they share something worse: the identity people use to find you.
Three ways to have two paths
Lined up, there are three real options, and what tells them apart is what happens to the IP address when something fails.
- Two lines from the same ISP. The address can stay, because it still belongs to the same owner and they decide where to hand it over. It covers a failed router, a failed patch lead or a failed access circuit; it does not cover the ISP having a problem inside their own network, nor a fibre cut affecting both accesses if they share a route. It is the cheapest option and the easiest to buy, which is why it is the one most often sold as "redundancy".
- Two ISPs, each with its own range. You go out through whichever works, and for outbound traffic it genuinely solves the problem. For inbound, the address changes with the outage: that is the move described above, with its TTL, its dropped sessions and its third-party allow lists. It can be softened — low-TTL DNS, names instead of IPs in tunnels, service checks run from outside — and for many companies that is enough. The expensive version is finding out on the day of the outage.
- A block of your own, announced by you to two ISPs. You need an autonomous system number (ASN) and your own prefix. Both ISPs announce your prefix to the rest of the internet; if one goes down the route survives through the other and the address does not move. It is the only item on the list that keeps your identity intact even when the problem sits inside the ISP's network rather than on the access circuit, and the only one that makes you the administrator of a piece of the global routing table.
The numbers for owning your own block, 2026 edition
The RIPE NCC charging scheme for 2026 sets EUR 1,800 per year per LIR account, plus EUR 50 for each ASN assigned and EUR 75 for each independent resource assignment — the common ones there are IPv4 and IPv6 PI, anycast and IXP assignments. Signing up costs EUR 1,000 once. Added up: EUR 2,850 in year one if all you hold is the ASN, and EUR 1,850 afterwards; EUR 1,925 if you also keep an independent resource.
For many companies that figure is manageable, and that is usually where the enthusiasm starts. The problem is not the money: it is that there are no IPv4 addresses to buy with it. RIPE's own page says it plainly: "While we have run out of IPv4 addresses, RIPE NCC members can still request a single /24 allocation", and adds the condition that rules out most of the industry, "Existing members can only submit a request if they have never received an IPv4 allocation from the RIPE NCC before (of any size)". That request joins a waiting list fed by addresses recovered from companies that shut down. There is no date.
That leaves two ways out. One is the transfer market: you buy a /24 — 256 addresses, the smallest piece global routing accepts in practice: RFC 7454, which collects BGP operational good practice, notes that "IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet" — from somebody who holds one and no longer uses it. Prices are published by brokers and swing by region and block size; IPv4.Global, one of the public marketplaces, puts the range at 30 to 40 US dollars per address on its own site, referring to 2024. Do the multiplication and a /24 comes to somewhere between 7,700 and 10,200 dollars in one go: three or four times the cost of every RIPE fee put together, and the number that actually moves the budget. Treat it as an order of magnitude and ask for a price on the day you buy. The other way out is to skip IPv4 and build your own block in IPv6, which still leaves you needing IPv4 addresses borrowed from the ISP for everything that does not speak IPv6 yet — in practice, nearly everything your customers are using.
One note that saves money: you do not have to be a LIR to hold an ASN. You can request one through a sponsoring LIR: RIPE bills them the EUR 50, and you pay whatever that LIR passes on, without the EUR 1,800 annual fee. And there is a policy requirement worth reading before getting excited, because it is written on RIPE's own site: "Current RIPE Policy requires a network to be multi-homed, and have a unique routing policy for an ASN to be assigned". In other words: the ASN is not the first step towards multihoming, it is the consequence of having decided on it.
What the quote leaves out: the router and ninety seconds
If your ISPs hand you the full table, your box has to hold all of it. How much "all of it" is can be checked today. Geoff Huston's daily BGP report showed 1,076,340 active IPv4 prefixes from one of the observation points it publishes, in the sample taken at 11:01 UTC today, 27 August 2026. The Route Views feed in the same report showed 1,121,846 at 10:00 UTC that day: the number depends on where you look from, which is why it is worth saying where. You can check it in one line:
curl -s https://bgp.potaroo.net/as2.0/bgp-active.txt | tail -1
Those million-odd routes, plus the IPv6 table and the attributes of each entry, are what rule out the small firewall that had been doing its job for years. There is a way through without buying big iron — ask both ISPs for a default route only, or a partial table, and keep the redundancy without the traffic engineering — and it is a perfectly reasonable decision, worth taking deliberately, because it changes what you can do afterwards.
The other surprise is the clock. BGP does not notice its neighbour has vanished until the hold timer expires, and the default value suggested by RFC 4271 is ninety seconds, with keepalives at one third of that. The same document also suggests spacing announcements to an external neighbour thirty seconds apart. Translated: if the line does not fail outright but stops passing traffic with the interface still up, default failover takes a minute and a half. It is fixable with two specific things: lowering the timers by agreement with the ISP, and enabling BFD, which — if the ISP offers it on that service — brings detection down from ninety seconds to a few hundred milliseconds. Neither ships enabled.
Keeping the announcement alive, every day
Announcing a prefix means entering a permanent conversation with the rest of the internet, and that conversation needs upkeep. You have to sign RPKI ROAs so your origin is verifiable, maintain the objects in the routing registry so other people's filters let you through, and tell both ISPs every time something changes. And you have to know that signing is not the same as being protected: we went into it in RPKI will not stop your route being hijacked, because a ROA validates where the announcement starts, not the path it takes.
There is one advantage that only pays out on the day of the attack. With your own prefix and BGP you can ask your ISPs to drop traffic towards a specific address inside their network — that is RTBH — and shed a denial of service before it saturates your access line, at the price of that address receiving nothing at all any more, the good traffic included: you sacrifice one IP to save the rest. Without your own prefix you depend on the ISP being willing and able to do it for you. We covered it in detail in why the firewall will not save your link in a DDoS: useful mitigation happens upstream, and having your own announcement is what gives you a voice upstream.
When you do not need any of this
If your office only sends traffic out — people browse, use cloud mail and third-party applications — and nothing is published that somebody has to reach from outside, your own block adds nothing that justifies the fee. Two ISPs and a box that knows how to switch over solve the whole case. And if you have several sites and the problem is spreading traffic across different transports, the answer is usually in SD-WAN: when it pays off and when it is overkill, not in the global routing table.
You do not need it either if everything you publish lives behind a CDN or a reverse proxy: in that case the address the world sees is the provider's, not yours, and the conversation moves to how that provider reaches your origin. And you do not need it — this is the important one — if nobody in your company is going to maintain it. A badly kept prefix, with expired ROAs or stale filters, is worse than not having one: it takes you off the internet on an ordinary Tuesday without a single line having failed.
You do need it when the list of what comes in is long and expensive to move: a remote-access VPN pinned to a fixed IP, a mail server whose reputation is built on one specific address, customer integrations that declared your IP in writing, a portal with long sessions. At that point the question stops being what the ASN costs and becomes what the hour costs during which your address is not the one everybody has written down.
What breaks when your IP changes?
Making that list — what comes in, against which address, and who has it written down outside — is where we start when we design networks and communications design we do, and it often ends with you not needing an ASN at all, but rather sorting out how traffic is shared between sites. When it is genuinely needed, we are a network operator with our own network and we can be one of your two paths.
Talk to everyWANSources
Fees: RIPE NCC Charging Scheme 2026 (document ripe-848), the source of the EUR 1,800 per LIR account, EUR 75 per independent resource assignment, EUR 50 per ASN and the EUR 1,000 sign-up fee, as well as the list of resources covered by the EUR 75 charge. IPv4 status and the ASN policy requirement: official RIPE NCC pages on IPv4 and on autonomous system numbers. Secondary market range: figure published by IPv4.Global on its own site and referring to 2024, quoted as an order of magnitude rather than a current price. Timers: RFC 4271, section 10, "BGP Timers" — ninety seconds of suggested HoldTime, KeepaliveTime at one third of it, and thirty seconds of minimum advertisement interval on external sessions. Table size: Geoff Huston's daily BGP report (bgp.potaroo.net), file bgp-active.txt, sample taken at 11:01 UTC on 27 August 2026, retrieved by us with the command shown in the article; the Route Views figure (1,121,846 at 10:00 UTC the same day) comes from the equivalent file in the same report. Two views giving different numbers is normal: each collector sees what its neighbours announce to it. Which is why this number cannot be compared with the 1,445,943 routes we published on 6 August from Cloudflare Radar, which adds IPv4 and IPv6 together and aggregates dozens of observation points. Minimum prefix length: RFC 7454, section 6.1.3, citing the practice documented by the RIPE community. The effect of default timers on a real failover is an observation from our own work as a network operator, not from the sources cited. So are the opinions on when this pays off and when it does not.