Vultr's Bring Your IP Space functionality allows for unprecedented freedom in assigning your own IP resources to servers on the Vultr cloud. We generally recommend using BIRD to announce your IP space. There are a few solid alternatives to BIRD in case you can't achieve something with BIRD (although this is very rare) or you simply want to use other software.

Due to the administrative and technical overhead, we highly discourage making use of BIRD and Quagga (or any other software for that matter) in the same infrastructure and/or network. Keep in mind that the following configuration would give you a SPOF, as the instance announcing your overlapping subnet is not redundant. You should note, however, that Vultr has multiple BGP routers in every rack.

Although this guide has been written with CentOS 7 in mind, and tested only on this CentOS version, it will most likely work on older versions such as CentOS 6 as well. However, naturally we strongly discourage the usage of outdated software and we highly recommend updating to a newer, more recent (and supported) version such as CentOS 7.

There is no practical limit to the amount of subnets or their size you can announce from one instance running Quagga (or any BGP router for that matter), although in any network topology you should have some kind of risk spreading. That means you should create either a redundant setup or announce different subnets from different servers by following the guide below on multiple servers.

In order to follow this guide, you will need:

• The ASN you want / need to use;
• The IP space (subnet) you want to announce;
• BGP activated in your Vultr account

BIRD or Quagga?

For starters, picking between either BIRD or Quagga can be very hard. Both are well-known and have proven to be very stable and robust for many use cases, including high-traffic environments and infrastructures where reliability plays a key role. The main difference between BIRD and Quagga is that BIRD's configuration is separated from the daemon and discernible more aimed towards a code-like structure.

For example, with BIRD, if you want to achieve a failover setup you would use the following block in the bird.conf configuration file:

export filter {
    bgp_path.prepend(asnumber);
    accept;
};

As you can see, the configuration looks somewhat like a code block as it would appear with a programming language. With Quagga, you would append or alter settings using a program in the daemon itself.

In the end it mostly comes down to personal preference and there's no 'winner' or software you should use. In general, BIRD is easier to setup because of its easy-to-learn way of configuration and it's widely supported by the community.

Furthermore, in favor of Quagga, generally, in a running production environment, Quagga is easier to reconfigure. With BIRD, you'd need to edit the appropriate configuration files and having the daemon reload its settings. With Quagga, you can enter its shell, reconfigure settings without too much extra work or fuss. The continuity plays a big role here, but in practice, the overhead is minimal. In most infrastructures, you won't need to reconfigure these settings too much, so it's probably a good idea to judge by other aspects of the software instead of this detail only.

Just like BIRD, Quagga is cross compatible across multiple distributions. Should you ever want to change the distribution(s) used for the routers, in theory you could simply move over your configurations and nothing would have to be changed or will change.

In this guide, we wil describe the process of installing and configuring Quagga. In case you want to try BIRD as well, try following the "Configuring BGP on Vultr" guide.

Like mentioned, there's a few good other alternatives out there, but the largest part of those have some flaws, stopping them from being used in a production environment. For example, XORP's BGP implementation is relatively outdated which generally isn't a good start for setting up a brand new infrastructure (although its BGP implementation is stable).

Compared to many alternatives, BIRD has a low memory footprint and is not very resource intensive. On the other hand, spinning up or upgrading to a more powerful Vultr cloud instance only takes a few clicks from the Vultr control panel.

IPv4 and IPv6

Vultr supports announcing both IPv4 and IPv6 IP space. Quagga's BGP implementation is relatively up-to-date, allowing for the ability to announce IPv6 space as well.

Although this guide is aimed towards announcing IPv4 space, you could use Quagga's IPv6 implementation and use this article's instructions. This is not explicitly documented however, so please refer to an alternative source for this.

Important note

To be able to survive without a BGP router to pass traffic through, the best way to announce your IP space is as follows:

• Announce your /24 (or larger) from a dedicated Quagga instance;
• Announce individual /32's (or larger) from the instances traffic should be routed to themselves

This way, you would have one instance setup to announce the overlapping subnet for all IPs you break into individual /32's or larger. Using this design you're able to quickly announce IPs and route traffic to the correct instances.

Naturally, you're free to experiment with multiple approaches to announcing your IP space to your liking. In theory the use is limitless and knows no boundaries. Note that Vultr's servers are self-managed and we cannot assist you with any problems that might arise. Aside, it can't hurt to use a solution supported by Vultr and the community so if any problems might arise you can pinpoint their root cause quickly.

Step 1: Disabling SELinux

We highly recommend disabling SELinux in order to prevent it from stopping Quagga from functioning. We have a guide to disable SELinux, please follow it and return to this tutorial after SELinux has been disabled: Disabling SELinux on CentOS 7.

Step 2: Installing Quagga

We can proceed by installing Quagga using yum:

yum install quagga

If you get an error, especially on a newly deployed instance try:

yum update

Configure systemd so Zebra (the core daemon) is started automatically on boot:

systemctl enable zebra

Finally, start Zebra:

systemctl start zebra

We have to repeat the process for BGPd, as follows:

systemctl start bgpd
systemctl enable bgpd

Zebra and BGPd

Quagga consists of a variety of daemons allowing for routing. As we will be making use of BGP, we will need to use the Zebra and BGPd deamons. Zebra and BGPd work together. When either of them stops functioning, your routes will not be advertised anymore, effectively making your entire IP space unavailable.

Quagga supports multiple routing protocols, among others OSPF and BGP. The core of the topology of their implementations is Zebra. Zebra is the core daemon, which is a layer taking care of the UNIX kernel's communication (TCP) with Quagga clients. On the backend Zebra presents the Zserv API, which allows for these routings protocols to communicate routing updates. One of the implementations with the Zserv API is BGP.

The default version used by Quagga for BGP is BGPv4+, which includes address family support for multicast and IPv6.

Step 3: Configuring the BGP router

In order to configure the BGP router to your liking, we'll be using the vtysh shell. First off, copy the sample BGP configuration file:

cp /usr/share/doc/quagga-*/bgpd.conf.sample /etc/quagga/bgpd.conf

After the file has been copied, enter the shell:

vtysh

In some older Quagga versions you might find a setup with AS7675. We don't need this as it will only conflict with our setup, so we need to delete it if it exists. Check if this configuration exists in your Quagga installation by executing the following command inside the shell:

show running-config

If this returns a string with or including "router bgp 7675", delete it by executing:

configure terminal
no router bgp 7675
router bgp YOURAS
no auto-summary
no synchronization

You should now enter the BGP information Vultr has provided you with.

neighbor NEIGHBORIP remote-as VULTRAS
neighbor NEIGHBORIP description "Vultr"

Most likely, you need a password to establish the BGP session. Enter it:

neighbor NEIGHBORIP password YOURBGPPASSWORD
exit

Finally, if you're sure you want to write these changes (only applicable if you're working on a production setup), execute the following to let the changes take effect:

write

Make sure the changes were successful by executing:

show ip bgp summary

We should now have successfully established a BGP session.

Step 4: Announcing your IP space

Although we've established a BGP session, we're not announcing any routes or IP addresses yet, so this will have no effect in practice. Luckily, setting the IP space to announce is a relatively easy process.

In vtysh, execute the following commands to achieve this:

configure terminal
router bgp YOURAS

You're now in the configuration. Make sure to have the IP space you want to announce at hand and enter it:

network YOURSUBNET/CIDR

For example, valid input would be:

network 185.92.220.0/23

Naturally, this won't work in your specific setup as above IP space is owned by Vultr. Replace this and everything should work fine.

Exit and save the changes:

exit
write

Check if your prefixes have successfully been announced:

show ip bgp neighbors NEIGHBORIP advertised-routes

Attempt to ping an IP address from the subnet, and try to perform a traceroute from outside the network.

Troubleshooting

Troubleshooting Quagga is largely outside of the scope of this article, but if you're experiencing difficulties you could always attempt to stop your Quagga instance and retry announcing the IP space via BIRD to be able to exclude a number of possible causes.

When BGP doesn't function correctly on Quagga as well as BIRD, there's a chance your firewall hasn't been properly configured. Port 179 should be open. On CentOS 7, attempt temporarily disabling the firewall:

systemctl stop firewalld

If you use iptables, try:

service iptables stop

Then attempt to initiate the BGP session again. If it hangs on 'Idle', 'Connect' or 'Active' there's a possibility the port is still blocked. With the 'Established' state, the BGP session has successfully been setup and advertised routes are shown.

Quagga has now been installed onto your server, and should function. During the first few days of announcing your own IP space, you should monitor its functionality to prevent your entire infrastructure from not functioning.

That concludes our Quagga tutorial, thank you for reading. To learn more about Vultr's Bring Your IP Space feature, please head over to the BGP page.