Configuring BGP on Vultr

Introduction

Vultr's BGP feature allows you to bring your own IP space and use it across any of our locations. Use this guide to configure BGP for your own IP address space. We also have guides to configure BGP with floating IPs for high availability.

Prerequisites

To use BGP, you need:

• A deployed Vultr server instance.
• Your own IP space (either v4 or v6). If you have your own ASN, you can use that, or we can assign a private one.

If you are advertising an IPv4 prefix, the server instance must have an IPv4 address automatically assigned from by Vultr. If you are advertising an IPv6 prefix, the server instance must have both IPv4 and IPv6 addresses automatically assigned by Vultr.

Preliminary Setup

Please complete the BGP setup form to begin. Ensure you verify ownership of your ASN and subnet(s) to prevent delays. You will need at minimum a /24 of IPv4 space, or a /48 of IPv6 space. Smaller subnets are not routable on the internet.

Once we have approved the configuration, you will need to build a BGP session to our endpoint.

BGP on Vultr VPS

For Vultr VPS, use the following settings:

• Vultr Internal AS: 64515
• Vultr IPv4 BGP Neighbor: 169.254.169.254
• Vultr IPv6 BGP Neighbor: 2001:19f0:ffff::1
• BGP Multihop setting: 2

BGP on Vultr Bare Metal

Note: Vultr does not advertise the full internet BGP table to Bare Metal servers.

For Vultr Bare Metal, use the following settings:

• Vultr Internal AS: 20473
• Vultr IPv4 BGP Neighbor: 169.254.1.1
• Vultr IPv6 BGP Neighbor: 2001:19f0:ffff::1
• BGP Multihop setting: 2

Note: You will use the same IPv4/IPv6 address regardless of where you are connecting from. Once we have completed setup, we provide example FRR and BIRD configurations in your Vultr Console. The configurations are found on each subscription page on the BGP tab.

We will announce your prefix(es) to our upstream providers in whatever location you choose to deploy your instance. The carrier mix may be different from location to location and may cause unequal BGP paths. If you plan to use multiple locations (anycast) we cannot guarantee the even distribution of connections to your selected locations.

If your instance was deployed before BGP was setup on your account, you need to reboot it via the control panel. BGP will not work on existing instances until they've been rebooted via the control panel, rebooting via SSH is not sufficient.

BGP Configuration Steps

We recommend using BIRD as your BGP daemon (but you can use any BGP daemon you want). Most operating systems have a package available for this.

Our example assumes the following:

• AS: 64512
• Instance IP: 203.0.113.123
• IPv4 Block: 198.51.100.0/24
• BGP Password: hunter2

To confirm connectivity, let's set up a BGP session without announcing any IPs. Create a /etc/bird.conf file with the following text. Note that on some systems, such as Ubuntu 16.04, this will be /etc/bird/bird.conf.

bird.conf on Vultr VPS

For Vultr VPS, use the following settings:

router id 203.0.113.123;

protocol bgp vultr
{
    # substitute with your AS or Vultr's private AS
    local as 64512;
    source address 203.0.113.123;
    ipv4 {
        import none;
        export all;
    };
    graceful restart on;
    multihop 2;
    neighbor 169.254.169.254 as 64515;
    password "hunter2";
}

bird.conf on Vultr Bare Metal

For Vultr Bare Metal, use the following settings:

router id 203.0.113.123;

protocol bgp vultr
{
    # substitute with your AS or Vultr's private AS
    local as 64512;
    source address 203.0.113.123;
    ipv4 {
        import none;
        export all;
    };
    graceful restart on;
    multihop 2;
    neighbor 169.254.1.1 as 20473;
    password "hunter2";
}

Restart bird

Restart bird and check the status of the session:

[root@vultr ~]# birdc show proto all vultr
BIRD 1.4.5 ready.
name     proto    table    state  since       info
vultr    BGP      master   up     14:11:36    Established
  Preference:     100
  Input filter:   REJECT
  Output filter:  (unnamed)
  Routes:         0 imported, 581634 filtered, 1 exported, 0 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:         581674          0     581674          0          0
    Import withdraws:            2          0        ---     581675          0
    Export updates:              1          0          0        ---          1
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 169.254.169.254
    Neighbor AS:      64515
    Neighbor ID:      169.254.169.254
    Neighbor caps:    refresh restart-able AS4
    Session:          external multihop AS4
    Source address:   203.0.113.123
    Hold timer:       208/240
    Keepalive timer:  57/80

A BGP state of Established means that everything is working properly. If you don't see a state of Established, here are some things to try:

• Have you rebooted via the control panel since support set up BGP on your account?
• Is the BGP port (TCP 179) allowed through your firewall?
• Is your BGP password correct? (This can be verified in your control panel, each subscription has a BGP tab listing the details)
• Are you using the main IP of your instance? (You cannot use anything other than the main IP of an instance with BGP)

