holo: a routing stack built around YANG, gRPC and transactions

A routing stack aimed at machines that configure networks

Holo is a suite of routing protocols designed to support high-scale and automation-driven networks. It is written in Rust, published under the MIT licence, and the repository was last pushed on 2026-10-12 with releases v0.9.0 on 2026-02-21, v0.8.0 on 2025-07-07 and v0.7.0 on 2025-03-27.

The set of protocols is visible in the workspace, because the Cargo.toml lists one crate per protocol area: holo-bgp, holo-ospf, holo-isis, holo-ldp, holo-rip, holo-vrrp, holo-bfd and holo-igmp, alongside the shared pieces such as holo-protocol, holo-interface, holo-routing, holo-policy, holo-platform, holo-northbound, holo-yang and holo-utils. The topic tags add MPLS, segment routing, BIER, gNMI, gRPC and YANG to that list, which is a fair summary of the direction of travel.

The reason a new implementation of protocols that have existed for decades is written in Rust is stated in the project documentation: the goal is a reliable, easy to maintain and extensible codebase, and the argument is that routing protocol implementations should be built on a foundation that is simple, modular and thoroughly documented, so that most regressions are caught early in the development of a new feature. The strictness of the Rust compiler and the unit tests are given as the mechanism.

One structural note for anyone assessing it: the project itself says the codebase is largely platform independent, with the parts that touch the operating system, such as network I/O, interface management and route installation, isolated in a few places, so it can be ported elsewhere, and it can also be compiled to WebAssembly, mainly to run virtual networks in the browser. It runs on Linux today.

YANG, gRPC and a CLI that generates itself

The northbound is the part that distinguishes Holo from a routing daemon with a text configuration file, and it is what the phrase automation-driven networks refers to in practice.

Holo natively implements standard YANG modules from the IETF and supports multiple management interfaces, including native gRPC and gNMI. The gRPC interface is what an orchestration system talks to. Alongside it there is a standalone CLI that dynamically renders commands from the YANG modules and communicates with the Holo daemon through gRPC. That last detail is the elegant part: the command line interface is not hand written, it is generated from the same models that drive the API, so the two cannot drift apart and a new YANG module brings its commands with it.

The configuration model is transactional, and this is the feature the documentation treats as the main enabler for network automation. Changes are processed as transactions, which guarantees that either all the changes are applied or none at all, and the documentation says this removes the need for error recovery in management applications, since a partially applied configuration is exactly the state an orchestration system struggles to reason about. Beyond that, Holo supports network-wide transactions involving multiple network devices, so a change can be committed across a set of devices as a unit, and it adds confirmed commits and configuration rollback support.

Put together, the northbound offers the properties a network automation tool wants: typed models rather than free text, an API rather than a command line parser, atomic application, and a rollback. The cost is that the operator has to be comfortable with YANG, and that the configuration surface is the YANG modules rather than something the project invented.

Panics in one packet handler should not take the daemon down

The security section of the documentation makes two separate claims, and they are worth separating.

The first is about memory safety. By virtue of being written in a memory-safe language, Holo is immune to a wide variety of memory-related bugs and vulnerabilities, and beyond that the daemon drops privileges at startup. For operations that need more, such as binding sockets, Linux capabilities are used to gain the minimum required permission for the least amount of time. This is standard practice for a network daemon, and stating it in a README does not make Holo safer than the alternatives, but the combination of a memory-safe language, privilege dropping and narrowly scoped capabilities is a coherent posture.

The second is about denial of service through malicious packet input, which the documentation calls the most common attack vector in routing protocol stacks. Incoming packets are decoded in isolated, supervised async tasks, so a protocol implementation can recover from a panic: it can ignore a malformed packet, or close only the affected TCP stream, without compromising the stability of the whole daemon. That is a meaningful design decision, because a routing stack that dies on a malformed packet is a routing stack that one remote host can take down.

The third piece is fuzzing. The modular design and built-in support for coverage-guided fuzzing are cited as the reason most parsing bugs are expected to be detected and addressed during development, and the repository has a fuzz/ directory at the top level, excluded from the Cargo workspace so that it is built separately. For a project whose job is parsing untrusted packets from the network, a fuzzing target in the tree is more convincing than a claim in prose.

One OSPF implementation for two versions, by way of Rust generics

Some protocols come in versions that are widely deployed in parallel, typically one for IPv4 and another for IPv6. OSPF has OSPFv2 and OSPFv3, and RIP has RIPv2 and RIPng. Maintaining two implementations of each is the tax that most routing stacks pay.

