holo-routing/holoSuíte de protocolos de roteamento baseada em Rust implementando BGP, OSPF, IS-IS, RIP e VRRP com configuração modelada por YANG, automação gNMI/gRPC e fuzzing integrado para redes de alta escala e orientadas por automação.
Holo é um conjunto de protocolos de roteamento projetado para suportar redes de alta escala e orientadas à automação.
Para uma descrição do que é um protocolo de roteamento, consulte esta página da Wikipédia.
O principal objetivo do Holo é criar uma base de código confiável, fácil de manter e extensível. Com a crescente complexidade dos protocolos de roteamento e suas extensões, é crucial ter implementações de protocolos de roteamento construídas sobre uma base robusta. Para isso, a base de código do Holo prioriza simplicidade, modularidade e documentação completa. Graças ao rigor do compilador Rust e aos extensos testes unitários, espera-se que a maioria das regressões seja detectada no início do ciclo de desenvolvimento de novos recursos. Para mais detalhes, consulte a página Arquitetura.
O Holo foi desenvolvido especificamente para redes de alta escala e orientadas à automação que exigem configuração e monitoramento programáveis usando dados estruturados e modelados. O Holo implementa nativamente módulos YANG padrão da IETF e oferece suporte a várias interfaces de gerenciamento, incluindo gRPC e gNMI nativos. Além disso, o Holo possui uma CLI independente que renderiza dinamicamente comandos a partir de módulos YANG e se comunica com o daemon Holo através de gRPC.
As alterações feitas na configuração são processadas como transações, garantindo que todas as alterações sejam aplicadas ou nenhuma delas. Esse recurso é um facilitador significativo da automação de rede, pois elimina a necessidade de recuperação de erros em aplicativos de gerenciamento. O Holo também oferece suporte a transações em toda a rede envolvendo vários dispositivos de rede. Recursos adicionais de automação de rede incluem commits confirmados e suporte a rollback de configuração.
Por ser escrito em uma linguagem com segurança de memória, o Holo é imune a uma ampla variedade de bugs relacionados à memória e vulnerabilidades de segurança. Além das garantias de segurança fornecidas pelo Rust, o daemon Holo também reduz privilégios na inicialização. Para certas operações, como vinculação de sockets, as capabilities do Linux são usadas para obter a permissão mínima necessária pelo menor tempo possível.
O Holo também fornece proteção robusta contra o vetor de ataque mais comum em stacks de protocolos de roteamento: ataques de negação de serviço (DoS) via entrada de pacotes maliciosos. Pacotes recebidos são decodificados em tarefas assíncronas isoladas e supervisionadas, permitindo que as implementações de protocolo se recuperem graciosamente de panics, como ignorando pacotes malformados ou fechando apenas o stream TCP afetado, sem comprometer a estabilidade de todo o daemon. Além disso, graças ao design modular do Holo e ao suporte nativo para fuzzing guiado por cobertura, espera-se que a maioria dos bugs de parsing seja detectada e tratada durante o desenvolvimento.
Alguns protocolos, como OSPF e RIP, possuem diferentes versões amplamente implantadas, tipicamente uma para IPv4 e outra para IPv6. O Holo aproveita os genéricos do Rust para ter implementações de protocolo agnósticas à versão, onde a maior parte do código é compartilhada pelas diferentes versões do protocolo. Essa abordagem reduz o custo de manutenção desses protocolos e facilita o lançamento de novos recursos que beneficiam todas as versões do protocolo.
O Holo faz uso extensivo de operações assíncronas e depende do runtime Tokio para agendar tarefas e executá-las em um pool de threads. Para obter melhor desempenho, tanto requisições de I/O quanto algoritmos intensivos em CPU são delegados a tarefas separadas, maximizando a utilização de todos os núcleos de CPU disponíveis. O suporte para código independente de runtime está planejado para o futuro, assim que as abstrações necessárias forem padronizadas pela equipe da linguagem Rust.
O Holo gera mensagens de log que contêm dados estruturados, que podem ser apresentados em vários formatos, como JSON, texto, etc. Como o logging é realizado através da fachada tracing, diversos subscribers do tracing podem ser utilizados para atender a diferentes requisitos do usuário. Por exemplo, o log pode ser direcionado para um arquivo, journald, um coletor OpenTelemetry centralizado, ou qualquer combinação dessas opções com níveis de log potencialmente variados.
O Holo fornece funcionalidade de gravação e reprodução, permitindo a fácil reprodução de qualquer bug reportado pelo usuário. O daemon Holo pode ser configurado para gravar o ciclo de vida completo de uma instância de protocolo em um arquivo. Esse arquivo pode então ser reproduzido em outra máquina, reproduzindo a mesma sequência de eventos. Enquanto uma sessão de gravação pode durar horas ou dias, o processo de reprodução deve levar apenas alguns segundos. Isso é viável graças à arquitetura modular do Holo, onde todas as operações relacionadas ao tempo e de I/O são executadas em tarefas separadas e abstraídas como mensagens de evento.
Para instruções detalhadas sobre instalação, consulte o arquivo INSTALL.md.
Atualmente, o Holo é compatível apenas com sistemas operacionais Linux. O suporte a WebAssembly está planejado para o futuro.
A maneira mais fácil de começar a usar o Holo é usando contêineres Docker pré-construídos em combinação com o software containerlab. Você pode encontrar uma variedade de topologias de rede pré-configuradas neste link. Essas topologias podem ser implantadas com um único comando, permitindo testar o Holo em várias configurações de rede, incluindo testes de interoperabilidade com outras implementações.
Além disso, o Holo pode ser usado onde uma pilha de roteamento for necessária, como em roteadores de software, desde que o conjunto de recursos esteja alinhado com suas necessidades específicas.
O Holo suporta os seguintes padrões da Internet:
Resultados de testes de conformidade realizados com o Ixia IxANVL RFC Compliance Tester estão disponíveis aqui.
Este projeto é financiado através do NGI Zero Core, um fundo estabelecido pela NLnet com apoio financeiro do programa Next Generation Internet da Comissão Europeia. Saiba mais na página do projeto NLnet.
Este projeto está licenciado sob a licença MIT.
Aceitamos qualquer contribuição, desde relatórios de bugs a Pull Requests. Consulte nossa Project Wishlist para ideias sobre onde contribuir.
A menos que você indique explicitamente o contrário, qualquer contribuição enviada intencionalmente para inclusão no Holo por você será licenciada como MIT, sem quaisquer termos ou condições adicionais.
| 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% | 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% |