Announcing Routes

Once you have a working BGP session, the next step is to start announcing some routes. In order for your address space to be visible on the internet, you would need to announce at least a /24 (or /48 for IPv6).

The easiest way of getting started is to add a static route to your BIRD configuration, such as:

protocol static
{
    ipv4;
    route  198.51.100.0/24 unreachable;
}

protocol device
{
    scan time 5;
}

The 'protocol device' block lets BIRD gather information about the network adapters attached to your instance. Without it, your static routes will not appear.

Note: For BIRD 1.5 and above, you may need to change the route lines' syntax.

• From:

    route  198.51.100.0/24 via 203.0.113.123;
  

• To:

    route  198.51.100.0/24 via "203.0.113.123";

Reload BIRD, then verify your route is working properly:

[root@vultr ~]# birdc show route
BIRD 1.4.5 ready.
198.51.100.0/24    via 203.0.113.123 on eth0 [static1 14:22:12] * (200)

At this point, traffic for your subnet should now be flowing towards your instance. You won't be able to ping any IPs until they're configured within your operating system. One way to verify this would be to use tcpdump, 'tcpdump -i eth0 -n net 198.51.100.0/24'.

Configuring IPs

One common configuration we see is using individual IP addresses on different instances. This is possible, though each instance would need to be running its own BGP server.

To do this, we're going to announce /32 routes from individual instances, in addition to the covering /24. We could do this with static routes, but we recommend using dummy interfaces instead. We'll use 198.51.100.100 as the IP we want to route.

Set this up on an interface:

# ip link add dev dummy1 type dummy
# ip link set dummy1 up
# ip addr add dev dummy1 198.51.100.100/32

Confirm this was configured properly:

# ip addr show dev dummy1
5: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether ba:23:57:2c:ad:bc brd ff:ff:ff:ff:ff:ff
    inet 198.51.100.100/32 scope global dummy1

Note: You should consult your operating system's documentation to determine how to configure this interface to come upon boot.

Now we'll configure BIRD to scan for any dummy interfaces and announce any IPs it finds on them. Add the following to your BIRD configuration, and reload BIRD:

protocol direct
{
    interface "dummy*";
    ipv4 {
        import all;
    };
}

Verify that BIRD is announcing the route:

[root@vultr ~]# birdc show route
BIRD 1.4.5 ready.
198.51.100.0/24    via 203.0.113.123 on eth0 [static1 14:22:12] * (200)
198.51.100.100/32  dev dummy1 [direct1 14:36:56] * (240)

You can repeat this process on other instances with other IPs. What happens is our routers will use the most specific route they have for any given IP address. When there's a /24 and /32, the /32 is the most specific route, so any traffic for that IP will follow that route.

You can have multiple instances announcing the same /32. This provides high availability. If any instance fails, its routes will disappear and traffic will fail over to the other instance. A common use for this is to be able to use IPs from a larger subnet on multiple instances. In order for this to work, you must be advertising a /24 IPv4 or /48 IPv6 as well. All uses of a smaller announcement must be within the same location.

Our locations are not linked, so you would need to ensure you're announcing a /24 (or IPv6 /48) out of each location where you want to use the IPs. You cannot use one /24 to assign IPs for multiple locations unless you're trying to set up an anycast network.

FreeBSD Notes

The default FreeBSD configuration will not work with BGP. In order to actually make use of BGP on FreeBSD, you'll need to do a few things:

1. Load tcpmd5 kernel module on runtime:

    kldload tcpmd5
   

2. To persist across reboot add the following line to /boot/loader.conf:

    tcpmd5_load="YES"
   

3. Configure your network adapter with a static IP.

4. Update ipsec.conf with the BGP password:

    add 203.0.113.123 169.254.169.254 tcp 0x1000 -A tcp-md5 "hunter2";
    add 169.254.169.254 203.0.113.123 tcp 0x1000 -A tcp-md5 "hunter2";
   

5. Install bird with:

    pkg install bird2
   

6. Change the configuration accordingly:

    router id 203.0.113.123;
   
    protocol bgp vultr
    {
        # substitute with your AS or Vultr's private AS
        local as 64512;
        source address 203.0.113.123;
        ipv4 {
            import none;
            export all;
        };
        graceful restart on;
        multihop 2;
        neighbor 169.254.169.254 as 64515;
        password "hunter2";
    }

Related documents

AS20473 BGP Customer Guide

Troubleshooting

Our systems require TCP MD5 authentication in order to establish the connection. This means that you cannot test connectivity using something like telnet. We'd generally suggest watching the traffic with tcpdump in order to troubleshoot connectivity issues.