Dernière modification le 10 août 2021
Au début des années 2010, je cherchai une solution pour construire un générateur de trafic Ethernet à haut débit pour des tailles de paquets de 64 octets et le moins cher possible afin de mettre en œuvre le RFC2544. Après de nombreuses approches et de nombreux développements qui n’ont abouti à rien de significatif, c’est en 2014 que la question du générateur de trafic pour tester les matériels en maquette est devenue cruciale. La référence dans ce domaine était Ixia, mais ceux qui connaissent les prix comprennent que ce n’était pas une solution accessible à tout le monde. Dans le domaine commercial, un de ses concurrents intéressant et dont j’ai suivi la progression était Xena. L’avantage de ces solutions n’était pas tant la puissance des générateurs mais le niveau d’intégration et de finition de la couche logicielle qui permettait de lancer facilement des tests conformes aux standards.
Les standards qui me servaient de référence étaient les suivants :
- RFC2544 (Benchmarking Methodology for Network Interconnect Devices)
- RFC6815 (Applicability Statement for RFC2544)
- RFC1242 (Benchmarking Terminology for Network Interconnection Devices)
- RFC6349 (Framework for TCP Throughput Testing)
- RFC3918 (Methodology for IP Multicast Benchmarking)
- RFC2432 (Terminology for IP Multicast Benchmarking)
- RFC2889 (Benchmarking Methodology for LAN Switching Devices)
- RFC6985 (IMIX Genome: Specification of Variable Packet Sizes for Additional Testing)
- ITU-T Y.1564 (Ethernet service activation test methodology)
Pour tenter une approche autonome, j’ai commencé par tester pktgen qui était inclus dans le noyau Linux. Même si cet outil est intéressant, il n’a pas fallu longtemps pour voir sa limite en terme de performance. Il était déjà difficile de maintenir 1,488 Mpps avec des trames de 64 octets (1 Gbps) en utilisant une machine standard, alors ne parlons pas de la puissance qu’il fallait pour tenir 14,88 Mpps (10 Gbps). Il était évident qu’il fallait se diriger vers les recherches du domaine « Fast Packet I/O ».
Je me suis rapproché de Luigi RIZZO et Vincenzo MAFFIONE (Université de Pise) pour tester le framework netmap. Il était accompagné d’une version de pkt-gen qui s’appuyait sur les capacités « high speed packet I/O » de netmap. C’était très prometteur car les objectifs de performance pouvaient être atteint avec des machines de faible capacité (un coeur à 900 MHz pouvait envoyer 14,88 Mpps) et les drivers Ethernet pouvaient être maintenus en activité en les patchant. De ce fait, les interfaces pouvaient aussi bien être utilisées par les applications traditionnelles Linux, que par les applications spécifiquement développées pour utiliser la partie du patch du driver. VALE, le switch virtuel qui accompagnait netmap, était également intéressant pour mettre en relation des éléments sans passer par le bridge Linux qui était trop limité par la capacité CPU du système. FreeBSD 10 a intégré de base netmap, et bien que l’aspect Linux ait été maintenu, il n’y a pas eu beaucoup de portage d’applications sur netmap.
Au même moment, Keith WILES (d’abord chez Wind River puis passé chez Intel) développait une version de pktgen sur DPDK (Data Plane Development Kit). Je l’ai contacté pour tester sa version et j’ai obtenu les mêmes résultats de performance qu’avec netmap, qui plus est avec une version de pktgen plus avancée et plus conviviale. Pour remplacer le bridge Linux, on disposait du projet Open vSwitch qui était supporté sur DPDK. Grâce à son pilotage Openflow, il devenait même aisé de fabriquer un NPB (Network Packet Broker). De plus, Canonical annonçait le support natif de DPDK dans la future version Ubuntu Server 16.04. Il devenait évident que DPDK profitait du support d’acteurs majeurs du marché et qu’il allait s’implanter dans le monde Linux. L’histoire a confirmé ce point puisque DPDK se retrouve supporté par de plus en plus de fabricants de contrôleurs Ethernet et il est utilisé comme une référence dans divers projets comme fd.io par exemple. L’organisation FD.io s’est structurée pour rassembler des projets dont l’objectif est d’accélérer le « Data Plane » sur diverses architectures (x86, ARM, et PowerPC) et différents environnements (Bare-metal, VM, conteneur), jusqu’à pouvoir remplacer les matériels spécialisés. Le seul point qui me gênait était que, contrairement à netmap, l’usage de DPDK nécessitait de dédier des ressources CPU et interfaces. Celles-ci n’étaient plus accessibles pour les applications Linux traditionnelles. Il fallait donc prévoir des machines avec plusieurs ports Ethernet et plusieurs cœurs.
Des développements dans le domaine du générateur de trafic sur DPDK ont commencé à être disponibles en version avancée en 2016. Le premier outil Open Source que j’ai testé était WARP17. C’était, et c’est toujours, un outil intéressant derrière lequel plane l’ombre de Juniper Networks. C’est un générateur appelé « stateful » dans le sens où son objectif est de générer des trafics IP (TCP, HTTP ou UDP) pour valider une capacité en terme de nombres de sessions qui peuvent être encaissées par le DUT (Device Under Test). Bien qu’utile, je cherchais plus un générateur capable d’envoyer des trames en force brute, c’est à dire un générateur « stateless ».
Un autre produit Open Source, avec l’ombre de Cisco derrière, commençait à faire parler de lui. Il s’agissait de TRex. Ce générateur peut fonctionner aussi bien en mode « stateful » que « stateless ». Il est totalement paramétrable grâce à des scripts personnalisables. Le produit est très avancé en terme de fonctionnalités et, même s’il n’a pas une suite logicielle aussi complète que certains produits commerciaux, il peut rivaliser avec eux pour un usage standard et ce jusqu’à 20 Mpps en utilisant simplement un serveur avec la couche DPDK et les interfaces Ethernet appropriées et supportées.
Fin 2016, j’ai sorti mes deux premières appliances TRex sur une base de processeur AMD quad core Jaguar à 1 GHz et 4 GB de mémoire pour le générateur 1G et sur la base d’un serveur Xeon D-1518, 32GB de RAM, 64GB de flash, des interfaces 10G fournie par le SoC (System-on-a-Chip) et une carte Ethernet équipée d’un contrôleur Intel X540 pour le générateur capable de tenir les 14,88 Mpps sur une interface 10G.
Très utile pour tester les performances brutes d’un DUT, cette approche manquait de portabilité. S’appuyant sur DPDK, il n’était possible d’utiliser TRex que sur des serveurs X86 dont les interfaces étaient supportées. Dans des cas où l’objectif était seulement de vérifier le fonctionnement de certains mécanismes sur le DUT, l’appliance prenait l’allure d’un canon pour écraser une mouche.
J’ai donc décidé d’investiguer un autre outil dont on entendait beaucoup parler dans le milieu : Ostinato. Qui plus est l’histoire de ce produit m’interpellait. Son créateur, Srivats P. avait rencontré les mêmes raisonnements que moi face aux produits commerciaux, et, alors qu’il proposait à son employeur de l’époque de développer un générateur, il n’a pas obtenu le temps disponible qu’il avait demandé et s’est lancé sur son temps personnel dans la mise au point du produit qui est devenu ce qu’il est aujourd’hui. Le résultat est un concept très bien pensé. Le générateur gratuit appelé « drone » peut être installé sur différents systèmes positionnés à plusieurs endroits de l’architecture et l’ensemble est piloté par une interface graphique payante (à prix très raisonnable) sur Windows, MAC ou Linux Desktop. Il est également possible de piloter les différentes instances de « drone » à l’aide des APIs Python (licence payante aussi). Ostinato est un générateur « stateless » dont l’objectif n’est pas de proposer des performances exceptionnelles à tout prix, mais plutôt une souplesse de construction des flux. Pour se faire plaisir, il est tout à fait possible de remplir un lien Ethernet 10G en utilisant des « jumbo frames » de 9018 octets avec « drone » installé sur un serveur Xeon E5-2620v4 @ 2.10GHz (8 cœurs), 32 GB de RAM et une interface Ethernet 40G avec un contrôleur Intel XL710.
Srivats avait testé un portage sur DPDK en 2014 et il avait promis qu’un portage officiel verrait le jour, et c’est finalement sur XDP qu’il a développé le « Turbo Drone » soumis à licence et permettant de générer du trafic à 10, 25 ou 40 Gbps. XDP (eXpress Data Path) est une implémentation eBPF (Extended Berkeley Packet Filter) pour l’interception précoce des paquets. Les paquets reçus ne sont pas envoyés directement à la pile IP du noyau, mais peuvent être envoyés à l’espace utilisateur pour traitement. Les utilisateurs peuvent décider quoi faire avec le paquet (supprimer, renvoyer, modifier, passer au noyau). XDP est conçu comme une alternative à DPDK. Il offre des fonctionnalités et mécanismes déjà implémentés dans le noyau Linux depuis la version 4.8 (les utilisateurs de DPDK doivent tout implémenter dans l’espace utilisateur).
La partie « drone » étant gratuite, je l’intègre maintenant sur mes nouvelles « appliances automation » et pour la partie payante, le travail proposé par Srivats mérite largement le prix demandé, car même s’il travaille maintenant chez Juniper Networks, c’est sur son temps personnel qu’il continue à faire évoluer ce produit.