Skip to content
🤠 bgp.rodeo

Photo: S A / Unsplash

Bring your own ASN: BGP sessions on Greybull VPSes

greybullbgpvpsrpkipeeringdb

For a while now, the question I get most from people who’ve just got their first ASN is some version of: “Where do I actually announce this thing?”

Getting the ASN and a /48 is the easy part these days. Finding somewhere to run the BGP session is harder. The big clouds don’t want your prefixes. Some small providers take them, but they want a ticket, a LOA, and a few days of back-and-forth. And a lot of people just want to put a prefix on the internet from a small VPS to learn how it works. That’s how I started too, back at Coloclue.

So I built it. Compute instances on Greybull, the hosting side of my company, can now run BGP sessions with AS202585.

What you get

  • Two BGP sessions per address family, one to each of the two routers in Enschede (rtr01 and rtr02), over IPv4 and IPv6. If one router is down for maintenance, your prefixes stay up via the other.
  • Your choice of routes: a default route only, or the full table. Pick “default” if you just want to announce and route out, and “full” if you want to play with path selection. You can change it per peer, and the change reaches the routers immediately.
  • Your prefixes, announced via AS202585 to transit and at the IXPs I’m connected to.
  • Large communities on your routes, so you can see where they came from: (202585, 1, 3) for customer-learned, (202585, 2, <your ASN>) for the origin, and (202585, 9, 2) for the Enschede PoP.

The VPS itself is a normal Greybull compute instance, from €4.99 a month. BGP runs on top of it at no extra cost; it’s not a separate product.

How it works

The part I’m proudest of is that the common case needs no humans.

1. Prove you own the ASN via PeeringDB. You link your PeeringDB account to the portal with OAuth. When you add a peer, the portal asks PeeringDB live whether you’re an admin of that network. If you are, the ASN is yours as far as I’m concerned. No LOA, no emailing a PDF, no waiting. It does mean your network needs a PeeringDB entry, which it should have anyway.

2. Add your prefixes, which are checked against RPKI. Every prefix you add is looked up in IRR Explorer straight away:

  • RPKI valid for your ASN: approved on the spot.
  • RPKI invalid: rejected, with a message explaining that a ROA exists and it doesn’t match you. Fix the ROA, or talk to whoever holds the space.
  • Not found (no ROA at all): goes into a queue for me to review by hand, the old-fashioned way. Create a ROA and this step goes away, which you should do anyway.

3. The routers get configured. A small agent runs next to BIRD on each router. The portal renders a peer config, the agent writes it to peers.d/, checks it with bird -p, and runs birdc configure. Nobody SSHes in. A reconciler also runs periodically, so the routers always match what the portal says, even after a failed push.

4. Your ASN joins my AS-SET. Upstreams and IXP route servers build their filters for me from AS202585:AS-RODEO in the RIPE database. The portal adds your ASN to it automatically, so you don’t wait on me to update IRR objects.

The filtering

Every customer session gets its own import filter, generated from what the portal knows:

filter cust_AS65000_vm123_v6_in {
  if (roa_check(r6, net, bgp_path.last) = ROA_INVALID) then reject;
  if net !~ [
    2001:db8:1000::/48
  ] then reject;
  bgp_large_community.delete([(202585, *, *)]);
  bgp_local_pref = 400;
  bgp_large_community.add((202585, 1, 3));
  bgp_large_community.add((202585, 2, 65000));
  bgp_large_community.add((202585, 9, 2));
  bgp_large_community.add((202585, 100, 1));
  accept;
}

In order:

  • RPKI invalids are dropped on the session itself, not just at the edge. If your ROA changes after approval, the route disappears.
  • Only your approved prefixes are accepted. Anything else you announce, by accident or not, stops at my router.
  • Large communities in my namespace are removed before I add my own. My export policy uses those tags, so letting a customer set (202585, *, *) would let them steer my announcements. Your own communities and well-known ones like NO_EXPORT pass through untouched.
  • Export to upstreams keys on (202585, 100, 1), a tag only the portal-managed sessions add. I learned that one the hard way. An earlier version keyed on the generic “customer route” tag. My older, hand-built customer sessions set that tag too, so their routes suddenly matched the export filter as well, and the extra prefixes blew straight through the tight export limits on my transit sessions.

On top of that there’s an import limit per session: go over it and the session restarts, which is better than leaking. There’s also BCP38 on the way out. When a prefix is approved, the agent adds it to an nftables allow-set on the routers, so your VPS can source traffic from your own space and from nothing else. My own space is in a separate, hand-maintained set, so a broken push can never cut off AS202585’s own traffic.

Who this is for

  • People with a fresh ASN who want their first announcement to happen somewhere forgiving. If you’re following along with my first BGP session guide, a Greybull VPS is a place to try it.
  • Anycast experiments. Announce the same prefix here and from somewhere else, and watch where traffic goes.
  • Small networks that want a cheap, filtered presence in the Netherlands, in Enschede with a private backbone to Amsterdam.

It’s not a transit product for your whole network. It’s a VPS that happens to speak BGP, run by someone who cares whether your filters are right.

Getting started

Sign up at greybull.nl and create a compute instance. BGP is on for every account, so there’s nothing to request. Everything above happens in the portal: link PeeringDB, add your ASN and prefixes, and the connection details for both routers show up once the sessions exist.

If something doesn’t work, or you think one of my filters is wrong, I’d like to hear it. That feedback is useful to me.

← Back to all posts