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é s'est considérablement accrue 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 ?"

L'"Open Networking" n'est pas une nouveauté. Tous ceux qui ont suivi ce segment de l'industrie des réseaux connaissent probablement la montée en puissance 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 d'appareils, alors que les opérateurs de réseaux restaient bloqués sur des ensembles d'outils de l'âge de pierre, basés sur des CLI encombrants, et ne pouvaient donc pas faire évoluer leur expertise pour gérer davantage d'appareils. Cumulus a donc entrepris de créer un système d'exploitation de réseau (NOS) basé sur Linux et sur une distribution générique (Debian) qui pourrait fonctionner sur du matériel de type 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'est en tout cas ce qui était prévu. Ce concept a suscité beaucoup d'enthousiasme. À l'époque, les administrateurs de réseau avaient de nombreuses plaintes à formuler, qu'il s'agisse des licences coûteuses, des prix exorbitants des optiques SFP propriétaires qui étaient identiques à ce que les clients pouvaient acheter pour 1/10e du prix, ou du "churn" des boîtiers (la fin de vie d'une plateforme après la sortie d'une nouvelle). Un analyste bien connu est même allé jusqu'à mentionner que Cumulus et la commutation des boîtes blanches constituaient une menace existentielle pour les principaux fournisseurs de boîtes. Cette prédiction était basée sur le fait que les clients étaient prêts à abandonner leurs CLIs pour une invite linux bash.

Cumulus a décollé et a effectivement acquis un grand nombre de clients, mais il était incroyablement difficile d'obtenir chaque client. En effet, de nombreux fournisseurs avaient mis en place des tactiques de vente intéressantes entre 2000 et 2010. L'une de ces tactiques était une campagne de marketing et de vente nommée "Allumez-la". En gros, les SE avaient pour instruction d'inciter les clients à activer toutes les fonctionnalités 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 parce que plusieurs des fonctionnalités n'existaient même pas pour le second fournisseur. Certaines de ces fonctionnalités étaient vraiment intéressantes, d'autres n'étaient que des bagages supplémentaires. Les clients ne se souciaient guère du fait que leurs configurations devenaient de plus en plus propriétaires. Cette initiative a fonctionné et de nombreux clients avaient à l'époque des appels d'offres ou des demandes de renseignements qui mentionnaient les caractéristiques propriétaires comme des 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 fonctions étaient absolument nécessaires, d'autres non. Mais le défi était que Cumulus devait faire en sorte qu'un dispositif Linux fasse ce qu'un commutateur Cisco pouvait faire. Et cela posait quelques VRAIS GROS problèmes : linux ayant été conçu pour être un système d'exploitation de serveur, il ne se souciait pas vraiment des meilleures pratiques en matière de réseau. Ainsi, toutes sortes de choses n'existaient pas ou ne fonctionnaient pas idéalement pour la mise en réseau. Jetons un coup d'œil aux principaux problèmes et à la façon dont Cumulus les a résolus :

Contributions de Cumulus au réseau ouvert

Accélération ASIC des commutateurs - 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. Si SAI avait existé, Cumulus aurait eu plus d'options pour potentiellement mettre Switch en open 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 la 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 Cumulus est allé de l'avant avec détermination pour surpasser l'ingénierie et l'automatisation de cette complexité. Au fil du temps, les performances de Quagga sont devenues très fiables et il a été démontré qu'elles pouvaient être mises à l'échelle pour prendre en charge l'ingestion de l'ensemble de la table de routage mondiale. Nous savons tous que 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 forker Quagga dans un nouveau projet appelé Free Range Routing (FRR). Ce projet est aujourd'hui la suite de routage open source la plus largement déployée et utilisée, fonctionnant 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 de la mise en réseau. BGP Unnumbered. C'est vrai, saviez-vous qu'il ne s'agissait pas d'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 mis en œuvre 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 de l'interface réseau de Linux - ifupdown bénéficie d'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 l'on essayait d'apporter des modifications à un seul port avec les commandes de réseau natives de Linux. En fait, si vous vouliez changer 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 très grave pour un serveur lorsque vous faites de la maintenance, mais imaginez que vous rebondissiez sur une interface d'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 nécessitait d'énormes efforts. Cumulus a finalement publié ifupdown2, qu'ils ont remonté pour que tout le monde puisse bénéficier des avantages 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 le CLI était une impasse et que personne ne devrait utiliser le CLI pour gérer un commutateur de tissu de centre de données. Cumulus a donc pris les devants et a créé les premiers vrais playbooks Ansible pour automatiser un réseau, ce qui a poussé Cisco à faire un " moi aussi " rapide en demandant à un développeur tiers de créer des outils Ansible pour le Nexus 9k. En effet, l'approche DevOps-first était très avant-gardiste et a réellement permis à l'industrie d'évoluer plus rapidement vers un modèle plus programmable.

C'est beaucoup de développement et de résolution de la dette technique pour une startup avec peu de revenus. Certains savent déjà comment cela s'est terminé...

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 la transaction, Broadcom a révoqué l'accès de Cumulus au SDK Broadcom, mettant ainsi fin à la prise en charge des ASIC Broadcom par Cumulus. 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.

Bravo à 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 réussi à associer sa technologie à une transition majeure sur le marché. On pourrait dire qu'ils ont essayé de créer la transition elle-même, mais bash au lieu de CLI et whitebox T2 au lieu de Cisco T2 n'ont pas suffi à motiver les entreprises à mettre à jour tous leurs NOC et leurs systèmes de surveillance, ainsi qu'à remplacer tous les CCIE par des experts en linux. Il ne suffisait pas de créer une transition. Au lieu de cela, ils auraient dû chercher une transition majeure à laquelle s'attacher.

SONiC bénéficie d'un énorme élan. Il a été conçu pour être automatisé comme une application moderne. Hedgehog s'efforce d'apporter toute la bonté de la transition de la plateforme Kubernetes à la mise en réseau SONiC. Cela inclut actuellement les tissus de réseau de centre de données et les plates-formes d'hébergement d'applications en périphérie, mais s'étendra un jour au campus, au réseau étendu 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 qui soutiennent maintenant SONiC, on s'attend à ce que SONiC soit le NOS standard pour la majorité des nouveaux builds dans un avenir proche. Le temps de l'adoption de SONiC est venu.

Jusqu'à la prochaine fois...