AS210622: Building a Multi-Homed Autonomous System as a Small Operator

Context

Most hosting companies rent everything: the servers, the address space, the routing. That works until the day your upstream makes a decision you have to live with — a peering dispute, a filtering change, a maintenance window that becomes an outage. We wanted the failure domain to be ours, so we built our own network: AS210622, with provider-independent address space and our own BGP edge.

The result is a network whose claims anyone can check. Our sessions, prefixes, and upstreams are visible on bgp.tools — we would encourage you to verify any operator's claims there, including ours.

Constraints

We are a small operator. There is no 24/7 NOC, no team of network engineers on rotation, no budget for equipment that exists to impress a datacenter tour. Every design decision flows from that honesty:

• Conservative over clever. Three well-understood transit sessions we can reason about at 3 AM beat a complicated topology we can't.
• Automation over headcount. Anything done twice by hand gets encoded — in filters generated from IRR data, in monitoring, and eventually in birdy, the BGP management tool we built because we needed it ourselves.
• No aspirational capacity. We advertise what we can back up, not a marketing number.

Approach

We are multi-homed across three independent upstreams, so no single provider can take us offline:

Transit:
├── Digi Romania / RCS & RDS (AS8708)  — 10G, primary
├── NAV Communications (AS6718)        — 1G
└── ParadoxNetworks / PDXnet (AS52025) — 1G

On top of that sit the practices that keep a routing table honest:

• RPKI validation on every session — invalid routes are dropped, not observed. This is the single highest-leverage protection against route hijacks.
• IRR-based prefix filtering — every prefix we accept is verified against RIPE's IRR database, and our own objects are maintained so others can filter us just as strictly.
• Deliberate traffic engineering — local-pref for outbound decisions, measured prepending and communities for inbound. We wrote up the details in our BGP traffic engineering post.

The edge also carries our security tooling: the routers feed the live threat map on this site, and the same infrastructure informed the DDoS posture we described in DDoS mitigation at the network edge.

What was hard

Getting the first session up is easy; being a good citizen is the work. Filters, ROAs, IRR objects, and route hygiene are unglamorous, and nobody notices them until they're missing. We treated them as launch requirements, not follow-ups.

Inbound traffic engineering is negotiation, not control. You can decide where your traffic leaves; the internet decides where it enters. With three upstreams of very different sizes, balancing inbound took measurement and iteration rather than one clever config.

Knowing what we are not yet. AS210622 is transit-only today — no IX port. Peering at an exchange is where latency and transit economics genuinely improve, and it is the next thing we want to fix. We say so plainly because the alternative — implying connectivity we don't have — is exactly the kind of claim bgp.tools would contradict in one click.

Where it stands

AS210622 is in production, multi-homed, RPKI-validated, and carries our hosting platform and edge security pipeline daily. The full build story is in Building a Resilient Network, and the operational tooling it produced — including a web UI for BIRD that renders the entire config with an armed auto-revert — is open source.

If you want a network partner who runs their own — or help designing, automating, or auditing yours — talk to us.