The heart of BIRD is a routing table. BIRD has several independent routing tables;
each of them contains routes of exactly one nettype (see below). There are two
default tables -- master4
for IPv4 routes and master6
for IPv6 routes.
Other tables must be explicitly configured.
These routing tables are not kernel forwarding tables. No forwarding is done by BIRD. If you want to forward packets using the routes in BIRD tables, you may use the Kernel protocol (see below) to synchronize them with kernel FIBs.
Every nettype defines a (kind of) primary key on routes. Every route source can supply one route for every possible primary key; new route announcement replaces the old route from the same source, keeping other routes intact. BIRD always chooses the best route for each primary key among the known routes and keeps the others as suboptimal. When the best route is retracted, BIRD re-runs the best route selection algorithm to find the current best route.
The global best route selection algorithm is (roughly) as follows:
Usually, a routing table just chooses a selected
route from a list of entries for one network. But if the sorted
option is
activated, these lists of entries are kept completely sorted (according to
preference or some protocol-dependent metric). This is needed for some features
of some protocols (e.g. secondary
option of BGP protocol, which allows to
accept not just a selected route, but the first route (in the sorted list) that
is accepted by filters), but it is incompatible with some other features (e.g.
deterministic med
option of BGP protocol, which activates a way of choosing
selected route that cannot be described using comparison and ordering). Minor
advantage is that routes are shown sorted in show route
, minor disadvantage
is that it is slightly more computationally expensive.
BIRD works with several types of routes. Some of them are typical IP routes, others are better described as forwarding rules. We call them all routes, regardless of this difference.
Every route consists of several attributes (read more about them in the Route attributes section); the common for all routes are:
Other attributes depend on nettypes. Some of them are part of the primary key, these are marked (PK).
The traditional routes. Configuration keywords are ipv4
and ipv6
.
The IPv6 routes containing both destination and source prefix. They are used
for source-specific routing (SSR), also called source-address dependent routing
(SADR), see RFC 8043. Currently limited mostly to the Babel protocol.
Configuration keyword is ipv6 sadr
.
Routes for IPv4 and IPv6 with VPN Route Distinguisher (RFC 4364).
Configuration keywords are vpn4
and vpn6
.
These entries can be used to validate route origination of BGP routes.
A ROA entry specifies prefixes which could be originated by an AS number.
Their keywords are roa4
and roa6
.
Flowspec rules are a form of firewall and traffic flow control rules
distributed mostly via BGP. These rules may help the operators stop various
network attacks in the beginning before eating up the whole bandwidth.
Configuration keywords are flow4
and flow6
.
This nettype is currently a stub before implementing more support of RFC 3031.
BIRD currently does not support any label distribution protocol nor any label assignment method.
Only the Kernel, Pipe and Static protocols can use MPLS tables.
Configuration keyword is mpls
.
This is not a nettype. The route next hop is a complex attribute common for many nettypes as you can see before. Every next hop has its assigned device (either assumed from its IP address or set explicitly). It may have also an IP address and an MPLS stack (one or both independently). Maximal MPLS stack depth is set (in compile time) to 8 labels.
Every route (when eligible to have a next hop) can have more than one next hop. In that case, every next hop has also its weight.
BIRD protocol is an abstract class of producers and consumers of the routes. Each protocol may run in multiple instances and bind on one side to route tables via channels, on the other side to specified listen sockets (BGP), interfaces (Babel, OSPF, RIP), APIs (Kernel, Direct), or nothing (Static, Pipe).
There are also two protocols that do not have any channels -- BFD and Device. Both of them are kind of service for other protocols.
Each protocol is connected to a routing table through a channel. Some protocols support only one channel (OSPF, RIP), some protocols support more channels (BGP, Direct). Each channel has two filters which can accept, reject and modify the routes. An export filter is applied to routes passed from the routing table to the protocol, an import filter is applied to routes in the opposite direction.
When BIRD is started after restart or crash, it repopulates routing tables in
an uncoordinated manner, like after clean start. This may be impractical in some
cases, because if the forwarding plane (i.e. kernel routing tables) remains
intact, then its synchronization with BIRD would temporarily disrupt packet
forwarding until protocols converge. Graceful restart is a mechanism that could
help with this issue. Generally, it works by starting protocols and letting them
repopulate routing tables while deferring route propagation until protocols
acknowledge their convergence. Note that graceful restart behavior have to be
configured for all relevant protocols and requires protocol-specific support
(currently implemented for Kernel and BGP protocols), it is activated for
particular boot by option -R
.