Si vous lisez ceci, vous êtes probablement d'accord pour dire que la révolution de l'Open Networking est réelle ! J'ai récemment assisté au sommet mondial de l'OCP et au sommet ONE de la Fondation Linux, et il y avait effectivement de l'électricité dans l'air. La taille de la communauté a augmenté de façon spectaculaire et elle attire chaque jour de nouveaux utilisateurs et vendeurs.

Chez Hedgehog, nous construisons une structure de réseau en utilisant un logiciel entièrement libre NOS (SONiC) pour les charges de travail modernes natives du nuage. Lorsque je parle aux gens de ce qui se passe dans l'écosystème SONiC, la réponse la plus fréquente est "N'est-ce pas ce que Cumulus Networks a essayé de faire ?"

Vous voyez, le "réseautage ouvert" n'est pas nouveau. Tous ceux qui se sont intéressés à ce segment de l'industrie des réseaux connaissent probablement l'ascension d'une société appelée Cumulus Networks.

Entrez dans la tortue-fusée

Cumulus a connu une ascension fulgurante, mais n'a pas réussi à créer ce dont le secteur avait besoin, une véritable révolution.

Cumulus a basé toute sa stratégie d'entreprise sur l'idée que toute l'infrastructure des serveurs était déjà passée des systèmes d'exploitation propriétaires à Linux. Les administrateurs de serveurs disposaient désormais d'outils (Ansible/Chef/Puppet) qui leur permettaient de gérer des milliers de périphériques, mais les opérateurs de réseaux étaient coincés avec des outils de l'âge de pierre basés sur l'interface CLI, et par conséquent, ils ne pouvaient pas faire évoluer leur expertise pour gérer davantage de périphériques. Cumulus s'est donc lancé dans la création d'un système d'exploitation réseau (NOS) basé sur une distribution générique (Debian) qui pourrait fonctionner sur du matériel en boîte blanche.  

La commutation en boîte blanche était également quelque peu nouvelle à l'époque. Les plus gros clients au monde (principalement des hyperscalers) achetaient des commutateurs de base auprès de fabricants de matériel d'origine (ODM) qui contenaient des ASIC Broadcom, Marvell ou Mellanox. Étant donné que Cisco utilisait à l'époque le Broadcom Trident 2 dans un grand nombre de ses produits, Cumulus pouvait promettre le même niveau de débit à condition d'obtenir le logiciel nécessaire pour programmer correctement les ASIC de Broadcom. ASIC du matériel.

C'était le plan, en tout cas. Ce concept a suscité beaucoup d'enthousiasme. À l'époque, les administrateurs de réseaux ne manquaient pas de reproches, qu'il s'agisse de licences coûteuses, d'optiques SFP propriétaires à des prix insensés, identiques à celles que les clients pouvaient acheter pour un dixième du prix, ou encore de l'abandon d'une plate-forme après la sortie d'une nouvelle.  Un analyste bien connu est même allé jusqu'à mentionner que Cumulus et la commutation de boîtes blanches étaient une menace existentielle pour les grands vendeurs de boîtes. Cette prédiction était basée sur le fait que les clients étaient prêts à abandonner leurs CLI pour un prompt bash linux.

Eh bien, Cumulus a décollé et a effectivement acquis beaucoup de clients, mais il était incroyablement difficile d'obtenir chaque client. Vous voyez, de nombreux fournisseurs avaient mis en place des tactiques de vente intéressantes en 2000-2010. L'une de ces tactiques était une campagne de marketing et de vente appelée "Allumez-la". En gros, les SE avaient pour instruction d'inciter les clients à activer toutes les fonctions possibles, car cela créerait un verrouillage pour les ventes futures. La configuration d'un appareil ne pouvait pas être facilement convertie à la syntaxe d'un autre fournisseur car plusieurs des fonctionnalités n'existaient même pas pour le second fournisseur. Certaines de ces fonctionnalités étaient en effet intéressantes, d'autres n'étaient qu'un bagage supplémentaire. Les clients se souciaient peu du fait que leurs configurations devenaient de plus en plus propriétaires. Cette initiative a fonctionné et de nombreux clients de l'époque avaient des demandes de propositions ou des demandes de devis qui mentionnaient des fonctionnalités propriétaires comme exigences.

Afin d'acquérir des clients, Cumulus s'est lancé dans une guerre de parité des fonctionnalités avec Cisco et Arista. En gros, ils ont essayé d'ajouter toutes les fonctionnalités demandées par le marché. Certaines de ces fonctionnalités étaient vraiment nécessaires, d'autres non. Mais le défi était que Cumulus devait obtenir un dispositif linux pour faire ce qu'un commutateur Cisco pouvait faire. Et cela posait quelques VRAIS GROS problèmes, car Linux a été conçu pour être un système d'exploitation de serveur, il ne se souciait pas vraiment des meilleures pratiques de mise en réseau. Ainsi, toutes sortes de choses n'étaient pas présentes ou ne fonctionnaient pas idéalement pour la mise en réseau. Jetons un coup d'oeil aux grands problèmes et à la façon dont Cumulus les a résolus :

