BIRD Internet Routing Daemon

Ondřej Zajı́ček
CZ.NIC

Abstract Fourth, BIRD has rather extensive documentation, both

user and programmer one.
We introduce BIRD Internet Routing Daemon, a Linux rout-
ing software. We present the overview of BIRD project, its Typical applications
basic concepts and design decisions, common applications,
supported protocols and and examples of usage. We also dis- The basic application is using Linux system as a software
cuss pitfalls in userspace/kernel interfaces encountered during router, where Linux kernel serves as a data plane, while
BIRD development. BIRD serves as a control plane, communicating with other
routers in the network, discovering the network topology and
computing the routing table. Such application works well
Introduction unless forwarded data rates are too high, requiring hardware
BIRD overview routing solutions.
There are also applications where data traffic is not for-
BIRD Internet Routing Daemon is a routing daemon; i.e., a warded, system traffic is limited to control traffic and local
software responsible for managing kernel packet forwarding data traffic. These are especially suitable for routing software
tables. It is a free implementation of several well known and like BIRD. Several examples: monitoring tools for OSPF net-
common routing and router-supplemental protocols, namely works, BGP route reflectors, fail-over solutions for servers.
RIP, RIPng, OSPFv2, OSPFv3, BGP, BFD, and NDP/RA. One particular example is using BIRD as BGP route server
BIRD supports IPv4 and IPv6 address families, Linux ker- in internet exchange points. The purpose of BGP route
nel and several BSD variants (tested on FreeBSD, NetBSD servers in IXPs is to exchange, filter and distribute routing
and OpenBSD). BIRD consists of bird daemon and birdc in- information between BGP border routers of IXP clients to
teractive CLI client used for supervision. eliminate the need for configuring a BGP session between
BIRD started as a student project at the Faculty of Math each pair of clients. Data traffic is exchanged directly be-
and Physics, Charles University, Prague in 1999. After the tween border routers bypassing the route server. Such task
project was finished, the development mostly ceased. Since requires a flexible and efficient control plane as usually sep-
2008, BIRD is again in active development, sponsored by arate routing table for each client is used and extensive route
CZ.NIC. filters based on RIR databases are applied. BIRD is very pop-
BIRD is a free / open source software, freely distributed ular in European IXP community, according to Euro-IX 2014
under GNU General Public License. report 1 , 64 % of members’ route servers run BIRD.
BIRD features Concepts
BIRD has several distinctive features compared to alternative There are few basic conceptual objects in BIRD: routes, pro-
routing daemons: tocols, tables and filters.
First, BIRD has native support for multiple protocol in-
stances and multiple routing tables. This was one of original Routes
design considerations. Routes are basic objects managed by BIRD. They are gener-
Second, BIRD has programmable route filters by internal ated by protocols and stored in routing tables. Like routes in
scripting language with a familiar syntax, instead of usual ac- kernel forwarding table, they have a destination network pre-
cess control lists. This allows greater expressive power when fix, an associated interface and the target (a gateway or a spe-
configuring route distribution. cific action like unreachable). In addition to this, they have
Third, BIRD uses clear and structured config files for its a list of associated attributes – the responsible protocol, the
configuration. It has automatic runtime reconfiguration – route preference and some protocol-specific attributes (OSPF
when the config file is changed and reconfiguration is re- metrics, multiple kinds of BGP attributes).
quested, BIRD automatically applies necessary changes with-
1
out disrupting other routing protocol sessions. https://www.euro-ix.net/documents/1467-euro-ix-route-servers-stats-pdf

Proceedings of netdev 0.1, Feb 14-17, 2015, Ottawa, On, Canada

