You could earn up to $300 by adding new articles!

Get Started Now

Configuring BGP on Vultr

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

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

Getting started

In order to use BGP, you would need 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.

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

router id 203.0.113.123;

protocol bgp vultr
{
    local as 64512;
    source address 203.0.113.123;
    import none;
    export all;
    graceful restart on;
    multihop 2;
    neighbor 169.254.169.254 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: 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 then 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
options TCP_SIGNATURE

2) Configure your network adapter with a static IP

3) 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";

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  198.51.100.0/24 via 203.0.113.123;
}

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.
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 it's 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 up on 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.
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 would give you high availability (if any one instance failed, it's routes would disappear and traffic would failover to the other instance).

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

Notes

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

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

Get started in the SSD Cloud!