BIRD Internet Routing Daemon
BIRD Internet Routing Daemon is an open-source dynamic IP routing software designed for Unix-like operating systems, including Linux, FreeBSD, NetBSD, and OpenBSD, that manages routing tables and exchanges routing information with other routers to facilitate efficient packet forwarding across IPv4 and IPv6 networks.[1] Primarily developed to provide a scalable and high-performance alternative to earlier routing daemons like routed and Zebra, BIRD supports a wide array of modern routing protocols such as BGPv4, OSPFv2, OSPFv3, RIPv2, RIPng, Babel, and BFD, enabling it to handle complex topologies in both wired and wireless environments.[2] Originating as a student project at Charles University in Prague, BIRD has evolved into a robust tool maintained by CZ.NIC Labs, with its initial development led by contributors including Libor Forst and Pavel Machek.[1] Released under the GNU General Public License, it features an extensible architecture that allows for multiple routing tables, policy-based routing, and inter-table route exchange via a virtual protocol called Pipe.[3] Key capabilities include a powerful route filtering language for fine-grained control over route selection and propagation, support for IPv6 Router Advertisements, and integration with kernel routing tables for seamless operation.[2] BIRD's configuration is handled through a human-readable text file, typically/etc/bird.conf, using a C-like syntax that defines protocols, filters, and tables, with runtime adjustments possible via the birdc command-line client or soft reconfiguration signals like SIGHUP.[2] Renowned for its speed and efficiency, BIRD is deployed in major Internet exchanges worldwide, where it excels in recalculating optimal routes across large-scale networks.[4] As of the latest stable release, version 3.1.4, it continues to incorporate enhancements for emerging routing technologies while maintaining backward compatibility.[2]
History
Origins and Early Development
The BIRD Internet Routing Daemon project originated in 1999 as a seminar project at the Faculty of Mathematics and Physics, Charles University in Prague, Czech Republic.[5] Initiated under the supervision of RNDr. Libor Forst, the effort was led by Martin Mares as the original author, with significant early contributions from Ondrej Filip.[6] This academic endeavor aimed to address limitations in existing routing software by creating a new dynamic IP routing daemon tailored for Unix-like systems. The project's core motivation was to develop a lightweight and portable routing daemon capable of supporting modern routing protocols, such as BGP, OSPF, and RIP, while avoiding the perceived bloat and complexity of predecessors like gated and Zebra.[6] BIRD was envisioned as a modular, extensible tool with a flexible configuration interface and powerful route filtering capabilities, prioritizing efficiency and ease of use for network administrators.[4] These goals reflected the need for a streamlined alternative in the evolving landscape of Internet routing during the late 1990s. The first public release of BIRD, version 0.1, occurred on June 9, 2000, and was distributed under the GNU General Public License (GPL) version 2 or later.[4] This initial version marked the project's transition from academic prototype to open-source software, quickly attracting interest from the networking community for its clean design and focus on essential functionality.[6] Over the subsequent years, BIRD's development evolved beyond its university roots into a sustained open-source initiative.Major Milestones and Sponsorship
In 2008, CZ.NIC initiated sponsorship of BIRD's development, revitalizing the project after a period of limited activity and enabling professional maintenance, regular releases, and significant expansions in functionality.[7] This institutional support transformed BIRD from an academic endeavor into a robust, widely adopted open-source routing solution, with CZ.NIC Labs taking responsibility for ongoing enhancements and providing commercial support options ranging from 5,000 to 50,000 Euros annually.[8] A key recognition of BIRD's impact came in 2010, when the project received the LINX Conspicuous Contribution Award from the London Internet Exchange for advancing internet routing practices through its open-source contributions.[9] The project's evolution is marked by major version transitions that addressed scalability and protocol integration challenges. The v1.x series, maintained until its end-of-life on December 31, 2023, culminated in version 1.6.8 released in September 2019 and relied on separate daemons for IPv4 (bird) and IPv6 (bird6) operations.[10][11] In December 2017, BIRD 2.0 introduced a unified architecture integrating IPv4 and IPv6 support within a single daemon, alongside a comprehensive rewrite incorporating microsecond timers, RPKI validation, and MPLS next-hop capabilities to enhance performance and scalability in large-scale deployments.[11] Subsequent advancements arrived with the v3.x series, beginning with the stable release of version 3.0.0 in December 2024, which implemented multithreading to better handle high-load environments and decoupled route exports from imports for improved efficiency.[12] Development continues to be hosted on GitLab under CZ.NIC Labs, where community contributions are integrated via the bird-users mailing list and pull requests, ensuring collaborative evolution of the codebase.[13] As of November 2025, the current stable release is BIRD 3.1.4, which includes critical bug fixes such as resolutions for multiple BGP crashes, building on prior enhancements like ASPA crash fixes in 3.1.3, to maintain reliability in production networks.[14][15]Features
Supported Protocols
BIRD supports a comprehensive set of routing protocols for both IPv4 and IPv6 networks, enabling dynamic route exchange and management across diverse topologies. These protocols include mechanisms for inter-domain and intra-domain routing, link failure detection, and policy-based route manipulation, allowing BIRD to serve as a versatile routing daemon in various environments.[16] The Border Gateway Protocol (BGP) is a core protocol in BIRD, used for inter-domain routing between autonomous systems. It implements BGP-4 as defined in RFC 4271, supporting both internal BGP (iBGP) for route propagation within an AS and external BGP (eBGP) for inter-AS exchanges. Key features include route reflection per RFC 4456 to reduce peering overhead, community attributes (standard per RFC 1997, extended per RFC 4360, and large per RFC 8092) for policy control, graceful restart per RFC 4724 for high availability, and multipath support per RFC 7911 for load balancing. BIRD's BGP implementation also handles 4-octet AS numbers per RFC 6793 and enables route selection based on attributes like local preference, AS path length, and multi-exit discriminator (MED).[16] For intra-domain link-state routing, BIRD provides Open Shortest Path First (OSPF) support, including OSPFv2 for IPv4 per RFC 2328 and OSPFv3 for IPv6 per RFC 5340. These versions facilitate fast convergence through link-state advertisements and shortest path calculations using Dijkstra's algorithm. Features encompass multi-area configurations, external route tagging, equal-cost multi-path (ECMP) routing, graceful restart per RFC 3623, and integration with various network types such as broadcast, point-to-point, non-broadcast multi-access (NBMA), and point-to-multipoint. BIRD's OSPF handles stub and not-so-stubby area (NSSA) support, virtual links, and bidirectional forwarding detection (BFD) for enhanced neighbor monitoring.[16] BIRD implements the Routing Information Protocol (RIP) as a distance-vector protocol for simpler network environments, supporting RIPv2 for IPv4 per RFC 2453 and RIPng for IPv6 per RFC 2080. These versions use hop count as the metric and operate via periodic updates and split-horizon to prevent loops. Key aspects include authentication options, interface-specific configurations, and compatibility with triggered updates for quicker convergence in small to medium-sized networks.[16] Bidirectional Forwarding Detection (BFD) in BIRD provides rapid link and neighbor failure detection, complementing slower protocols like BGP and OSPF. It adheres to RFC 5880, supporting single-hop and multi-hop sessions with configurable detection multipliers and authentication mechanisms. BFD sessions monitor liveness through periodic control packets, enabling sub-second failure detection and route withdrawal to maintain network stability.[16] For mesh and low-overhead routing, BIRD includes the Babel protocol, a loop-avoiding distance-vector routing scheme per RFC 8966. It optimizes for wired, wireless, and tunnel interfaces with RTT-based metrics and link quality estimation, supporting IPv6 source-specific routing (SSR) and split packet aggregation for reduced overhead in dynamic topologies.[16] BIRD also supports static routes for manual route definitions, allowing fixed paths independent of dynamic updates. These can include multiprotocol label switching (MPLS) labels and are essential for default gateways or policy overrides.[16] IPv6 Router Advertisements (RA) enable host autoconfiguration and route propagation per RFC 4861 and RFC 4191. BIRD generates RAs on interfaces to announce prefixes, default routes, and DNS configurations per RFC 6106, with tunable parameters like advertisement intervals and lifetimes.[16] The inter-table protocol (Pipe) facilitates policy-based routing by exchanging routes between multiple routing tables within BIRD. It allows bidirectional communication with import/export filters for route translation and manipulation, supporting complex scenarios like virtual routing and forwarding (VRF).[16]Configuration and Management Tools
BIRD employs a text-based configuration file, typically namedbird.conf and located at /etc/bird.conf, which uses a declarative syntax to define routing protocols, filters, and policies.[17] This file supports comments via # or /* */ blocks, is case-sensitive, and organizes elements within curly braces {} for grouping options such as protocol instances and interface bindings. For instance, a basic kernel protocol configuration might appear as:
This syntax allows administrators to specify protocol behaviors, such as enabling IPv4 export and ensuring persistence across reboots, without procedural scripting.[17] Central to BIRD's configuration is its route filtering language, which enables precise manipulation of routes based on attributes including AS paths, prefixes, and metrics. Filters are defined using theprotocol kernel { ipv4 { export all; }; persist; }protocol kernel { ipv4 { export all; }; persist; }
filter keyword followed by a name and a block of commands, such as import filter { if net = 192.0.2.0/24 then accept; reject; } to selectively accept or reject routes matching specific criteria.[17] Policies can be applied to protocol imports and exports, allowing complex decision-making like preferring routes with shorter AS paths or lower metrics, thereby enforcing routing policies declaratively within the configuration file. This language supports expressions for attribute evaluation, ensuring flexibility in handling diverse routing scenarios without requiring external tools.[17]
For operational management, BIRD provides the birdc command-line interface (CLI) tool, which communicates with the running daemon via a UNIX domain socket (default: bird.ctl) to facilitate monitoring, debugging, and runtime modifications.[18] Administrators can inspect status with commands like show protocols to view protocol states or show route to display routing tables, aiding in real-time diagnostics. Debugging is enhanced through debug protocol bgp1 all to enable verbose logging of events such as state changes or packet exchanges, while runtime changes include enable bgp1 to activate a protocol instance without daemon restart.[18] The tool supports options like -r for read-only access, ensuring secure interactions in production environments.
BIRD's soft reconfiguration feature allows dynamic reloading of the configuration file to minimize downtime, achieved by sending a SIGHUP signal to the daemon or using birdc configure soft to apply changes while preserving existing routes and sessions where possible.[18] This approach updates filters and policies without fully restarting affected protocols, as filter modifications do not trigger immediate route withdrawals unless explicitly required. For example, configure soft "new.conf" loads a revised file, integrating updates seamlessly into the active routing state.[18]
To support multiple routing instances or virtual routers, BIRD accommodates separate configuration files invoked via the -c option for each daemon process, enabling isolated environments such as virtual routing and forwarding (VRF) setups with vrf "name";.[17] Additionally, configuration templates like template bgp { ... }; allow reuse of common settings across instances, such as shared neighbor policies, facilitating scalable management in multi-router deployments. This capability ensures that diverse routing domains can operate concurrently on the same host without interference.[17]
Architecture and Design
Core Components
BIRD employs a modular architecture designed to facilitate the implementation and extension of routing protocols while maintaining a clean separation between the core functionality and protocol-specific logic. This structure consists of core modules handling essential operations like resource management and configuration, alongside library modules for shared utilities, and system-dependent modules for interfacing with the operating system. Protocol implementations are encapsulated in dedicated modules that operate independently, allowing for easy addition of new protocols without affecting the overall system.[19] At the heart of BIRD's design is the Routing Information Base (RIB), a central repository that stores all known routes and their attributes, serving as the convergence point for information from various protocol modules. Protocol-specific modules exchange routing updates with the RIB through defined channels, enabling the daemon to aggregate and process routes from multiple sources such as BGP, OSPF, or static configurations. This internal RIB maintains comprehensive route details, including metrics and preferences, to support informed decision-making in route selection.[20] The kernel protocol module acts as the bridge between BIRD's internal RIB and the operating system's forwarding table, exporting selected routes to enable packet forwarding and importing kernel routes to incorporate external changes, such as those from connected interfaces. This module handles synchronization tasks, including resolution of recursive next hops, ensuring consistency between the daemon's view of the network and the kernel's forwarding behavior. It is implemented in a system-dependent manner to accommodate different UNIX-like environments, promoting portability.[20] BIRD's filter system provides a powerful mechanism for policy enforcement, allowing administrators to define rules that evaluate, modify, or reject routes during import, export, or selection processes. Written in a specialized, loop-free scripting language, filters operate at key hooks in the route lifecycle, such as pre-export stages, to apply criteria based on attributes like prefixes, communities, or metrics. This enables fine-grained control over route propagation and selection without altering protocol implementations.[19] The daemon operates on a multi-threaded event-driven model, utilizing a custom scheduler to manage asynchronous events like protocol updates, timer expirations, and interface changes, for efficiency on multi-core systems. Protocol operations are supervised by state machines that handle startup, shutdown, and state transitions, with integrated hooks for logging events and debugging to facilitate troubleshooting and monitoring. This design ensures responsive handling of network dynamics in resource-constrained environments.[20] To support advanced routing scenarios, BIRD accommodates multiple routing tables, including a primary table and configurable secondary ones, which enable virtual routing and routing instances (VRFs) for segmenting traffic domains. Each table operates independently within the RIB framework, allowing protocols to interact with specific tables and supporting features like policy-based routing across isolated contexts.[20]Routing Table Management
BIRD maintains multiple independent routing tables, each serving as a self-contained Routing Information Base (RIB) for storing routes learned from various protocols. These tables are defined by nettype configurations, such as IPv4 or IPv6, allowing separation of routing domains like virtual routing and forwarding (VRF) instances. While BIRD's RIBs hold detailed route attributes, the Forwarding Information Base (FIB) resides in the kernel, and synchronization ensures consistency between them.[21] Route selection within each table employs a multi-stage algorithm that first compares route preferences, which are configurable values assigned to routes based on their source protocol or user policies. If preferences tie, the algorithm evaluates preferences of the originating protocol instances, followed by protocol-specific metrics, such as the shortest AS path in BGP or lowest cost in OSPF. User-defined policies, applied through import and export filters, further refine selection by modifying attributes like preference or metric before comparison. For instance, an export filter can adjust preference values to prioritize certain routes. Sorted tables, enabled via thesorted option, maintain routes in preference or metric order for efficient retrieval.[21]
Synchronization between BIRD's RIBs and the kernel's FIB occurs through the Kernel protocol, which uses Netlink sockets on Linux systems or routing sockets on BSD variants to import kernel routes into BIRD and export selected BIRD routes to the kernel. Import filters control which kernel routes enter BIRD's tables, while export filters determine which BIRD routes update the kernel FIB, enabling selective propagation based on criteria like prefix length or attributes. This bidirectional exchange supports features like route learning from directly connected interfaces and ensures BIRD can override or supplement kernel routes.[21]
The Pipe protocol facilitates route redistribution between BIRD's independent tables on the same host, acting as a virtual channel for inter-table communication with optional transformations. Routes exported from a source table via an export filter can be modified—such as altering metrics, preferences, or attributes—before import into a peer table through an import filter, allowing custom policy enforcement across routing domains. By default, Pipe retains original route sources and attributes unless filters intervene.[21]
BIRD handles route aggregation through dedicated protocols like the experimental Aggregator (use with caution), which merges multiple routes into summarized prefixes based on user-defined expressions, such as network prefix or BGP path length, to reduce table size while preserving essential attributes. Blackholing is supported by marking routes with the RTD_BLACKHOLE destination type, directing matching packets to silent discard without forwarding. Multipath routing enables equal-cost or weighted path selection, with routes supporting multiple next hops assigned weights from 1 to 256; the Kernel protocol's merge paths option combines compatible paths into equal-cost multipath (ECMP) entries in the FIB, limited to a configurable maximum like 16 paths by default.[21]
Deployments and Usage
Applications in Internet Exchange Points
BIRD serves as a route server in Internet Exchange Points (IXPs), enabling BGP peering among participants without requiring a full-mesh topology of individual sessions. This approach mirrors the role of route reflectors in iBGP, allowing the route server to aggregate and redistribute routes from multiple peers, thereby minimizing session overhead and simplifying connectivity for IXP members.[22][7] The daemon is deployed in prominent IXPs, including the London Internet Exchange (LINX), DE-CIX in Frankfurt, and AMS-IX in Amsterdam, where it manages vast routing tables comprising millions of prefixes announced by hundreds of connected autonomous systems. These deployments support peak traffic volumes exceeding several terabits per second while maintaining stable operations across diverse peering arrangements.[23][8][24] Compared to alternatives such as Quagga, BIRD offers superior scalability for environments with hundreds of BGP sessions, reduced CPU consumption when handling high prefix volumes, and quicker convergence during route updates. Quagga, for instance, exhibits instability beyond approximately 100 sessions and provides less robust BGP filtering capabilities.[23][8][25] Since the early 2010s, European IXPs have increasingly adopted BIRD, replacing proprietary routing solutions and earlier open-source daemons like Quagga to enhance reliability and cost-effectiveness in critical infrastructure. A notable case is LINX's full transition to BIRD on its LON1 route servers in 2020, following Quagga's deprecation due to scaling limitations, which has bolstered open-source integration across the IXP ecosystem. BIRD has been widely used in major European IXPs, such as DE-CIX and AMS-IX.[26][27][28] BIRD's multithreaded version 3 supports high-performance processing in IXP settings, efficiently handling large-scale BGP update volumes on multi-core hardware to ensure rapid route propagation and minimal downtime.[29][30]Integration in Software Distributions
BIRD is integrated into major Linux distributions, including Debian, Ubuntu, and Fedora, where it is available through official package repositories as pre-built binaries.[31][32] These packages typically include version-specific variants such asbird for legacy releases and bird2 or bird3 for modern implementations, along with initialization scripts for seamless service management via tools like systemd.[33] In Debian and Ubuntu-based systems, installation is facilitated by the Advanced Package Tool (APT), using commands like sudo apt install bird2 to deploy the daemon with default configurations and dependencies. Fedora users can similarly install it via the DNF package manager, ensuring compatibility with Red Hat-based environments.[32]
The daemon extends to BSD variants, with dedicated ports in FreeBSD's ports collection (e.g., net/bird2) and support for OpenBSD, enabling deployment on these systems through their respective package tools like pkg or pkg_add.[10][16] BIRD's portability across Unix-like operating systems is achieved through a modular architecture that adapts to kernel-specific interfaces, such as Netlink for interacting with the Linux kernel's forwarding information base (FIB) and routing sockets for BSD kernels to synchronize routing tables.[16] This design allows the software to function on a range of platforms without requiring extensive recompilation, provided GNU development tools are available.[16]
Community-maintained ports in these distributions handle ongoing updates and adaptations, ensuring alignment with upstream releases from CZ.NIC.[31] For users requiring enhanced reliability, CZ.NIC provides commercial support options, including enterprise-level contracts for setup, custom development, training, and on-site assistance tailored to production deployments.[34] BIRD's lightweight footprint and cross-platform compatibility also make it suitable for embedded and virtualized environments, such as virtual routers in containerized or hypervisor-based setups.[16]