Protocols attributes. Named filters are defined as top-level objects but
Protocol objects represent instances of routing protocols used in import or export options of a protocol. Filters can
(BGP, OSPF, RIP), or other route sources/sinks (static, ker- also be defined using where expression. There are two key-
nel, direct). Protocols have name, type, operating state (start, words all and none that can be used as accept-all or reject-all
up, stop, down), associated routing table (usually one, but filters. Note that default is import all and export none.
in some cases multiple), configuration, statistics and internal define martians = [ 10.0.0.0/8+,
state. 172.16.0.0/12+, 192.168.0.0/16+,
Protocols generate routes, propagate them to associated 169.254.0.0/16+, 224.0.0.0/4+,
routing table and receive routes from it. It is possible to have 240.0.0.0/4+, 0.0.0.0/32- ];
multiple instances of one protocol type (e.g. OSPF) as sepa-
rate protocol objects with different names (e.g. ospf1, ospf2). filter bgp_in {
Protocols could be independently enabled, disabled, restarted if net ˜ martians then reject;
or reconfigured. Protocols could be examined using show if bgp_path.first != 1234 then reject;
if bgp_path.len > 64 then reject;
protocols command.
if net ˜ 128.66.0.0/16+
Tables then bgp_local_pref = 500;
Routing tables are data tables where routes are accumulated. else bgp_local_pref = 100;
They are userspace analogy of kernel packet forwarding ta-
bles. In network engineering terminology, they are called bgp_med = 0;
RIB (routing information base), while kernel forwarding ta- accept;
}
bles are called FIB (forwarding information base).
A route is generated by a protocol, then imported to an protocol bgp {
associated routing table, where it is stored. Routing tables import filter bgp_in;
store one route per destination and source protocol. There- export where source = RTS_BGP;
fore, it is possible to have multiple routes for each destination
(from different protocols) concurrently. For each destination, local 192.168.1.1 as 65100;
a preferred route is selected (based on route preferences and neighbor 192.168.1.2 as 65200;
protocol metrics) and then exported to associated protocols. }
BIRD supports any number of routing tables. There is a
default one (named master), others have to be defined in con- Usage
figuration. Note that BIRD routing tables are not automat-
BIRD is mainly configured through its config file, usually
ically synchronized with kernel forwarding tables. There is
/etc/bird.conf or /etc/bird/bird.conf.
a kernel protocol serving to that purpose – when a route is
After start, BIRD setups a unix socket, usually
exported to the kernel protocol, it is propagated to a (config-
/var/run/bird.ctl, which is used by birdc inter-
urable) kernel forwarding table, and vice versa. Therefore,
active client for supervision. There are no specific access
some BIRD routing tables may be synchronized with kernel
control mechanisms for the client, access is controlled just by
forwarding tables, while others may be just internal to BIRD.
file permissions of the socket. BIRD client is an interactive
There is also a pipe protocol to exchange routes between two
shell which uses GNU Readline for CLI. It contains interac-
routing tables.
tive help (accessible by ‘?’). The most important commands
are:
Kernel 1 Kernel 2 • show route [all] . . .
• show protocols [all]
Table A Pipe Table B • show interfaces
• show ospf . . .

BGP 1U BGP 1D BGP 2U BGP 2D

• enable | disable | restart proto
• configure [timeout | undo | confirm]
• down
Filters Compared to e.g. Quagga, where each protocol is a sepa-
Filters stand between protocols and tables. When a route is rate process, in BIRD all protocols are handled by one pro-
imported from a protocol to a table, it passes through an im- cess. Note that in current BIRD, IPv4 and IPv6 are handled
port filter. Likewise, when a route is exported from a table by two separate daemons, bird for IPv4 and bird6 for IPv6.
to a protocol, it passes through an export filter. Such filters Likewise, the client for IPv6 daemon is named birdc6. There
may modify, reject or accept routes. A filter is written in a is also a lightweight client, birdcl, that does not depend on
scripting language, which may access and examine all route GNU Readline.

Proceedings of netdev 0.1, Feb 14-17, 2015, Ottawa, On, Canada

Basic setup tain many additional attributes, mainly AS PATH describing
Basic configuration is pretty simple. Global options are usu- the path to the destination as a list of autonomous systems.
ally used just to specify router ID and logging. Protocol de- BIRD implements BGPv4 (RFC 4271), multiprotocol BGP
vice is necessary for enumeration of network interfaces. Pro- (RFC 4760) for IPv6 (RFC 2545) and multiple BGP exten-
tocol kernel is used for synchronization of BIRD routing ta- sions:
bles and kernel forwarding tables. Protocol static allows to • RFC 1997 – communities attribute
specify a set of static routes.
• RFC 2385 – MD5 password authentication
router id 192.168.1.1;
log syslog all; • RFC 3392 – capability negotiation
• RFC 4360 – extended communities attribute
protocol device {
} • RFC 4456 – route reflectors
• RFC 4724 – graceful restart
protocol kernel {
export all; • RFC 4893 – 4B AS numbers
scan time 10; • RFC 5668 – 4B AS numbers in extended communities
}
A BGP protocol instance in BIRD represents one BGP ses-
protocol static { sion. Therefore, it is expected to setup multiple BGP proto-
route 192.168.10.0/24 via 192.168.1.2; cols, one for each BGP neighbor. A BGP implementation
route 192.168.20.0/24 unreachable; in BIRD is conceptually simple, it does not maintain much
} internal state, it is essentially a pipe to the neighbor. All ex-
ported routes (from the BIRD routing table) are sent to the
OSPF – Open Shortest Path First neighbor, all routes received from the neighbor are imported
OSPF is a popular link-state routing protocol for internal net- to the BIRD routing table. BGP path attributes are accessible
works. Each router monitors reachability of its neighbors, the from import and export filters, BGP path decision process is
local network topology is packed to LSAs (Link State Adver- handled in BIRD routing tables as a part of preferred route
tisements), distributed to neighbors and flooded through the selection.
network. Therefore, every router gets a complete map of the An example of configuration is skipped as it is contained
network and computes shortest paths to all destinations. in the example for Filters.
BIRD implements OSPFv2 for IPv4 (RFC 2328), OSPFv3
for IPv6 (RFC 5340), and NSSA areas (RFC 3101). BFD – Bidirectional Forwarding Detection
A protocol instance represents a complete OSPF domain BFD is a protocol for neighbor reachability and liveness test-
possibly with multiple areas and active interfaces. Multiple ing. It is a supplementary protocol to OSPF, BGP and others.
instances are possible but usually not necessary. It maintains Although these protocols have internal neighbor liveness test-
OSPF topology, when it changes, OSPF routing table is cal- ing, they have timers with 1-second granularity and their re-
culated and imported to BIRD routing table. When a route action time is usually in tens of seconds, while BFD reaction
is exported to an OSPF protocol, it is included in its topol- time is tens to hundreds of milliseconds.
ogy as an external LSA. Device routes for OSPF interfaces BIRD implements BFD (RFC 5880) for IPv4 and IPv6,
are handled internally and generated automatically. both the single hop variant (RFC 5881), and the multihop
protocol ospf { variant (RFC 5883).
# export all static routes to OSPF protocol bfd {
export where source = RTS_STATIC; interface "eth*" {
interval 50 ms;
area 0 { multiplier 4;
interface "eth0" { };
cost 5; hello 5; wait 10; dead 25; }
};
interface "eth*" { protocol bgp {
cost 100; type pointopoint; . . .
};
}; local 192.168.1.1 as 65100;
} neighbor 192.168.1.2 as 65200;
bfd;
BGP – Border Gateway Protocol }
BGP is the standard protocol for internet routing. A router
receives paths to reachable destinations from its neighbors. It NDP/RA – IPv6 router advertisements
chooses preferred paths by path lengths and local policy. Pre- IPv6 routers use router advertisement packets from Neighbor
ferred paths are used as a routes for forwarding and also pos- Discovery Protocol (NDP) to announce their presence on the
sibly propagated to other neighbors. Forwarded routes con- network to hosts. Hosts then use it for IPv6 stateless address

