Holo is a suite of routing protocols designed to support high-scale and automation-driven networks.
For a description of what a routing protocol is, please refer to this Wikipedia page.
The image below shows the different logical layers of the Holo software stack:
Items with a gray background have not been implemented yet. For more comprehensive and detailed information, please refer to the Architecture page.
Holo's main goal is to create a reliable, easy-to-maintain, and extensible codebase. With the ever increasing complexity of routing protocols and their extensions, it's crucial to have routing protocol implementations built on a robust foundation. To that end, Holo's codebase prioritizes simplicity, modularity, and thorough documentation. Thanks to the strictness of the Rust compiler and extensive unit tests, it's expected that most regressions will be caught early in the development cycle of new features.
Holo was developed specifically for high-scale, automation-driven networks that require programmable configuration and monitoring using structured and modeled data. Holo natively implements standard YANG modules from IETF and supports multiple management interfaces, including native gRPC and gNMI. Additionally, Holo features a standalone CLI that dynamically renders commands from YANG modules and communicates with the Holo daemon through gRPC.
The changes made to the configuration are processed as transactions, guaranteeing that either all the changes are applied or none at all. This feature is a significant facilitator of network automation as it eliminates the need for error recovery in management applications. Holo also supports network-wide transactions involving multiple network devices. Additional network automation capabilities include confirmed commits and configuration rollback support.
By virtue of being written in a memory-safe language, Holo is immune to a wide variety of memory-related bugs and security vulnerabilities. Besides the safety guarantees provided by Rust, the Holo daemon runs in a chroot jail and drops privileges at startup. For certain operations, like binding sockets, Linux capabilities are used to gain the minimum required permission for the least amount of time.
Some protocols, such as OSPF and RIP, have different versions that are widely deployed, typically one for IPv4 and another for IPv6. Holo leverages Rust's generics to have version-agnostic protocol implementations, where most of the code is shared by the different protocol versions. This approach reduces the maintenance cost of these protocols and facilitates shipping new features that benefit all protocol versions.
Holo makes extensive use of asynchronous operations and relies on the Tokio runtime to schedule tasks and run them on a thread pool. In order to achieve better performance, both I/O requests and CPU-intensive algorithms are offloaded to separate tasks, maximizing the utilization of all available CPU cores. Support for runtime-agnostic code is planned for the future, once the necessary abstractions are standardized by the Rust language team.
Holo generates log messages that contain structured data, which can be presented in various formats such as JSON, text, etc. As logging is carried out through the tracing facade, diverse tracing subscribers can be utilized to meet different user requirements. For instance, logging can be directed to a file, journald, a centralized OpenTelemetry collector, or any combination of these options with potentially varying logging levels.
Holo provides record-and-replay functionality, enabling easy reproduction of any user-reported bug. The Holo daemon can be set up to record the complete lifespan of a protocol instance to a file. That file can then be played back on another machine, reproducing the same sequence of events. While a recording session may last for hours or days, the playback process should take only a few seconds. This is feasible thanks to Holo's modular architecture, where all time-related and I/O operations are performed in separate tasks and abstracted as event messages.
Holo uses unstable Rust features, so building it from the source code requires a nightly version of the Rust compiler.
For detailed instructions on installation, please refer to the INSTALL.md file.
At present, Holo is only compatible with Linux operating systems.
WebAssembly support is planned for the future. This addition will enable simulation of large networks from within your browser, making network experimentation more convenient and accessible to everyone.
The easiest way to start using Holo is by using pre-built Docker containers in combination with the containerlab software. You can find a variety of pre-configured network topologies at this link. These topologies can be deployed with a single command, allowing you to test Holo in various network setups, including interoperability testing with other implementations.
Additionally, Holo can be used wherever a routing stack is required, such as in software routers, provided that the feature set aligns with your specific needs.
Holo supports the following IETF RFCs and Internet drafts:
- RFC 5880 - Bidirectional Forwarding Detection (BFD)
- RFC 5881 - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
- RFC 5882 - Generic Application of Bidirectional Forwarding Detection (BFD)
- RFC 5883 - Bidirectional Forwarding Detection (BFD) for Multihop Paths
- RFC 1997 - BGP Communities Attribute
- RFC 2385 - Protection of BGP Sessions via the TCP MD5 Signature Option
- RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
- RFC 2918 - Route Refresh Capability for BGP-4
- RFC 4271 - A Border Gateway Protocol 4 (BGP-4)
- RFC 4360 - BGP Extended Communities Attribute
- RFC 4486 - Subcodes for BGP Cease Notification Message
- RFC 4760 - Multiprotocol Extensions for BGP-4
- RFC 5082 - The Generalized TTL Security Mechanism (GTSM)
- RFC 5492 - Capabilities Advertisement with BGP-4
- RFC 5668 - 4-Octet AS Specific BGP Extended Community
- RFC 5701 - IPv6 Address Specific BGP Extended Community Attribute
- RFC 6286 - Autonomous-System-Wide Unique BGP Identifier for BGP-4
- RFC 6608 - Subcodes for BGP Finite State Machine Error
- RFC 6793 - BGP Support for Four-Octet Autonomous System (AS) Number Space
- RFC 7606 - Revised Error Handling for BGP UPDATE Messages
- RFC 7607 - Codification of AS 0 Processing
- RFC 8092 - BGP Large Communities Attribute
- RFC 8212 - Default External BGP (EBGP) Route Propagation Behavior without Policies
- RFC 8642 - Policy Behavior for Well-Known BGP Communities
- RFC 5036 - LDP Specification
- RFC 5561 - LDP Capabilities
- RFC 5918 - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)
- RFC 5919 - Signaling LDP Label Advertisement Completion
- RFC 6720 - The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
- RFC 2328 - OSPF Version 2
- RFC 3623 - Graceful OSPF Restart
- RFC 5187 - OSPFv3 Graceful Restart
- RFC 5243 - OSPF Database Exchange Summary List Optimization
- RFC 5250 - The OSPF Opaque LSA Option
- RFC 5340 - OSPF for IPv6
- RFC 5709 - OSPFv2 HMAC-SHA Cryptographic Authentication
- RFC 5838 - Support of Address Families in OSPFv3
- RFC 6987 - OSPF Stub Router Advertisement
- RFC 7684 - OSPFv2 Prefix/Link Attribute Advertisement
- RFC 7166 - Supporting Authentication Trailer for OSPFv3
- RFC 7770 - Extensions to OSPF for Advertising Optional Router Capabilities
- RFC 8362 - OSPFv3 Link State Advertisement (LSA) Extensibility
- RFC 8405 - Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
- RFC 8476 - Signaling Maximum SID Depth (MSD) Using OSPF
- RFC 8665 - OSPF Extensions for Segment Routing
- RFC 8666 - OSPFv3 Extensions for Segment Routing
- RFC 2080 - RIPng for IPv6
- RFC 2453 - RIP Version 2
- RFC 4822 - RIPv2 Cryptographic Authentication
| Module | Configuration | State | RPCs | Notifications | Total |
|---|---|---|---|---|---|
| ietf-bfd-ip-mh@2022-09-22 | 100.00% | 100.00% | - | 100.00% | 100.00% |
| ietf-bfd-ip-sh@2022-09-22 | 100.00% | 100.00% | - | 100.00% | 100.00% |
| ietf-bfd@2022-09-22 | 100.00% | 100.00% | - | - | 100.00% |
| ietf-bgp-policy@2023-07-05 | 100.00% | - | - | - | 100.00% |
| ietf-bgp@2023-07-05 | 32.38% | 87.86% | - | - | 61.39% |
| ietf-interfaces@2018-01-09 | 100.00% | 0.00% | - | - | 22.22% |
| ietf-ip@2018-01-09 | 17.39% | 0.00% | - | - | 13.33% |
| ietf-ipv4-unicast-routing@2018-03-13 | 100.00% | 100.00% | - | - | 100.00% |
| ietf-ipv6-unicast-routing@2018-03-13 | 40.62% | 100.00% | - | - | 45.71% |
| ietf-key-chain@2017-04-18 | 100.00% | 100.00% | - | - | 100.00% |
| ietf-mpls-ldp@2022-03-14 | 86.96% | 92.31% | 100.00% | 100.00% | 92.38% |
| ietf-mpls@2020-12-18 | 0.00% | 57.14% | - | - | 35.29% |
| ietf-ospf-sr-mpls@2024-01-18 | 25.00% | 53.95% | - | - | 52.81% |
| ietf-ospf@2022-10-19 | 75.00% | 59.64% | 100.00% | 41.94% | 59.57% |
| ietf-ospfv3-extended-lsa@2024-01-16 | 50.00% | 85.28% | - | - | 84.85% |
| ietf-rip@2020-02-20 | 27.91% | 93.33% | 100.00% | - | 55.41% |
| ietf-routing-policy@2021-10-11 | 100.00% | 0.00% | - | - | 98.11% |
| ietf-routing@2018-03-13 | 100.00% | 85.71% | - | - | 92.31% |
| ietf-segment-routing-mpls@2021-05-26 | 62.50% | 0.00% | - | 23.53% | 32.76% |
| ietf-segment-routing@2021-05-26 | 100.00% | - | - | - | 100.00% |
This project is funded through NGI Zero Core, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
This project is licensed under the MIT license.
We welcome any contributions, from bug reports to Pull Requests. Please refer to our Project Wishlist for ideas on where to contribute.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Holo by you, shall be licensed as MIT, without any additional terms or conditions.