Multihoming

What it requires

• Your own address space — a /24 or larger for IPv4 — see bring your own IP space
• Your own AS number
• A router that can hold the sessions, and someone who understands BGP
• Route objects and valid RPKI ROAs for everything you announce

Without your own space you are not multihoming; you are using two providers' addresses, and failover means renumbering.

Outbound: you decide

Local preference on your router chooses which provider your traffic leaves by. It is entirely under your control, and it is the easy half.

Two sensible patterns: prefer the cheaper or better-performing transit and use the other as backup, or balance by destination. You do not need a full routing table to do either — taking default routes plus your providers' customer routes gives you most of the benefit with a fraction of the memory.

Inbound: you persuade

You cannot control how the rest of the internet reaches you. You can influence it:

• AS path prepending — announce your prefix with your own AS repeated, making that path look longer. Blunt, widely honoured, and the usual first tool.
• Communities — precise. Most providers publish communities that let you ask them to prepend to specific peers, or not announce a prefix in a region at all. Ask us for ours.
• More specific announcements — effective and antisocial. Splitting a /23 into two /24s works because longest prefix wins, and it adds entries to every routing table in the world. Use sparingly, and check your ROA max length allows it.

The leak you must not cause

The classic multihoming accident: you accept routes from provider A and announce them to provider B. You have just offered to carry traffic between two large networks over your small connection, and it will arrive.

Prevent it explicitly. Announce only your own prefixes, with an outbound filter listing them, on every session. Do not rely on your providers to catch it, even though we will.

Fail over faster than BGP does

Default timers take tens of seconds to notice a dead neighbour. Enable BFD if your router and ours support it, and failure detection drops to well under a second. Worth it when traffic is dropping in the meantime.

Test it on purpose

Shut one session during a maintenance window and watch what happens: does traffic move, how long does it take, does everything still work on the remaining path? An untested failover is a theory, exactly like an untested restore.

With us

We are happy to be one of your upstreams, and Amsterdam makes that straightforward because the alternatives are a cross-connect away — see why Amsterdam. Start with running BGP with us; the session is set up by an engineer talking to an engineer.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base