Wenn Sie dies lesen, stimmen Sie wahrscheinlich zu, dass die Open Networking Revolution real ist! Ich habe vor kurzem am OCP Global Summit und am Linux Foundation ONE Summit teilgenommen, und es lag tatsächlich Elektrizität in der Luft. Die Größe der Community ist dramatisch gewachsen, und sie zieht jeden Tag neue Benutzer und Anbieter an.

Bei Hedgehog bauen wir eine Netzwerkstruktur mit einem vollständig quelloffenen NOS (SONiC) für die modernen Cloud-nativen Workloads. Wenn ich mit Leuten darüber spreche, was im SONiC-Ökosystem passiert, ist die häufigste Antwort: "Ist das nicht das, was Cumulus Networks versucht hat?"

Sie sehen, "Open Networking" ist nicht neu. Jeder, der sich in diesem Segment der Netzwerkbranche auskennt, ist wahrscheinlich mit dem Aufstieg eines Unternehmens namens Cumulus Networks vertraut.

Auftritt der Raketenschildkröte

Cumulus hatte einen aufregenden Aufstieg, schaffte es aber nicht, das zu schaffen, was die Branche brauchte: eine ECHTE REVOLUTION.

Die gesamte Unternehmensstrategie von Cumulus basierte auf der Idee, dass die gesamte Server-Infrastruktur bereits von proprietären Betriebssystemen auf Linux umgestellt worden war. Server-Administratoren verfügten nun über Tools (Ansible/Chef/Puppet), mit denen sie Tausende von Geräten verwalten konnten, während Netzwerkbetreiber mit klobigen, CLI-basierten Tools aus der Steinzeit feststeckten und daher ihr Know-how nicht skalieren konnten, um mehr Geräte zu verwalten. Also machte sich Cumulus daran, ein linuxbasiertes Netzwerkbetriebssystem (NOS) zu entwickeln, das auf einer generischen Distribution (Debian) basiert und auf White-Box-Hardware laufen kann.

White-Box-Switching war zu diesem Zeitpunkt ebenfalls noch recht neu. Die größten Kunden der Welt (meist Hyperscaler) kauften Standard-Switches von Originalgeräteherstellern (ODMs), die ASICs von Broadcom, Marvell oder Mellanox enthielten. Da Cisco zu dieser Zeit Broadcom Trident 2 in vielen seiner Produkte einsetzte, konnte Cumulus den gleichen Durchsatz versprechen, vorausgesetzt, man verfügte über die Software zur korrekten Programmierung der ASIC Hardware.

Jedenfalls war das der Plan. Es gab eine Menge Aufregung um dieses Konzept. Die Netzwerkadministratoren beschwerten sich damals über teure Lizenzen, über wahnsinnig teure proprietäre SFP-Optiken, die identisch waren mit dem, was die Kunden für ein Zehntel des Preises kaufen konnten, und über die "Abwanderung" von Boxen (EOL einer Plattform, sobald eine neue auf den Markt kommt). Ein bekannter Analytiker ging sogar so weit, zu erwähnen dass Cumulus und White-Box-Switching eine existenzielle Bedrohung für die großen Box-Anbieter darstellen. Diese Vorhersage beruhte auf der Bereitschaft der Kunden, ihre CLIs für einen Linux-Bash-Prompt aufzugeben.

Nun, Cumulus startete durch und gewann tatsächlich eine Menge Kunden, aber es war unglaublich schwer, jeden einzelnen Kunden zu gewinnen. Viele Anbieter hatten in den Jahren 2000 bis 2010 einige interessante Verkaufstaktiken angewandt. Eine dieser Taktiken war eine Marketing- und Vertriebskampagne namens "Einschalten". Im Grunde genommen wurden die SEs angewiesen, die Kunden dazu zu bringen, jede einzelne Funktion zu aktivieren, die ihnen möglich war, da dies eine Bindung für zukünftige Verkäufe schaffen würde. Eine Konfiguration für ein Gerät konnte nicht einfach auf die Syntax eines anderen Anbieters umgestellt werden, da einige der Funktionen für den zweiten Anbieter gar nicht existierten. Einige dieser Funktionen waren in der Tat cool, andere waren nur zusätzlicher Ballast. Den Kunden machte es nicht viel aus, dass ihre Konfigurationen immer mehr proprietär wurden. Diese Initiative funktionierte, und viele Kunden hatten damals RFP/RFQs, in denen proprietäre Funktionen als Anforderungen aufgeführt waren.

Um Kunden zu gewinnen, trat Cumulus in einen Funktionsparitätskrieg mit Cisco und Arista ein. Im Grunde versuchte man, alle vom Markt geforderten Funktionen hinzuzufügen. Einige dieser Funktionen wurden definitiv benötigt, andere nicht. Aber die Herausforderung bestand darin, dass Cumulus ein Linux-Gerät dazu bringen musste, das zu tun, was ein Cisco-Switch tun konnte. Und dabei gab es einige WIRKLICH GROSSE Probleme, denn Linux war als Server-Betriebssystem konzipiert und kümmerte sich nicht wirklich um bewährte Netzwerkpraktiken. Daher waren alle möglichen Dinge nicht vorhanden oder funktionierten nicht ideal für die Vernetzung. Werfen wir einen Blick auf die großen Probleme und darauf, wie Cumulus diese Probleme gelöst hat:

Die Beiträge von Cumulus zum Open Networking

ASIC-Beschleunigung für Schalter - switchd & SAI

Linux war ursprünglich nicht für die Verwaltung eines Ethernet-Switches konzipiert. Es gab keine Daemons oder Dienste zur Programmierung und Verwaltung von TCAM oder Flusstabellen. Serveradministratoren hatten kein Problem damit, dass neue Datenflüsse wenige Sekunden nach einer Änderung in die NICs programmiert wurden. Aber für Netzwerke in Rechenzentren? Ein paar Sekunden sind eine Ewigkeit. Also entwickelte Cumulus einen neuen Daemon namens switchd, der für den Umgang mit der Hardware und dem ASIC zuständig war. Das war damals ein völlig neues Konzept für die Kunden. Leider hat Cumulus die strategische Entscheidung getroffen, diesen speziellen Teil des Codes proprietär und als Closed-Source zu halten. Da switchd erforderlich ist, damit Cumulus auf Switching-Hardware läuft, führte dies zu der seltsamen Marketing-Unterscheidung zwischen "Open Networking" und "Open Source". Sie sehen, Cumulus Linux war "Open Networking", d. h. sie ermöglichten die Nutzung dieses neuen disaggregierten Hardware-/Softwaremodells, aber sie waren nicht vollständig quelloffen. Switchd würde ohne die Eingabe eines Lizenzschlüssels durch den Benutzer nicht richtig funktionieren. Hätte es SAI gegeben, hätte Cumulus mehr Möglichkeiten gehabt, Switchd als Open Source zu nutzen, aber auch hier gilt: Timing ist alles!

Aber das war eine wirklich coole Idee und der Vorläufer des Switch Abstraction Interface (SAI), das wir jetzt alle in SONiC verwenden, um mehrere Hardware-Plattformen zu unterstützen.

Schicht-3-Routing - Quagga wird FRR

Linux fehlte schon immer ein wirklich guter Routing-Stack. Zu dieser Zeit gab es nicht viele Optionen: statische Routen, eine proprietäre und teure Router-Software oder ein seltsames Softwarepaket namens Quagga. Jeder Einzelne weiß, dass er einen "WTF"-Moment hatte, als er zum ersten Mal jemanden "Quagga" erwähnen hörte. Was für ein bizarrer Name, oder? Quagga ist eine Zebraart, die im 19. Jahrhundert bis zur Ausrottung gejagt wurde. Vielleicht hätte das eine Vorahnung auf das sein sollen, was mit ihr passiert ist. Wie auch immer, Quagga (das Netzwerk-Ding, nicht das Emo-Pferd) ist eine Reihe von Routing-Protokoll-Dämonen, darunter BGP und OSPF. Vor Cumulus war Quagga hauptsächlich experimentell. Es hatte eine Menge Bugs und war nicht wirklich gut skalierbar. Viele BGP-Nerd-Knöpfe fehlten. Cumulus begann, Quagga zu verbessern und alle Änderungen an den Maintainer weiterzuleiten, der zufällig eine Einzelperson war und eine seltsame Versionskontrollmethode verwendete. Dies erforderte einen enormen technischen Aufwand. Die Bestimmung der tatsächlichen Skalierungsgrenzen für FIB und TCAM ist schwierig, wenn man der Produktmanager für ein Gerät ist, aber bei mehreren ASICs, CPUs, SerDes, Port-Blöcken und Optiken? 

Das ist doch verrückt, oder? Aber in der Tat hat Cumulus mit Entschlossenheit daran gearbeitet, diese Komplexität zu übertreffen und zu automatisieren. Im Laufe der Zeit wurde die Leistung von Quagga immer zuverlässiger, und es hat sich gezeigt, dass es die Aufnahme der gesamten globalen Routing-Tabelle unterstützen kann. Wir alle wissen, dass FRR die Internet-Tabelle verarbeiten kann, die wirklich so komplex und schmutzig ist, wie man nur sein kann. Aufgrund von Problemen mit der Geschwindigkeit, mit der der ursprüngliche Betreuer die Änderungen integrierte, beschloss Cumulus schließlich, Quagga in ein neues Projekt namens Free Range Routing (FRR) aufzuspalten. Dieses Projekt ist heute die am weitesten verbreitete und genutzte Open-Source-Routing-Suite, die in großen Clouds wie Azure und AWS läuft.

Coole Ideen werden echt

Dies ist eines meiner Lieblingsbeispiele dafür, wie Cumulus die Demokratisierung von Netzwerken demonstriert. BGP Unnumbered. Ja, richtig, wussten Sie, dass dies keine Kreation eines großen Anbieters war? Cumulus hat die Implementierung von BGP Unnumbered entworfen, ausgefeilt und beworben und dann jedem erlaubt, sein Meisterwerk zu kopieren. Kopieren ist die aufrichtigste Form der Schmeichelei, nicht wahr? Andere Anbieter haben diese einfache Technik praktisch über Nacht in ihr NOS implementiert.

Im Grunde hat Cumulus Linux-Netzwerke entwickelt, die für Rechenzentren optimiert sind.

Linux Network Interface Management - ifupdown erhält ein Upgrade

Wie ich bereits gesagt habe, war Linux nicht als Switch-Betriebssystem konzipiert, und das wurde schmerzlich deutlich, wenn man versuchte, mit den nativen Linux-Netzwerkbefehlen Änderungen an einem einzelnen Port vorzunehmen. Wenn man eine Portkonfiguration ändern oder sogar einen Port bouncen wollte, musste man im Grunde alle Ports des Servers auf einmal bouncen. Für einen Server ist das keine große Sache, wenn man Wartungsarbeiten durchführt, aber stellen Sie sich vor, Sie bouncen eine Schnittstelle an einem 48-Port-Switch und alle Ports fallen aus - das ist lächerlich und im Rechenzentrum inakzeptabel. Das war ein ziemlich tief verwurzeltes technisches Design in Linux, und es zu ändern, erforderte einen riesigen Aufwand. Cumulus veröffentlichte schließlich ifupdown2, das sie als Upstream zur Verfügung stellten, damit jeder von ihrer Arbeit profitieren konnte.

Automatisierung und Programmierbarkeit - CLIs wenden sich an Ansible

Als Cumulus auf den Markt kam, gab es weder eine CLI noch eine API. Die Idee war, dass CLI eine Sackgasse ist und niemand CLI für die Verwaltung eines Fabric-Switches im Rechenzentrum verwenden sollte. Also übernahm Cumulus die Führung und erstellte die ersten echten Ansible-Playbooks für die Automatisierung eines Netzwerks, was Cisco dazu veranlasste, ein schnelles "me too" zu machen und einen Drittentwickler zu beauftragen, Ansible-Tools für den Nexus 9k zu erstellen. Der DevOps-first-Ansatz war in der Tat sehr zukunftsweisend und hat die Branche dazu veranlasst, sich schneller in Richtung eines stärker programmierbaren Modells zu bewegen.

Das ist eine Menge Entwicklungsarbeit und die Beseitigung technischer Schulden für ein Startup mit geringen Einnahmen. Einige Leute wissen bereits, wie es dazu kam...

Im Jahr 2020 übernahm Nvidia Cumulus Networks, kurz nachdem es Mellanox gekauft hatte. Zu dieser Zeit unterstützte Cumulus zwei große ASIC-Anbieter, Broadcom und Mellanox. Kurz nach Bekanntgabe der Übernahme entzog Broadcom Cumulus den Zugriff auf das Broadcom-SDK und beendete damit die Unterstützung von Cumulus für Broadcom-ASICs. Eine inoffizielle Schätzung besagt, dass 90% der Cumulus Kunden Broadcom ASICs (verkauft als Dell, Edgecore, etc.) verwenden. Die Multi-Vendor-Fähigkeiten von Cumulus endeten und nun ist Cumulus ein Teil des Nvidia-Netzwerkportfolios, mit spezifischen Optimierungen für KI/ML-Workloads und Speichernetzwerke.

Applaus für Cumulus!

Ich erzähle den Leuten gerne, dass Cumulus eine Mauer in der Branche eingerissen hat, indem sie ihr ganzes Gewicht in die Waagschale geworfen und sich dabei im Grunde das Genick gebrochen haben. Damit meine ich, dass Cumulus der Open-Source- und Open-Networking-Gemeinschaft einen unglaublichen Impuls gegeben hat, aber dabei zu viele Ressourcen (Entwicklungskosten und -zeit) eingesetzt hat, so dass sie sich nicht effektiv von anderen Anbietern als Linux-NOS unterscheiden konnten. Cumulus hat diese Revolution, die wir gerade erleben, eingeleitet, aber der Markt war zu langsam, um das disaggregierte Modell zu übernehmen. Auch wenn Cumulus nicht der von allen gewünschte Disruptor der Branche war, so hat es doch viele alte Geschäftsmodelle zerstört, und viele Anbieter haben immer noch Schwierigkeiten, sich auf die neue Realität einzustellen.

Daher möchte ich im Namen der Community ein riesiges Dankeschön an Cumulus und alle Mitarbeiter aussprechen, die dazu beigetragen haben, den Stand der Technik im Bereich Networking voranzutreiben.

Was ist heute anders?

Cumulus hat seine Technologie nicht effektiv mit einem größeren Übergang im Markt verbunden. Man könnte argumentieren, dass sie versucht haben, den Übergang selbst herbeizuführen, aber Bash anstelle von CLI und Whitebox T2 anstelle von Cisco T2 war nicht genug, um einen Motivationsfaktor für Unternehmen zu schaffen, alle ihre NOCs und Überwachungssysteme zu aktualisieren und alle CCIEs durch Linux-Experten zu ersetzen. Es war nicht genug, um einen Übergang zu schaffen. Stattdessen hätten sie nach einem größeren Übergang suchen müssen, an den sie anknüpfen können.

SONiC hat eine ungeheure Eigendynamik. Es wurde entwickelt, um wie eine moderne Anwendung automatisiert werden. Hedgehog arbeitet daran, alle Vorzüge der Kubernetes-Plattform auf das SONiC-Netzwerk zu übertragen. Dies umfasst derzeit Netzwerk-Fabrics in Rechenzentren und Edge-Applikations-Hosting-Plattformen, wird sich aber eines Tages auf Campus-, WAN- und andere Bereitstellungsmodelle ausweiten. Kein anderes Open-Source-NOS hat eine so große Gemeinschaft von Mitwirkenden, und da alle großen Anbieter SONiC jetzt unterstützen, wird erwartet, dass SONiC in naher Zukunft das Standard-NOS für die Mehrzahl der neuen Builds sein wird. Die Zeit für SONiC Annahme ist JETZT.

Bis zum nächsten Mal...