Redundant, according to whom?
"Fully redundant network" means nothing if someone else controls the failover. Here is how to check any host's real upstreams yourself, in thirty seconds.
In this article 3 sections
- Every hosting page claims a "fully redundant network." The claim has two problems: redundancy is only real if the claimant controls the failover, and almost nobody checks.
- Many hosts are tenants on someone else's backbone: one upstream, rented capacity, redundancy by permission. When that upstream has a bad day, so do they, and so do you.
- Ours is checkable: AS200477 operating across Athens, Amsterdam, and Toronto, multi-homed on multiple carriers (global Tier-1 transit and regional incumbents), peering at GR-IX and NetIX, on IPv4 space we hold directly from RIPE.
- You can verify every word of that on the public routing table yourself. This post shows you how, for us and for whoever hosts you now.
Look at any hosting feature grid and you will find it, sitting between "NVMe SSD storage" and "24/7 support" like a fact of nature: Fully redundant network. A checkmark, a tooltip if you are lucky, and on to the next tab. Nobody stops on it. It reads as settled.
It answers none of the questions that matter. Redundant at which layer, the switch or the carrier or the route? And when a path actually dies at three in the morning, who decides the traffic goes the other way, and how long do they wait for permission to do it? The checkbox is silent on all of it, which is convenient, because those are the only questions whose answers change what happens to your site.
Redundancy is a chain of custody
When a carrier fails, someone has to decide that traffic takes the other path. That decision is the whole product. If your host owns its AS and runs its own routing, the someone is your host, acting in minutes on its own gear. If your host is a tenant on a rented backbone, the someone is an upstream's NOC, working a priority list your host does not set, and your host is on hold with everyone else that carrier just dropped. Same word on the sales page. Completely different at three in the morning.
| REDUNDANT ON PAPER | REDUNDANCY YOU CONTROL |
|---|---|
| One upstream, rented capacity, an SLA about someone else's network | Your own AS, multi-homed across independent carriers |
| Failover decided in someone else's NOC | Failover decided on your own edge, by your own engineers |
| IP space leased from the provider you're trying to survive | Address space held directly from the registry |
| THE ROW THAT SETTLES ITVerifiable: nothing | Verifiable: all of it, on the public routing table |
What ours looks like, stated checkably
Our autonomous system, AS200477, operates across our datacenters in Athens, Amsterdam, and Toronto. We are multi-homed on multiple transit providers, including global Tier-1 carriers and regional incumbents, and we peer at internet exchanges including GR-IX and NetIX. Traffic rides IPv4 space we hold directly from RIPE, so it does not change hands when you scale. Routing changes happen on our own edge, run by our own engineers.
Check it yourself, thirty seconds
Find the AS
Search any host's name on bgp.he.net. Ours is AS200477. The tool resolves a company to the autonomous system that actually carries its traffic.
Count the upstreams
The peers-and-transit view shows who carries their routes. One upstream is a tenant. Two or more independent carriers is real multi-homing, the kind that survives a single carrier's bad day.
Check the exchange peering
Public exchange membership is listed on the same page. It means regional traffic takes short local paths instead of touring a distant carrier's backbone first.
Check whose address space it is
Prefixes registered to the host mean they hold their own space. Prefixes registered to their upstream mean your IP reputation is a sublet, and it moves when they change carriers.
Run the same check on us
Same tool, same check. We put the AS number in this post on purpose, because the whole argument is that you should not have to take it on faith.
An uptime number you have to take on faith. This, you can check before you ever talk to sales.
“Redundancy you don't control is a rumor someone else gets to confirm.”
The routing table proves structure, not virtue. Independent carriers can still be run badly. Directly-held space can still be misrouted by someone having a bad day. What the check settles is narrower and more useful than a quality score: who is in control when a path fails. That is the exact question the checkbox was built to skip.
Straight answers
How do I check my hosting provider's network redundancy?+
Look up their AS on a public BGP tool such as bgp.he.net or bgpview. Count the transit providers carrying their routes, and check whose name is on their address space. It takes under a minute and cannot be faked, because you are reading the live global routing table, not a sales page.
What is multi-homing and why does it matter?+
Multi-homing is connectivity through two or more independent carriers under your own routing control. When one carrier fails, your traffic re-routes because you re-route it, not because you waited for someone else to. A single-upstream host inherits every bad day its one carrier has.
Does it matter who owns the IP addresses my site uses?+
Yes. Directly-held address space means your addresses, and the reputation attached to them, stay put when you scale or when your host changes carriers. Space sublet from an upstream is a dependency wearing your name, and it can move without you.
Is peering at an internet exchange important?+
It keeps regional traffic on short local paths instead of hairpinning through a distant carrier. We peer at GR-IX and NetIX. A host's exchange memberships are publicly listed, so this is something you check rather than something you ask about.
Can a host with one upstream still be reliable?+
Until the upstream is not. The structural issue is not competence, it is control: with one carrier, every failover decision that matters happens inside an organisation that has never heard of you and does not answer to you.
Run the check. Then call whoever wins.
bgp.he.net, your host's name, thirty seconds. If the answer is one rented upstream, we should talk about what owning the network looks like.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer