BGP Open-Source Tools – Quagga vs. BIRD vs. ExaBGP

Categories

The router market is largely controlled by the big vendors like Cisco and Juniper that spend a lot of time and money developing a rich feature set, mainly routing protocols. However, there are also multiple open-source BGP routing stacks in networking out there.

Despite the relative lack of funding into these options they tend to have a smaller number of features, but some of the world’s largest companies frequently use them. Businesses are not always open about their use of these open-source tools, but they are frequently deployed because not only are they are free and still offer a relatively large feature set, they are typically highly customizable to the business’ specific needs within their own networks.

Today, we’re going to do a comparative deep dive into three different stacks: Quagga and BIRD, which are the two biggest open-source stacks, and ExaBGP, a narrower alternative focused on BGP. Other notable open-source tools in networking include XORP, Bagpipe-BGP and the OpenBSD-supported OpenBGPd and OpenOSPFd. 

We will get started by taking a close look at Quagga.

What is Quagga?

Quagga, also known as the Quagga Routing Project, is an open-source licensed network routing stack. It is distributed under the terms of the GNU General Public License (GPL). Quagga is an implementation of IP routing protocols, providing implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPng and BGP-4. Quagga is not a full router implementation as it does not include the traffic forwarding component; however, it can be run with various Unix platforms, including FreeBSD, Linux, NetBSD and Solaris. Linux, for instance, can use the standard Linux kernel for forwarding as a software router, or Quagga can alternatively be connected to a distributed forwarding platform using OpenFlow or another interface (either open-source or proprietary), acting as a high-end distributed router. Finally, it could also be used simply for the routing protocols and interface with off-the-shelf routers to receive and announce routes.

Quagga is a Fork of GNU Zebra

Quagga is a fork of GNU Zebra, which was developed by Kunihiro Ishiguro around 14 years ago (the project’s name stems from the quagga, an extinct sub-species of the African zebra). Zebra was abandoned as a public project in 2005; however, it was developed into a commercial solution – ZebOS with the Santa Clara, California-based IP Infusion. The Quagga tree has set out to build a more engaged community around the open-source Quagga.

Components

The Quagga architecture is comprised of a core daemon (zebra), which acts as an abstraction layer to the underlying Unix kernel. It presents the Zserv API over a Unix-domain socket or TCP socket to Quagga clients. These Zserv clients generally implement a routing protocol and communicate routing updates to the zebra daemon.

Existing Zserv implementations are:

  • IPv4
  • IPv6
  • zebra
    • kernel interface, static routes, zserv server
  • ripd
  • ripngd
    • RIPv1/RIPv2 for IPv4 and RIPng for IPv6
  • ospfd
  • ospf6d
    • OSPFv2 and OSPFv3
  • bgpd
    • BGPv4+ (including address family support for multicast and IPv6)
  • isisd
    • IS-IS with support for IPv4 and IPv6

with additional work and/or externally:

  • babeld
    • BABEL wireless mesh routing (IPv4 & IPv6)

under development or unmaintained:

  • olsrd
  • ldpd
    • MPLS Label Distribution Protocol
  • bfdd
    • Bidirectional Forwarding Detection

Support for OSPFv3 and IS-IS is currently in various beta states; IS-IS for IPv4 is thought to be usable; but OSPFv3 and IS-IS for IPv6 have known issues.

BABEL support is primarily developed as part of Quagga-RE.

Furthermore, the Quagga architecture has a development library aimed at facilitating the implementation of protocol and client software with consistent configuration and administrative behavior.

Who Manages Quagga?

It is managed by OpenSourceRouting under the umbrella of the non-profit Network Device Education Foundation (NetDEF). OpenSourceRouting employ the main active maintainer of Quagga (spending time testing and fixing the current and new code), but do not run it. It is run by its community.

In NetDEF co-founder Martin Winter’s words in a 2014 interview with SDXCentral, “We see our role in providing a paycheck to a few people in the community to make sure they can afford the time working on the project. Our goal is not to take over ownership and control away from the community, but to help building a stable community around Quagga”.

OpenSourceRouting initially began with donations from Google; one of its main current sponsors is Cumulus Networks.

New Fork: FRR

In April 2017, FreeRangeRouting (FRR) forked from Quagga aiming for a faster and more open development. In the press announcement, Winter described the goal of its developers as being “to streamline the routing protocol stack and to make engineers’ lives that much easier”. FRR can be used in a variety of use case scenarios; for enterprises for connecting hosts, virtual machines, and containers to their networks; as advertising network service endpoints; for network switching and routing; and in Internet access/peering routers.

Who Uses Quagga?

According to Martin Winter, Quagga is mainly used in virtual environments, large data centers (cloud providers) and in the academic/research community because of its needs to an open-source implementation of the proprietary routing protocols as a foundation to try new standards and ideas on top of it. In addition, as mentioned above, there are a lot of large users, including the Fortune 100, using Quagga in secret that don’t publicly acknowledge its use.

They use Quagga because it is easy to modify and extend using their own intelligence, and despite it being open-source software, they do not need to publish everything. For GLPv2 this is only the case for code that is distributed on to other parties. If the enhancement is just employed in-house, it does not need to be shared, which is a major advantage to using Quagga over one of the commercial solutions as most commercial vendors will share any new features with all their other customers, lessening any competitive advantage gained by writing one’s own enhancements.

BIRD

What is BIRD?

BIRD (BIRD Internet Routing Daemon) is the biggest alternative to Quagga in terms of popularity. It initially began life as a BGP route-server/route-reflector for Internet providers and exchange points and thus has numerous unique features for this environment.

The goal of the BIRD project is to develop a fully functional dynamic IP routing daemon mainly targeted on (but not limited to) Linux, FreeBSD and other UNIX-like systems and distributed under the GNU General Public License. As of March 2018, it runs in new releases 2.0.2 and 1.6.4.

Components

BIRD’s main recent features are:

  • BGP- multipath
  • BGP – large BGP communities
  • BGP – MD5 authentication in FreeBSD

BIRD supports:

  • IPv4 and IPv6
  • Multiple routing tables
  • BGP
  • RIP
  • OSPF
  • BFD
  • Babel
  • Static routes
  • IPv6 Router Advertisements
  • Inter-table protocol
  • Command-line interface (using the `birdc’ client; to get some help, just press `?’)
  • Powerful language for route filtering
  • Linux, FreeBSD, NetBSD, OpenBSD ports

BIRD contains a simple programming language with two objects: filters and functions.

When a route is being passed between protocols and routing tables, filters are interpreted by BIRD core. The filter language includes control structures such as if’s and switches, however, it allows no loops. Examples of filters using numerous features can be found in filter/test.conf. Filter gets the route, examines its attributes and alters those of them if it wishes to. Finally, it decides whether to accept (i.e. pass) the changed route through or whether to reject it.

Filters are compiled into bytecode. They include variables, sets and contants. Data types are bool, int, ip, prefix, enum, quad, string, bgppath, bgpmask, clist, eclist and lclist. Operators that can be used include: +, -, *, /, comparisons, logical, element_of_set (~), roa_check(). Controls structures include if/else, case and functions. The set is implemented by a weight-balanced tree (or similar structures) using a logarithmic time complexity.

BIRD also supports functions, so that the same blocks of code do not have to be continuously repeated. Functions can have zero or more parameters. They can also have local variables., but recursion is not allowed.

Who Developed BIRD?

BIRD was originally developed as an open-source routing daemon in 1998 as a school project at Faculty of Math and Physics, Charles University, Prague. Libor Forst and Pavel Machek were formerly BIRD team members.

The project slept for a while after its initial development then went through a small reincarnation in 2003 and 2006 and was fully renewed as of Q4 2008 when it was taken under the umbrella of CZ.NIC Labs.

Who Manages BIRD?

Currently BIRD (1.6.4) is developed and supported by CZ.NIC Labs who in 2008 decided to invest its surplus from domain name registrations into projects related to the common good of the Internet, including open-source development of key Internet software.

Current team members are:

CZ.NIC provides a support programme for BIRD, with prices ranging from 5,000 to 50,000 Euro per year. Current customers are primarily IXPs and large CDN/cloud providers. These fees cover all development costs.

BIRD is also a component of CZ.NIC’s Turris Omnia project, a crowd-funded high-performance home router.

 How does it compare to Quagga?

BIRD is a relatively full-featured routing suite that like Quagga, does not forward any network packets. It provides the logistical information the network systems need in order to send incoming data packets on the right path to their ultimate destinations. It can be installed on any commodity hardware.

It has a few main differences to Quagga. The first is that BIRD stems from a configuration client that is detached from the daemon. It is able to communicate with the BIRD daemon via unix sockets by default; however it can also communicate over the network.

The configuration syntax for BIRD is more similar to JunOS than IOS; however, it is still quite different and its unusual configuration language can take some getting used to. The configuration has an embedded basic scripting language, however, that for most developers and network engineers will be relatively straightforward to use. It is a powerful configuration and filter language. BIRD also has a separate client utility that can be used to query the server. The BIRD project site includes a page of useful popular IOS commands and their equivalent in birdc.

BIRD is lightweight and efficient, supports current routing protocols and is portable (it supports Linux, FreeBSD, NetBSD and OpenBSD) and modular. Similarly to Quagga, BIRD is actively in development with various features currently underway.

According to BIRD team member Ondrej Filip, Quagga becomes unstable when it has to deal with over one hundred BGP sessions and has far weaker BGP filtering capabilities than BIRD.

According to the European Internet Exchange Association, BIRD is the most widely used router daemon and has conquered a significantly larger share of the market than Quagga. The wide user community helps in debugging the software.

Who uses BIRD?

According to a presentation given by Filip at APRICOT 2018 in February, users of BIRD include the following:

Three of the largest peering centers in Europe:

  • Amsterdam Internet Exchange
  • DE-CIX in Frankfurt
  • London Internet Exchange (LINX)

Other large exchanges using BIRD include:

  • North-American Peering And Internet eXchange (PAIX)
  • Moscow Internet Exchange (MSK-IX),
  • London Network Access Point (LONAP)

BIRD is particularly popular within the Internet Exchange Points (IXP) community as that is where it was developed. The largest IXPs run switching platforms with vast amounts of peak traffic; indeed the IXPs that BIRD serves constitute the global backbone of today’s Internet infrastructure. In addition to the huge amounts of traffic they have to process, these systems also have extremely high requirements in terms of reliability, availability and scalability.

According to Flip, it is also used by various large companies, including:

  • Netflix
  • Equinix
  • Amazon (Twitch)
  • Cisco (despite having its own proprietary solution)

Similarly to Quagga, companies benefit from the use of BIRD because they can add their own functionality or integrate BIRD with their own solutions. According to Filip, BIRD also has various unique features such as extremely powerful filtering mechanisms.

ExaBGP

What is ExaBGP?

ExaBGP is released under the BSD-3 license. It describes itself on GitHub as “the BGP swiss army knife of networking”.

It is a highly flexible BGP speaker, which enables the control of BGP announcements on a programmatic basis. It is also able to receive BGP updates from peers and feed those in a parsed form to your application. ExaBGP takes care of all the details running BGP state machine, keepalives and protocol encoding.

Components

Among others, ExaBGP supports:

  • IPv4/IPv6
  • L2VPN
  • L3VPN
  • FlowSpec

Integration is performed by configuring your application in ExaBGP’s configuration file. It was designed to be controlled from third party apps. Your application will be launched by ExaBGP, which will then interact with it i.e. ExaBGP starts your app as a subprocess. Unix Pipes are used to do IO. Options include: announce/withdraw routes, add/remove neighbors, ask state, etc.

Who Develops and Manages ExaBGP?

UK-based ISP Exa Networks initially created ExaBGP for use on its own infrastructure, but have since released it to the public. Exa Networks was founded in 2003 with just six employees in Halifax, Yorkshire. It now has over 50 employees and offers “the dedicated Internet connections and products that businesses require – accompanies by the customer care and technical support that have earned them two customer service awards from the Internet Service Provider’s Association in the last four years”.

How Does it Compare to Quagga and/or BIRD?

A direct comparison between ExaBGP and Quagga and Bird cannot be made as ExaBGP does not interact with the operating system to apply announcements to the routing table. Nor does it support any route server or route reflector features.

Instead, the focus of ExaBGP is on delivering an easy BGP interface for applications and scripts to consume; for instance, because it has no other dependencies than Python, deployment is simplified. And although it is written in Python, because of the generic interface, other languages can be used to write third party scripts or applications.

By default, ExaBGP doesn’t run or require a TCP listener; however, it can be enabled.

ExaBGP is primarily recommended for use in introducing a highly programmable layer to your BGP environment.

Use Cases for ExaBGP

According to network architect/software developer Anton Aksola, the most obvious use case for using ExaBGP is anycasting and the announcement of reachability information for your apps. The app would need to be served by an IP address that is being announced by multiple ExaBGP instances in different servers. That IP address would be put into a loopback interface, which would be monitored so that the script could then announce/withdraw the address according to the state of the app. In his presentation, Aksola also details a case study his company Nebula ran using ExaBGP.

Keeping it Classless blogger Matt Oswalt meanwhile describes ExaBGP as “a conduit between an organization’s network and development teams” as “it seems to have the right tools to bridge the gap between network operations and software development”. Oswalt points out that many of the common use cases for ExaBGP are highly focused on ISP networks.

Check out our other blog post:

Scroll to Top