holo-routing/holoRust-basierte Routing-Protocol-Suite, die BGP, OSPF, IS-IS, RIP und VRRP implementiert, mit YANG-modellierter Konfiguration, gNMI/gRPC-Automatisierung und integriertem Fuzzing für hochskalierbare, automatisierungsgetriebene Netzwerke.
Holo ist eine Sammlung von Routing-Protokollen, die für hochskalierbare und automatisierungsgesteuerte Netzwerke entwickelt wurde.
Eine Beschreibung dessen, was ein Routing-Protokoll ist, finden Sie auf dieser Wikipedia-Seite.
Das Hauptziel von Holo ist es, eine zuverlässige, leicht wartbare und erweiterbare Codebasis zu schaffen. Angesichts der ständig wachsenden Komplexität von Routing-Protokollen und ihren Erweiterungen ist es entscheidend, Routing-Protokoll-Implementierungen auf einer robusten Grundlage zu haben. Zu diesem Zweck priorisiert Holos Codebasis Einfachheit, Modularität und gründliche Dokumentation. Dank der Strenge des Rust-Compilers und umfangreicher Unit-Tests wird erwartet, dass die meisten Regressionen früh im Entwicklungszyklus neuer Funktionen erkannt werden. Weitere Einzelheiten finden Sie auf der Seite Architecture.
Holo wurde speziell für hochskalierbare, automatisierungsgesteuerte Netzwerke entwickelt, die programmierbare Konfiguration und Überwachung mithilfe strukturierter und modellierter Daten erfordern. Holo implementiert nativ die standardmäßigen YANG-Module der IETF und unterstützt mehrere Verwaltungsschnittstellen, darunter natives gRPC und gNMI. Darüber hinaus verfügt Holo über ein eigenständiges CLI, das Befehle dynamisch aus YANG-Modulen generiert und über gRPC mit dem Holo-Daemon kommuniziert.
Die Änderungen an der Konfiguration werden als Transaktionen verarbeitet, was garantiert, dass entweder alle Änderungen übernommen werden oder gar keine. Diese Funktion erleichtert die Netzwerkautomatisierung erheblich, da sie die Notwendigkeit einer Fehlerbehebung in Verwaltungsanwendungen überflüssig macht. Holo unterstützt auch netzwerkweite Transaktionen, die mehrere Netzwerkgeräte umfassen. Zu den weiteren Netzwerkautomatisierungsfunktionen gehören bestätigte Commits und die Unterstützung von Konfigurations-Rollbacks.
Dadurch, dass es in einer speichersicheren Sprache geschrieben ist, ist Holo immun gegen eine Vielzahl von speicherbezogenen Fehlern und Sicherheitslücken. Neben den Sicherheitsgarantien von Rust senkt der Holo-Daemon beim Start auch die Berechtigungen. Für bestimmte Vorgänge, wie das Binden von Sockets, werden Linux-Capabilities verwendet, um für die kürzestmögliche Zeit die minimal erforderliche Berechtigung zu erhalten.
Holo bietet auch einen robusten Schutz gegen den häufigsten Angriffsvektor in Routing-Protokoll-Stacks: Denial-of-Service (DoS)-Angriffe durch bösartige Paketeingaben. Eingehende Pakete werden in isolierten, überwachten asynchronen Tasks dekodiert, sodass die Protokollimplementierungen sich von Paniken erholen können, z. B. durch das Ignorieren fehlerhafter Pakete oder das Schließen nur des betroffenen TCP-Streams, ohne die Stabilität des gesamten Daemons zu gefährden. Dank des modularen Designs von Holo und der integrierten Unterstützung für coverage-geführtes Fuzzing werden die meisten Parsing-Fehler voraussichtlich während der Entwicklung erkannt und behoben.
Einige Protokolle wie OSPF und RIP haben verschiedene Versionen, die weit verbreitet sind, typischerweise eine für IPv4 und eine für IPv6. Holo nutzt Rusts Generics, um versionsunabhängige Protokollimplementierungen zu ermöglichen, bei denen der Großteil des Codes von den verschiedenen Protokollversionen gemeinsam genutzt wird. Dieser Ansatz reduziert die Wartungskosten dieser Protokolle und erleichtert die Auslieferung neuer Funktionen, die allen Protokollversionen zugutekommen.
Holo nutzt umfangreich asynchrone Operationen und verlässt sich auf die Tokio-Laufzeit, um Tasks zu planen und auf einem Thread-Pool auszuführen. Um eine bessere Leistung zu erzielen, werden sowohl I/O-Anfragen als auch CPU-intensive Algorithmen in separate Tasks ausgelagert, um die Nutzung aller verfügbaren CPU-Kerne zu maximieren. Die Unterstützung für laufzeitunabhängigen Code ist für die Zukunft geplant, sobald die notwendigen Abstraktionen vom Rust-Sprachteam standardisiert sind.
Holo generiert Protokollmeldungen, die strukturierte Daten enthalten, die in verschiedenen Formaten wie JSON, Text usw. dargestellt werden können. Da die Protokollierung über die tracing-Fassade erfolgt, können verschiedene tracing-Subscriber genutzt werden, um unterschiedliche Benutzeranforderungen zu erfüllen. Beispielsweise kann die Protokollierung in eine Datei, journald, einen zentralen OpenTelemetry-Collector oder jede Kombination dieser Optionen mit potenziell unterschiedlichen Protokollierungsstufen erfolgen.
Holo bietet eine Aufzeichnungs- und Wiedergabefunktion, die eine einfache Reproduktion jedes benutzergemeldeten Fehlers ermöglicht. Der Holo-Daemon kann so eingerichtet werden, dass die gesamte Lebensdauer einer Protokollinstanz in einer Datei aufgezeichnet wird. Diese Datei kann dann auf einem anderen Rechner abgespielt werden, wobei die gleiche Ereignissequenz reproduziert wird. Während eine Aufzeichnungssitzung Stunden oder Tage dauern kann, sollte der Wiedergabeprozess nur wenige Sekunden dauern. Dies ist dank Holos modularer Architektur möglich, bei der alle zeitbezogenen und I/O-Operationen in separaten Tasks ausgeführt und als Ereignismeldungen abstrahiert werden.
Detaillierte Installationsanweisungen finden Sie in der Datei INSTALL.md.
Derzeit ist Holo nur mit Linux-Betriebssystemen kompatibel. Die Unterstützung von WebAssembly ist für die Zukunft geplant.
Der einfachste Weg, mit Holo zu beginnen, ist die Verwendung vorgefertigter Docker-Container in Kombination mit der Software containerlab. Eine Vielzahl vorkonfigurierter Netzwerktopologien finden Sie unter diesem Link. Diese Topologien können mit einem einzigen Befehl bereitgestellt werden, sodass Sie Holo in verschiedenen Netzwerkkonfigurationen testen können, einschließlich Interoperabilitätstests mit anderen Implementierungen.
Darüber hinaus kann Holo überall dort eingesetzt werden, wo ein Routing-Stack benötigt wird, z. B. in Software-Routern, sofern der Funktionsumfang Ihren spezifischen Anforderungen entspricht.
Holo unterstützt die folgenden Internetstandards:
Ergebnisse von Konformitätstests, die mit dem Ixia IxANVL RFC Compliance Tester durchgeführt wurden, sind hier verfügbar.
Dieses Projekt wird durch NGI Zero Core finanziert, einen Fonds, der von NLnet mit finanzieller Unterstützung des Programms Next Generation Internet der Europäischen Kommission eingerichtet wurde. Weitere Informationen finden Sie auf der NLnet-Projektseite.
Dieses Projekt ist unter der MIT license lizenziert.
Wir begrüßen jegliche Beiträge, von Fehlerberichten bis hin zu Pull Requests. Bitte schauen Sie sich unsere Projekt-Wunschliste an, um Ideen zu erhalten, wo Sie beitragen können.
Sofern nicht ausdrücklich anders angegeben, wird jeder von Ihnen absichtlich zur Aufnahme in Holo eingereichte Beitrag ohne zusätzliche Bedingungen unter der MIT-Lizenz lizenziert.
| Modul | Konfiguration | Zustand | RPCs | Benachrichtigungen | Gesamt |
|---|
| 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% | 85.95% | - | - | 60.40% |
| ietf-bier@2023-09-12 | 100.00% | - | - | 0.00% | 72.50% |
| ietf-if-extensions@2023-01-26 | 100.00% | 0.00% | - | - | 50.00% |
| ietf-if-vlan-encapsulation@2023-01-26 | 42.86% | - | - | - | 42.86% |
| ietf-igmp-mld@2019-11-01 | 84.62% | 100.00% | - | - | 95.83% |
| ietf-interfaces@2018-02-20 | 100.00% | 0.00% | - | - | 22.22% |
| ietf-ip@2018-02-22 | 52.17% | 0.00% | - | - | 40.00% |
| 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-isis-flex-algo@2026-06-26 | 0.00% | 100.00% | - | 0.00% | 74.00% |
| ietf-isis-link-attr@2026-06-26 | 81.82% | 78.43% | - | - | 78.76% |
| ietf-isis-msd@2024-09-02 | - | 100.00% | - | - | 100.00% |
| ietf-isis-sr-mpls@2025-12-09 | 15.38% | 57.27% | - | - | 52.85% |
| ietf-isis@2022-10-19 | 93.62% | 80.09% | 100.00% | 100.00% | 86.77% |
| ietf-key-chain@2017-06-15 | 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-anycast-flag@2026-05-19 | 100.00% | - | - | - | 100.00% |
| ietf-ospf-sr-mpls@2025-12-09 | 21.43% | 51.36% | - | - | 49.82% |
| ietf-ospf@2022-10-19 | 95.70% | 85.04% | 100.00% | 58.06% | 83.89% |
| ietf-ospfv3-extended-lsa@2024-06-07 | 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% |
| ietf-system@2014-08-06 | 26.67% | 60.00% | 0.00% | - | 38.24% |
| ietf-vrrp@2018-03-13 | 53.19% | 80.00% | - | 66.67% | 66.35% |