Proceedings of netdev 0.1, Feb 14-17, 2015, Ottawa, On, Canada

autoconfiguration. On Linux, this is usually handled by The Netlink and FIB
Router Advertisement Daemon (radvd). BIRD could also FIB behavior and its management using the Netlink interface
generate router advertisement packets by protocol radv. It is a source of multiple pitfalls:
can learn announced address prefixes from the interface con- The first issue is behavior of multipath routes where there
figuration. It also support RDNSS a DNSSL extensions for is no consistency between IPv4 and IPv6. An IPv4 multipath
DNS autoconfiguration on hosts. There is also a support for route is one route with several next hop fields, while IPv6
dynamic IPv6 router advertisements – advertisements trig- multipath route is a set of routes with the same destination
gered by availability of a configured route in BIRD routing network. There is a compatibility layer for IPv6 routes, but it
table. does not behave consistently (a route with multiple next hops
could be entered, but it is scanned back as a multiple separate
protocol radv {
interface "eth*"; routes).
rdnss 2001:0DB8:1234::10; The second issue are missing RTM DELROUTE notifi-
dnssl "domain.cz"; cations when routes are removed due to shutdown of re-
trigger 2000::/3; lated interfaces. Although there is a reason for that (to not
} flood Netlink with many RTM DELROUTE notifications),
it is unexpected and inconsistent behavior and the Netlink
was flooded with RTM NEWROUTE messages when these
Pitfalls routes were added.
During BIRD development, we encountered several pitfalls The third issue is the default limit for IPv6 FIBs,
in kernel networking API. 4096 routes (net.ipv6.route.max size), which is too
small for common usages and completely unexpected by
Sockets API users (as there is no such limit for IPv4 FIBs).

Although the Sockets API is well-behaved and mature in-

terface for simple TCP connections, there are plenty issues
when it is used for multicast with UDP or raw sockets. The
first issue is whether to use one global socket, or one socket
per interface. Although the first option seems natural, there
are often hidden limits for the number of joined multicast
groups per socket while memberships are specific per inter-
face, therefore such limits are encountered on systems with
many network interfaces. For this and other reasons, it seems
that the second option is generally better.
Another issue is that there is no universal reliable way to
specify the source address and the destination interface. The
syscall bind() is useless in this case, as it has multiple unre-
lated effects (like filtering incoming messages). We currently
use IP PKTINFO on Linux, IP SENDSRCADDR on BSD
for UDP and IP HDRINCL on BSD for raw sockets. Hope-
fully, for IPv6, IPV6 PKTINFO works well in all cases. Also
note that on Linux, socket option SO BINDTOIFACE is very
useful for our style of usage of sockets; unfortunately, no such
option is available on BSD.

Ephemeral Source Port Selection

When TCP or UDP communication is initiated with-
out explicitly specifying the source port, one is auto-
matically allocated. Such port is called an ephemeral
port. According to IANA and RFC 6335, range
49152–65535 should be used for ephemeral ports.
Linux uses by default range 32768–61000, tunable by
net.ipv4.ip local port range. FreeBSD uses by
default range 10000–65535, also tunable. In FreeBSD, there
is a socket option IP PORTRANGE HIGH that forces OS
to use the proper ephemeral port range. Unfortunately, there
is no such option in Linux. Why even care for ephemeral
port selection? Some BFD implementations reject received
packets with source port< 49152.

Proceedings of netdev 0.1, Feb 14-17, 2015, Ottawa, On, Canada