Configuring BGP on Vultr

Published on: Thu, May 12, 2016 at 10:52 am EST
FAQ Networking

Vultr's BGP feature allows you to bring your own IP space and use it across any of our locations.

Getting started

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.

Please complete the BGP setup form to begin. Ensure you verify ownership of your ASN and subnet(s) to prevent delays.

Once this has been configured on your account, you can proceed with configuring BGP.

BGP Setup

Note: If you're going to be configuring an instance that was deployed before BGP was setup on your account, you will need to reboot it via the control panel. BGP will not work on any existing instances until they've been rebooted (rebooting via SSH is not sufficient).

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 examples are going to assume the following:

  • ASN: 64512
  • Instance's IP::
  • IPv4 Block:
  • 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.

router id;

protocol bgp vultr
    local as 64512;
    source address;
    import none;
    export all;
    graceful restart on;
    multihop 2;
    neighbor as 64515;
    password "hunter2";

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:
    Neighbor AS:      64515
    Neighbor ID:
    Neighbor caps:    refresh restart-able AS4
    Session:          external multihop AS4
    Source address:
    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)

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) Recompile the kernel with these additional options enabled:

device crypto
options IPSEC

2) Configure your network adapter with a static IP.

3) Update ipsec.conf with the BGP password:

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

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
    route via;

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.

Reload BIRD, then verify your route is working properly:

[root@vultr ~]# birdc show route
BIRD 1.4.5 ready.    via 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'.

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 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

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 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*";
    import all;

Verify that BIRD is announcing the route:

[root@vultr ~]# birdc show route
BIRD 1.4.5 ready.    via on eth0 [static1 14:22:12] * (200)  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 would give you high availability (if any instance failed, its routes would disappear, and traffic would failover to the other instance).

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.

Some of our locations support ECMP, in which case traffic will randomly be distributed between up to 8 instances that announce the same IP. The locations currently supporting ECMP are:

  • New Jersey
  • Chicago
  • Dallas
  • Atlanta
  • Tokyo
  • Singapore
  • Los Angeles
  • Miami
  • Silicon Valley
  • Paris
  • London

Related documents


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

route via;


route via "";

** 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.

Want to contribute?

You could earn up to $300 by adding new articles