Holo uses Rust generics to write version-agnostic protocol implementations, where most of the code is shared between the versions. The stated benefit is twofold: it reduces the maintenance cost of these protocols, and it makes it easier to ship a new feature that benefits all the versions at once, because the change lands in the shared code rather than in each version separately.

This is a real advantage for a project that intends to keep shipping protocol extensions, and it is also a design constraint that a reader of the code will feel. A version-agnostic implementation has to express the differences between versions as parameters or traits, which pushes the version-specific details into a smaller, more explicit part of the tree, and it means a bug in the shared code affects every version simultaneously. The upside and the downside are the same mechanism, which is a fair way to judge it: the cost is paid once, at the point where the abstractions are drawn.

The repository layout follows the same modular idea. holo-protocol holds the shared protocol machinery, holo-policy the policy machinery, holo-interface the interface handling, and each protocol crate sits above them.

Tokio, offloaded CPU work, and logs you can query

Holo makes extensive use of asynchronous operations and relies on the Tokio runtime to schedule tasks and run them on a thread pool. To get better use of a machine, both I/O requests and CPU-intensive algorithms are offloaded to separate tasks, which maximises the use of the available CPU cores. Support for runtime-agnostic code is planned for the future, once the abstractions are standardised by the Rust language team, which is an honest admission that the code is currently tied to the runtime it uses.

The logging story is built on the tracing facade, and it is the kind of detail that matters when a routing stack is operated at scale. Log messages contain structured data, and they can be presented in various formats such as JSON or text. Because the logging goes through tracing, different tracing subscribers can be used to meet different requirements: logging can be directed to a file, to journald, to a centralised OpenTelemetry collector, or any combination of those, with potentially different levels for each. A daemon that can emit JSON to a collector and human text to a local file, without a fork, is far easier to run than one that offers a single format.

The other operational feature in the documentation is record and replay, which is unusual enough to deserve its own look. The daemon can be set up to record the complete lifespan of a protocol instance to a file, and that file can be played back on another machine to reproduce the same sequence of events. A recording session may last hours or days, and playback takes only a few seconds. The reason it is possible is the same modularity that serves the rest of the design: all time-related and I/O operations are performed in separate tasks and abstracted as event messages, so a run is a sequence of events that can be captured and replayed rather than a side effect of a live network. The workspace carries a holo-tools/holo-replay crate for it.

Trying Holo in a browser, or with containers and topologies

The quickest way to try the project is Holo Lab, which runs network topologies of Holo routers directly in the browser, with no installation. That is more than a demo convenience, because the same WebAssembly compilation mentioned in the platform section is what makes it possible, and it means a team can build a topology in a browser tab before committing to a deployment.

For a complete setup, the documentation points at pre-built Docker containers combined with containerlab software, and a separate repository of pre-configured network topologies that can be deployed with a single command. The docker/ directory in the repository is the packaging for that path, and the containerlab topologies repository is where the ready-made lab shapes live.

The detailed installation instructions live in the INSTALL.md file rather than in the README, which is the right place for them, and the repository also carries a SECURITY.md for reporting issues and a _typos.toml configuration.

The Cargo workspace shows how the project is laid out for a build. The default member is the daemon, and the individual protocol crates are separate members:

[workspace]
default-members = ["holo-daemon"]
resolver = "2"

[workspace.package]
version = "0.9.0"
license = "MIT"
edition = "2024"

The edition is 2024 and the workspace version matches the released 0.9.0. The dependency list is long, and it is the usual mixture for a network daemon: netlink crates for route installation on Linux, prost for protocol buffers, nix for system calls, capctl for capabilities, chrono for timestamps, regex and lexopt for parsing, plus bitflags, bytes, futures and the usual supporting crates. Nothing in that list suggests an unusual dependency, which is a reasonable signal for code that is going to sit on a network edge.

Editorial conclusion

Holo fits a network team whose configuration is written by an orchestration system, because the YANG and gRPC northbound and the transaction model remove the whole class of half-applied configuration failures, and the record and replay facility turns an intermittent bug report into a reproducible file. It is the wrong choice for a network that still has people editing configuration by hand, and the wrong choice if you need a routing stack today, since the project is at version 0.9.0 and is Linux only. Before you evaluate it, read INSTALL.md for the deployment path, try a topology in Holo Lab in the browser before you build anything, and check the protocol list against your own requirements, since the crates in the workspace show exactly which protocols are implemented and which are not.

Frequently asked questions

Official sources

1. holo-routing/holo on GitHub
2. Issues
3. License: MIT
4. README
5. Releases