A couple years ago, Vultr provided the ability to bring your own IP space and announce it via BGP. (Update: note that this was originally written in 2018)

My hope was that this was a precursor to them offering IP Anycast, similar to BuyVM but with the numerous Vultr locations (BuyVM has 3).

I waited. And waited. And waited…. almost 3 years later, no further announcements. It was time to do this the hard way!

Note that this was a new endeavor for me, so if you’re coming at this from a newcomer perspective (like I was), hopefully something in the following write-up helps you.

–

Preparation: IPv4, IPv6, or both?

Unfortunately, the smallest blocks you can announce for IPv4 and IPv6 are a /24 and /48 respectively. IPv6 space can be had for free (or near free). IPv4 space on the other hand will currently can run you in the $100/month region depending on where you get it from.

I did consider doing IPv6 only, and leaving the IPv4 handled via GeoDNS. Once I realized that would be a lot of work for about 20% of my traffic I decided I may as well go all-in. If you’re approaching this entirely from an academic standpoint (learning), IPv6 is configured in a virtually identical way here so no need to spend unnecessary coin on IPv4.

–

Leasing the IP space

Technically you can register with an RIR and buy space from someone else, though you need exceptionally deep pockets for this.

Leasing is the cheaper option. The tough part is finding providers that lease space.

Fortunately, HostUS is one such provider. I got a small VPS from them about 4 years ago and have had it running since which gave me a little more peace of mind in choosing them. Note that IPv4 and IPv6 isn’t heavily advertised on the site – it’s under Services / Available Addons / Licenses.

After asking a few questions about the process in a ticket, I ordered both an IPv4 and IPv6 block. Worth noting they do offer ASN registration too, but I wanted to keep things as simple as possible so just bought the space since Vultr provides a private ASN if you don’t have your own.

I may have been lucky with timing, but I had the address space within a few hours (this includes back-and-forth with questions I had that they were quite patient with).

An extremely positive experience.

–

Next Stop: Vultr

Vultr has a number of guides I read in between ticket responses, and if you’re new to this I’d suggest going through them during your wait periods. Once I had the space I headed over to https://my.vultr.com/bgp/setup/ to plunk in the info.

Note that they didn’t use the password I had created – it may have been too short or they may auto-generate one anyway. I *did* request a LOA from HostUS before filling this out (which they provided me with), though I’m not sure if it’s truly needed since they email for authorization anyway.

The process from here:

1. It automatically opened a ticket and emailed the holder (HostUS in this case) for authorization.
2. Once the authorization came through, it was a wait. I took the opportunity to get some sleep.
3. I woke up to a notification that it had been set up (approx 6 hours after the initial setup), and that I’d need to restart my instances for it to propogate.
4. I restarted the instances. There was a BGP tab with info and a link.
5. I selected the link within the BGP tab. They provided an auto-filled configuration that could be copy/pasted into the BIRD config file.

I have to give Vultr a lot of credit here. Somebody spent a lot of time creating the interface and auto-generating the configs. This wasn’t a half-hearted attempt. The configs aren’t entirely complete on their own, but they are in combination with their guides.

Note that my following examples are for a dead-simple situation (1 VPS in each location).

The short of it… for a basic “up and running” solution, you should follow their guide. However if you’re getting stuck, the general process when using Ubuntu 18.04 is to start with:

sudo apt install bird

Once installed, the IPv4 config will look something like this (use the config details they provide you with in the control panel though):

#/etc/bird/bird.conf
router id 1.2.3.4;

protocol bgp vultr
{
local as 22222;
source address 1.2.3.4;
import none;
export all;
graceful restart on;
multihop 2;
neighbor 123.45.6.7 as 11111;
password "abcdefg";
}
protocol static
{
route 9.8.7.0/24 via 1.2.3.4;
}
protocol device {
scan time 10;
}
protocol kernel {
metric 64;# Use explicit kernel route metric to avoid collisions
# with non-BIRD routes in the kernel routing table
import none;
}

The IPv6 config will look something like this in Ubuntu 18.04:

#/etc/bird/bird6.conf
router id 1.2.3.4;
protocol bgp vultr
{
local as 22222;
source address 1234:abcd:1234:abcd:12:ab:12:ab;
import none;
export all;
graceful restart on;
multihop 2;
neighbor 1234:1234:1234::1 as 11111;
password "abcdefg";
}
protocol static {
route 2222:ffff:2222::/48 via 1234:abcd:1234:abcd:12:ab:12:ab;
}
protocol device {
scan time 10;
}
protocol kernel {
metric 64;# Use explicit kernel route metric to avoid collisions
# with non-BIRD routes in the kernel routing table
import none;
}

Then sudo service bird restart && sudo service bird6 restart gets things going and announcing your space. The Vultr guides mention how to check the route which you should do.

The first hiccup I hit above was that the guide implied quotes might be needed – they were not in my case, and the quotes had to be removed for the route to be picked up. The second hiccup I hit was that copy/pasting the IPv6 part from the web control panel must have picked up some bad characters and bird6 refused to work due to errors on lines. I ended up erasing and manually rewriting it all, which worked fine.

The next step is to add the IPs. If using Ubuntu 18.04 it’s done via netplan which can be found at /etc/netplan/10-ens3.yaml.

The below example is condensed but should hopefully give you enough to go on:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: yes
      dhcp6: yes
      addresses:
        - 1.2.3.4/24
        - "1111:1234:12:1234:a:a:a:a/64"
        - "1111:1234:12:1234:b:b:b:b/64"
        - 11.22.33.0/24
        - 11.22.33.1/24
        - 11.22.33.2/24

…note that the 1st IPv4 address I put in was the instance IP address since it tended to get “lost” in ifconfig, etc otherwise.

Finally sudo netplan --debug generate && sudo netplan --debug apply will hopefully get those IP addresses added (check for error messages – bad spacing or an accidental “tab” is frequently a culprit). At that point you can start testing the addresses, and finally, assign IPs to whatever services you’re using.

–

One Last Thing: The Source IP

For outgoing communications, Ubuntu wanted to use the “largest” IPv6 address. Since I had set up whitelists previously which relied on the original IPv6 addresses, I wanted to tackle this.

The short solution here (probably not the best solution mind you) is to type:

ip -6 route

…copy the line that starts with “default via….” and then do the following…

ip -6 route change COPIED_LINE src DESIRED_ADDRESS

…so it might look like this…

ip -6 route change default via 1af:3:32:ab:fa:a3:fff:aa dev ens3 things things src aa:aa:aa:ba:2a:3a:4a:5a

I ended up writing a bash script + cron job to take care of this in case of reboot (groddy). Again, there are undoubtedly better ways. But hopefully if you need to tackle this it gets you started. Keep in mind that omitting the -6 will handle IPv4 if you have to set a different default source address there too.