How we change routing without asking permission.
When most hosts need a routing change, they open a ticket with their upstream and wait. When we need one, we make it. Here is the discipline that makes that safe.
In this article 4 sections
- A host that rents its network requests routing changes. A host that owns one makes them.
- Speed without discipline is a risk. Every change on production gear follows the same written runbook, described below.
- A small, standardized set of platforms, one operating grammar: the engineers on support are the same ones who set routing policy.
There is a moment in every serious incident where somebody says the routing needs to change. What happens next depends entirely on who owns the network. A host riding a rented backbone files a ticket with their upstream and waits in somebody else's queue. We log into our own edge and make the change. Carefully, according to rules we will show you, but we make it. Nobody upstream has to approve it, schedule it, or be reminded who we are.
Owning the change
The word for this is not speed, it is agency. Because the network announces itself as our own AS, routing policy is ours to set: how traffic enters, which carrier it prefers, what gets shifted when a path degrades. Ours is the same group of engineers who answer the support line, and the router is ours.
Fast is nothing without safe
Being able to change anything in minutes is only safe with discipline, and ours is written down. These are the standing rules for touching production network gear, quoted from the actual runbook, which is written from real operations, not a whiteboard exercise:
Every change on production gear follows a written runbook: hostname verified, running config backed up, one command at a time, nothing saved to startup until verified, and a second engineer sees the plan first.
None of these rules is exotic. What matters is that they are enforced on gear we own, by people two desks from each other, instead of described in a third party's change-management document.
Why we can operate this deep
The unglamorous answer is standardization. The edge is Cisco ASR 9000 in Athens and Juniper MX204 in Amsterdam, feeding a Cisco Nexus 9000 EVPN/VXLAN fabric: a small, standardized set of platforms our engineers know end to end, one operating grammar from top to bottom. That is the networking twin of the 3PAR doctrine: when every machine speaks one dialect, the engineer on the phone at 3am can also reason about the routing, because it is the same person and the same known system. There is no escalation to a backbone owner who has never heard of you, because there is no backbone owner above us to escalate to.
The lesson for you
At 3am the question is not whether your host is friendly. It is whether the person who picks up can change the network, or whether they are waiting on someone upstream with a queue, a change board, and no idea who you are. That single capability, held or not held, is most of the difference between an incident that lasts minutes and one that lasts a night.
Straight answers
You really don't need anyone's permission?+
For our own routing policy, no. We announce our own routes from our own AS; our upstreams carry them. Internal discipline is the permission structure: the plan is reviewed before execution, per the runbook above. What we do not need is a ticket with a third party to change how our own network behaves.
Would I get told about changes that affect me?+
Changes with customer-visible impact get a maintenance window and a heads-up. Most changes have none, which is the point of the discipline.
How do I find out whether my host owns its own network?+
It is public record. Look up who announces the IP range your server sits in: if the AS belongs to a different company than the one billing you, your host is reselling someone else's network. The full five-question checklist, lookup tools included, is in You don't own your network. That's your real lock-in.
Ask your host how fast they can reroute your traffic. Then ask us.
The people who run AS200477 are the people who pick up the phone.
Open the Sizing DeskYou’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