Les contributions de Cumulus au réseau ouvert

Accélération des ASIC de commutation - switchd & SAI

Linux n'a pas été conçu à l'origine pour gérer un commutateur Ethernet. Il n'y avait pas de démons ou de services pour programmer et gérer la TCAM ou les tables de flux. Les administrateurs de serveurs n'avaient rien à redire au fait que de nouveaux flux soient programmés dans les cartes réseau quelques secondes après qu'ils aient effectué un changement. Mais pour les réseaux de centres de données ? Quelques secondes, c'est une éternité. Cumulus a donc créé un nouveau démon appelé switchd, chargé de gérer le matériel et l'ASIC. À l'époque, il s'agissait d'un concept totalement nouveau pour les clients. Malheureusement, Cumulus a pris la décision stratégique de garder ce bout de code propriétaire et fermé. Comme switchd est nécessaire pour que Cumulus fonctionne sur le matériel de commutation, cela a donné lieu à l'étrange distinction marketing entre "Open Networking" (réseau ouvert) et "Open Source" (source ouverte). Vous voyez, Cumulus Linux était "Open Networking", c'est-à-dire qu'il vous permettait de consommer ce nouveau modèle matériel/logiciel désagrégé, mais il n'était pas complètement open source. Switchd ne fonctionnait pas correctement si l'utilisateur n'entrait pas une clé de licence. Avait SAI existait, Cumulus aurait eu plus d'options pour potentiellement changer de source, mais une fois de plus, le timing est roi !

Mais c'était une idée vraiment cool et c'était le précurseur de l'interface d'abstraction de commutation (SAI) que nous utilisons tous maintenant dans SONiC pour prendre en charge plusieurs plateformes matérielles.

Routage de couche 3 - Quagga devient FRR

Linux a toujours manqué d'une très bonne pile de routage. À l'époque, il n'y avait pas beaucoup d'options : les routes statiques, un logiciel de routage propriétaire et coûteux, ou un logiciel bizarre appelé Quagga. Tout le monde sait qu'il a eu un moment "WTF" quand il a entendu quelqu'un mentionner "Quagga" pour la première fois. Quel nom bizarre, n'est-ce pas ? Quagga est une espèce de zèbre qui a été chassée jusqu'à l'extinction au 19e siècle. Cela aurait peut-être dû laisser présager de ce qui lui est arrivé. Quoi qu'il en soit, Quagga (le truc de réseau, pas le cheval émo) est une suite de démons de protocole de routage incluant BGP et OSPF. Avant Cumulus, Quagga était surtout expérimental. Il avait beaucoup de bogues et n'était pas vraiment évolutif. Il manquait beaucoup de boutons pour les nerds de BGP. Cumulus a commencé à améliorer Quagga et à transmettre toutes les modifications au mainteneur, qui se trouvait être une seule personne utilisant une méthodologie bizarre de contrôle de version. Cela a nécessité une tonne d'ingénierie. Déterminer les limites réelles de l'échelle des routes pour FIB et TCAM est délicat si vous êtes le responsable produit d'un seul appareil, mais sur plusieurs ASIC, CPU, SerDes, blocs de port et optiques ? 

C'est fou, non ? Mais en effet, Cumulus est allé de l'avant avec la détermination de dépasser l'ingénierie et l'automatisation de cette complexité. Au fil du temps, les performances de Quagga sont devenues assez fiables et il a été démontré qu'il pouvait prendre en charge l'ingestion de la totalité de la table de routage mondiale. Nous savons tous que le FRR peut gérer la table Internet, qui est vraiment aussi complexe et sale que possible. Cependant, en raison de problèmes liés à la vitesse à laquelle le mainteneur original intégrait les changements, Cumulus a finalement décidé de bifurquer Quagga vers un nouveau projet appelé Free Range Routing (FRR). Ce projet est désormais la suite de routage open source la plus largement déployée et utilisée, et fonctionne dans des nuages massifs tels qu'Azure et AWS.

Les idées géniales deviennent légitimes

C'est en fait l'un de mes exemples préférés de la façon dont Cumulus a démontré la démocratisation des réseaux. BGP Unnumbered. C'est vrai, saviez-vous que ce n'était pas une création d'un "grand fournisseur" ? Cumulus a conçu, peaufiné et promu la mise en œuvre de BGP Unnumbered, puis a laissé tout le monde copier son chef-d'œuvre. La copie est la forme la plus sincère de la flatterie, n'est-ce pas ? D'autres fournisseurs ont implémenté cette technique simple dans leur NOS pratiquement du jour au lendemain.

En fait, Cumulus construisait un réseau linux, optimisé pour le centre de données.

Gestion des interfaces réseau Linux - ifupdown obtient une mise à jour

