Présentée est la sortie d'une édition portable du package de routage OpenBGPD 9.0, développé par les développeurs du projet OpenBSD et adapté pour une utilisation sur FreeBSD et Linux (le support pour Alpine, Debian, Fedora, RHEL/CentOS, Ubuntu est déclaré). Pour garantir la portabilité, des parties du code des projets OpenNTPD, OpenSSH et LibreSSL ont été utilisées. Le projet prend en charge la plupart des spécifications BGP 4 et est conforme aux exigences de la RFC8212, mais n'essaie pas d'embrasser les vastes et fournit principalement une prise en charge des fonctions les plus populaires et les plus répandues.
Le développement d'OpenBGPD est réalisé avec le soutien du registre Internet régional RIPE NCC, qui souhaite adapter les fonctionnalités d'OpenBGPD à une utilisation sur Internet. серверах pour le routage aux points d'échange de trafic inter-opérateurs (IXP) et pour la création d'une alternative complète au package BIRD (parmi les alternatives ouvertes avec la mise en œuvre du protocole BGP, on peut citer les projets FRRouting, GoBGP, ExaBGP et Bio-Routing).
Le projet vise à garantir un niveau maximal de sécurité et de fiabilité. La protection est assurée par une validation rigoureuse de tous les paramètres, le respect des limites des tampons, la séparation des privilèges et un accès restreint aux appels système. La syntaxe conviviale du langage de définition de configuration est également un atout. haute performance et l'efficacité de la mémoire (par exemple, OpenBGPD peut gérer des tables de routage contenant des centaines de milliers d'entrées).
Principaux changements dans la nouvelle version :
- Les tables Adj-RIB-Out (Adjacency Routing Information Base Out), qui stockent les routes destinées aux routeurs voisins, ont été réécrites. Les optimisations mises en œuvre lors de cette réécriture ont permis de réduire considérablement la consommation de mémoire et d'améliorer les performances ; par exemple, sur les serveurs IXP (Internet Exchange Point) de grande taille, la consommation de mémoire a été réduite de plus de 50 %.
- Le traitement des messages UPDATE a été rationalisé et divisé en deux phases : d’abord, les tables Adj-RIB-In, Loc-RIB et FIB sont mises à jour, puis les tables Adj-RIB-Out sont traitées séparément. Cette nouvelle méthode a permis de réduire la latence, car la mise à jour des tables Adj-RIB-Out représente la majeure partie du temps de traitement.
- Une nouvelle implémentation de table de hachage évolutive est utilisée, ce qui améliore les performances en plaçant plus efficacement les données dans le cache.
- Ajout de nouvelles métriques pour suivre le temps passé à exécuter les différentes étapes du cycle de traitement des événements dans le moteur de routage.
Source: opennet.ru