Comme je l'ai déjà dit, Linux n'a pas été conçu pour être un système d'exploitation de commutation, et c'était douloureusement évident chaque fois que vous essayiez d'apporter des modifications à un seul port avec les commandes réseau natives de Linux. En fait, si vous vouliez modifier la configuration d'un port, ou même rebondir sur un port, vous deviez rebondir sur tous les ports du serveur en même temps. Ce n'est pas un gros problème pour un serveur lorsque vous faites de la maintenance, mais imaginez que vous rebondissez une interface sur un commutateur à 48 ports et que tous les ports tombent en panne, c'est ridicule et inacceptable dans un centre de données. Il s'agissait d'une conception technique assez ancrée dans Linux et la modifier demandait une quantité ÉNORME d'efforts. Cumulus a finalement publié ifupdown2, qu'ils ont upstreamé afin que tout le monde puisse bénéficier de leur travail, et maintenant les nouvelles capacités de gestion des ports peuvent être appréciées par l'ensemble de la communauté des réseaux ouverts.

Automatisation et programmabilité - Les CLI se tournent vers Ansible

Cumulus n'a pas fourni de CLI ou d'API lors de son lancement. L'idée était que la CLI était une impasse et que personne ne devait utiliser la CLI pour gérer un commutateur de centre de données. Cumulus a donc pris les devants et créé les premiers véritables playbooks Ansible pour automatiser un réseau, ce qui a incité Cisco à faire un rapide "me too" en demandant à un développeur tiers de créer des outils Ansible pour le Nexus 9k. En effet, l'approche DevOps a été très avant-gardiste et a réellement permis au secteur d'évoluer plus rapidement vers un modèle plus programmable.

Cela représente BEAUCOUP de développement et de résolution de la dette technique pour une startup avec peu de revenus. Certaines personnes savent déjà comment cela a fini...

En 2020, Nvidia a acquis Cumulus Networks, peu après avoir acheté Mellanox. À l'époque, Cumulus soutenait deux grands fournisseurs d'ASIC, Broadcom et Mellanox. Peu après l'annonce de l'opération, Broadcom a révoqué l'accès de Cumulus au SDK Broadcom, ce qui a mis fin au support de Cumulus pour les ASIC Broadcom. Selon une estimation non officielle, 90% des clients de Cumulus utilisaient des ASIC Broadcom (vendus sous le nom de Dell, Edgecore, etc.). Les capacités multi-fournisseurs de Cumulus ont pris fin et Cumulus fait désormais partie du portefeuille de réseaux de Nvidia, avec des optimisations spécifiques pour les charges de travail AI/ML et les réseaux de stockage.

Applaudissons Cumulus !

J'aime dire aux gens que Cumulus a abattu un mur dans l'industrie en y mettant tout son poids, se cassant ainsi le cou. Ce que je veux dire, c'est que Cumulus a donné un élan incroyable à la communauté de l'open source et des réseaux ouverts, mais en faisant cela, ils ont exercé trop de ressources (coûts de développement et temps) pour pouvoir se différencier efficacement au-delà d'un simple NOS linux. Cumulus a lancé la révolution que nous vivons actuellement, mais le marché a été trop lent à adopter le modèle désagrégé. Bien qu'ils n'aient pas été le perturbateur industriel que tout le monde souhaitait, ils ont brisé un grand nombre de modèles d'affaires existants, et de nombreux fournisseurs luttent encore pour faire face à la nouvelle réalité.

Sans plus attendre, au nom de la communauté, je voudrais adresser un énorme MERCI à Cumulus et à tous les employés qui ont contribué à faire progresser l'état de l'art des réseaux.

En quoi aujourd'hui est-il différent ?

Cumulus n'a pas attaché efficacement sa technologie à une transition majeure du marché. On pourrait dire qu'ils ont essayé de créer la transition eux-mêmes, mais bash au lieu de CLI et whitebox T2 au lieu de Cisco T2 n'était pas suffisant pour créer un facteur de motivation pour les entreprises de mettre à jour tous leurs NOC et systèmes de surveillance, ainsi que de remplacer tous les CCIE par des experts linux. Ce n'était pas suffisant pour créer une transition. Au lieu de cela, ils auraient dû chercher une transition majeure à laquelle se rattacher.

SONiC a un énorme élan. Il a été conçu pour être automatisé comme une application moderne. Hedgehog s'efforce d'apporter tous les avantages de la transition de la plateforme Kubernetes au réseau SONiC. Cela inclut actuellement les tissus de réseau des centres de données et les plateformes d'hébergement d'applications en périphérie, mais s'étendra un jour aux campus, aux réseaux étendus et à d'autres modèles de déploiement. Aucun autre NOS open-source n'a une communauté de contributeurs aussi importante, et avec tous les principaux fournisseurs soutenant SONiC, il est prévu que SONiC soit le NOS standard pour la majorité des nouvelles constructions dans un avenir proche. Le temps de l'adoption de SONiC est MAINTENANT.

Jusqu'à la prochaine fois...