nicht problemlos möglich, Netzwerk-hardware zweier Anbieter miteinan-der zu kombinieren. Wer schon einmal versucht hat, Jumbo-Frames zwischen Switches unterschiedlicher Hersteller zu nutzen, kennt das Problem.Hinzu kommt, dass ein Netzwerkadmin nicht automatisch Geräte anderer Anbie-ter administrieren kann, für die er nicht geschult ist. Wer etwa mit Cisco-Swit-chen umgehen kann, kann nicht automa-tisch auch Juniper-Hardware bedienen. Reine Linux-Admins sind in Sachen Netz-werkhardware aus eben diesen Gründen meist ohnehin sofort raus. In moderne Devops-Konzepte integrieren sich Swit-ches deshalb nur schwer: Meinst pflegen Unternehmen ihre Konfiguration fernab vom Rest der Installation.Das Quasi-Monopol der etablierten Her-steller ist in vieler Hinsicht ein Problem. Neben dem fehlenden Druck auf die Fea-ture-Entwicklung und der Lock-in-Prob-lematik behindert es insbesondere den Wettbewerb: Neuen Unternehmen fällt es schwer, mit eigener Netzwerkhardware Fuß zu fassen und eine kritische Größe zu erreichen. Mellanox ist dafür ein gu-tes Beispiel: Im Infiniband-Markt ist das israelische Unternehmen selbst praktisch der unangefochtene Marktführer – die Ethernet-Sparte der Firma, die einige äu-ßerst interessante Produkte hervorbringt, ist hingegen vielen Netzwerkern völlig unbekannt. Zudem behindern Switches mit pro-prietärer Software die Entwicklung zu-sätzlicher Funktionen: Drittanbieter kön-nen mit eigenen Produkten nicht einfach an vorhandene Geräte andocken, weil offene Standards und Schnittstellen feh-len. Entsprechende Kooperationen lassen Juniper & Co. sich teuer bezahlen.

Dell sorgte Anfang 2016 für Furore, als der – eher für seine Server- und Desktop-systeme bekannte – Hersteller ein Be-triebssystem für Netzwerkswitches na-mens OS 10 [1] präsentierte. Zwar liefen Switches von Dell auch bisher schon auf Basis des schlicht OS genannten Betriebs-systems, aber OS 10 geht in vielerlei Hin-sicht weiter – anders als seine Vorgänger basiert OS 10 auf Linux. Zudem liefert Dell das Betriebssystem expressis verbis mit dem Versprechen der Entkopplung: OS 10 soll nicht nur auf Geräten von Dell funktionieren, sondern auch auf generi-scher Netzwerkhardware. Anders als proprietäre Switch-Betriebs-systeme bietet OS 10 außerdem offene APIs und macht aus Switches normale Linux-Server, die sich in großen Umge-bungen wie ihre Serverkollegen verwal-ten lassen sollen. Das Linux-Magazin schaut genauer hin: Was verspricht Dell sich von OS 10? Wodurch unterscheidet sich das Betriebssystem von klassischer

Switch-Firmware? Und wie hoch sind Dells Marktchancen?

Marktanalyse

Um zu verstehen, warum ein offenes Switch-Betriebssystem wie OS 10 so viel Aufsehen erregt, hilft ein Blick auf den Markt für Netzwerkinfrastruktur. Der steht nicht gerade im Verdacht, flexibel und schnelllebig zu sein: Über Jahr-zehnte haben ihn sich nur wenige Unter-nehmen untereinander aufgeteilt, allen voran Juniper und Cisco. Meist ist die Entscheidung für die Netz-werkhardware eines Herstellers die Ent-scheidung für eine lange Partnerschaft. Wer sein Rechenzentrum durchgehend mit Hardware eines Herstellers ausgestat-tet hat, kommt von ihr nur schwer wieder weg. Aus mehreren Gründen: Zwar gibt es Standards für praktisch alle gängigen Netzwerkprotokolle und Netzwerktech-nologien, doch trotzdem ist es im Alltag

Dells OS 10 ist ein auf Linux basierendes Betriebssystem für Netzwerkhardware, das Admins aus dem Würge-griff der etablierten Netzwerkhersteller befreien soll. Worum es dabei geht, wie das System funktioniert und was OS 10 alles kann – ein Überblick. Martin Loschwitz

OS 10 und Dells Bemühungen in Sachen Open Networking

Freiheit, die ich meine

Tit

elth

ema

28

ww

w.lin

ux-m

agaz

in.d

eO

S 1

010

/201

6©

Chi

ram

anas

Jut

idha

rabo

ngse

, 123

RF

Vermehrt sind in den letzten Jahren aber auch Anzeichen dafür zu erkennen, dass sich das Monopol der etablierten Herstel-ler langsam auflöst. Maßgeblich dafür ist auch das Thema Cloud Computing und dort insbesondere das Software De-fined Networking: Viel Funktionalität, die früher vornehmlich im Switch – also in echter Netzwerkhardware – implemen-tiert war, ist heute in Software umgesetzt.

Das Monopol brechen

Diese Software muss keinesfalls zwin-gend auf den Netzwerkgeräten etwa des Cloudsetups laufen: In Open Stack-Clouds sind Switches im Normfall zu doofem Eisen degradiert, das nur Pakete zwischen einzelnen Ports empfängt und zustellt. Das ist übrigens nicht Design-bedingt: Denn moderne Switches sind auch nichts anderes als kleine Server mit sehr vielen Netzwerkanschlüssen. Damit das klappt, muss die Firmware des Switch aber modular und offen sein. Ge-nau hier scheitert die Theorie oft an der Praxis: Denn proprietäre Betriebssysteme sind gerade keine offenen Systeme. Mo-difikationen an der Firmware der Geräte können nur in dem Umfang stattfinden, den der Hersteller einräumt.Dass es auch anders geht, zeigt Cumu-lus [2]: Das Betriebssystem für Switches lässt sich auf der Whitelabel-Hardware diverser Anbieter installieren und bie-tet neben einem echten Linux-Kern und einer Distribution auf Basis von Debian auch offene APIs. Die Idee des Netz-werkswitch als einfachem Server wird hier Realität. Mellanox setzt bei seinen Ethernet-Produkten deshalb auf eine Kooperation mit Cumulus: Diverse Mel-lanox-Geräte lassen sich mit installiertem Cumulus bestellen. Weil skalierbare Set-ups stetig an Bedeutung gewinnen, hat der Markt offener Netzwerkinfrastruktur ein riesiges Potenzial.

Dells OS 10 ist ein Cumulus-Konkurrent

Genau hier schließt sich der Kreis zu OS 10: Dell schlägt damit in die gleiche Kerbe und möchte ein Betriebssystem für Swit-ches im Markt etablieren, das sich eben-falls auf der Hardware anderer Hersteller nutzen lässt und offene Schnittstellen

bietet. Letztlich ist OS 10 also Dells ma-nifestierter Anspruch, vom großen Cloud-Netzwerkmarkt ein ordentliches Stück abzubekommen.OS 10 macht es in vielerlei Hinsicht so ähnlich wie Cumulus: Das System be-ruht im Kern auf Linux und folgt den Regeln des SAI – Switch Abstraction In-terface ist ein Standard, den Dell, Mel-lanox, Facebook, Intel und Broadcom im Rahmen der Open-Compute-Initiative gemeinsam erarbeitet haben. In den vergangenen Monaten hat Dells Marketing für OS 10 ordentlich getrom-melt – eingedenk der vielen Gemeinsam-keiten mit Cumulus stellt sich freilich die Frage, was OS 10 tatsächlich kann, was es besser kann als Cumulus und wo noch Verbesserungspotenzial besteht.

Brücke zwischen Hard- und Software

Das Switch Abstraction Interface ist wich-tig, um die Idee hinter freien Betriebs-systemen für Switches zu verstehen. Grundsätzlich stehen die Hersteller von Netzwerkhardware vor der Herausforde-rung, der Software auf Switches irgend-wie Zugriff auf die Netzwerkhardware zu bieten, die in den handelsüblichen Geräten eingebaut ist. Wie bei jeder Netz-werkkarte sind auch in klassischer Netz-werkhardware Netzwerk-Chipsätze ver-

baut: Wenige Hersteller – etwa Mellanox – fertigen ihr Silikon selbst, die meisten Anbieter setzen auf fertige Chips, etwa von Broadcom. Damit ein Betriebssystem Hardware nut-zen kann, redet es typischerweise mit dessen Firmware. Das ist der springende Punkt: Damit Standard-Betriebssysteme wie Linux die Netzwerkhardware eines Switch ansprechen und nutzen können, muss der Hersteller dafür sorgen, dass eben jene Betriebssysteme über eine definierte Schnittstelle Zugriff auf die Firmware des verbauten Chipsatzes be-kommen. Bei klassischer Netzwerkhardware sieht sich der Admin hier einem monolithi-schen Block gegenüber: Direkt auf dem Gerät läuft die Software des Herstellers, die über die proprietäre Firmware des je-weiligen Chipsatzes direkt mit der Hard-ware kommuniziert. Der Nutzer hat auf Art und Umfang der Schnittstellen, die die Switch-Software anbietet, keinen Ein-fluss. Das SAI dagegen setzt bei der Firm-ware des Chipsatzes des Switch an. Wenn die Switch-Firmware ein standardisiertes Interface hat, kann auf dem Switch selbst jede Software laufen – also zum Beispiel auch ein ganz normaler Linux-Kern, der über die SAI-Schicht direkt auf den Chip-satz zugreift.Dell hat bei OS 10 genau diesen Weg eingeschlagen. Zwischen Hardware und

29

ww

w.lin

ux-m

agaz

in.d

e

Tit

elth

ema

OS

10

10/2

016

Abbildung 1: Die NPU (Network Processing Unit) ist Teil der SAI-Schnittstelle und exponiert zur Linux-Seite

hin normale Netzwerkschnittstellen und Netlink-Ereignisse.

© D

ell

auch selbst implementieren. Zugleich bedeutet dieser Ansatz natürlich auch, dass OS 10 nicht nur auf Dell-Switches laufen muss. Jeder Switch, der den SAI-Standard umsetzt, sollte sich mit OS 10 betreiben lassen. Dell stellt im Handbuch zur Open Edition von OS 10 allerdings gleich am Anfang klar, dass die Kombination aktuell nur auf einigen Switches von Dell offiziell unterstützt wird. Ob ein Dell-Switch OS 10 offiziell unterstützt, lässt sich laut Dell am schnellsten über die Produktseite des jeweiligen Geräts auf der Dell-Homepage herausfinden.

Konkret: Debian als Basis

Dell bietet OS 10 in Form mehrerer Mo-dule an, die ineinandergreifen. Die Open Edition umfasst den Kern des Linux-Be-triebssystems: Auf dem Switch läuft die-ses Basismodul (Abbildung 3) und bie-tet ein funktionierendes Standard-Linux. Dell bewirbt OS 10 als unmodifiziertes Debian Jessie, sodass dem Admin auf seinem Switch anschließend Linux 3.16 zur Verfügung steht.Der SSH-Login auf dem Switch führt nach der OS-10-Installation zu einer ganz nor-malen Linux-Shell. Schon dieser Umstand ist für die Nutzer bemerkenswert: Wer die CLIs von Cisco oder Juniper durch-

dringen möchte, hat eine steile Lernkurve vor sich. Ein Linux-basierter Switch mit normaler Shell lässt sich indes auch von normalen Linux-Admins administrieren, weil die ganze gewohnte Umgebung zur Verfügung steht. Der Aufruf von »ip a« macht das deut-lich: Durch die SAI-Abstraktion sieht der Admin auf dem OS-10-Switch sämtliche Ports des Switch als konfigurierbare Netzwerkinterfaces. Von hier aus hangelt er sich nach Belieben weiter. Weil es sich um ein Debian-System handelt, lässt sich zum Beispiel per »apt-get« neue Software installieren. Dadurch eröffnen sich alle Möglichkei-ten, die auch auf einem normalen Linux-Server verfügbar sind. Beispielsweise in Sachen Monitoring: SNMP-Unterstützung lässt sich per »snmpd« wie gewohnt einrichten, auch Traffic-Statistiken pro Port, etwa per RRD, sind so problemlos möglich. Wirklich schlagkräftig wird das reine Linux auf dem Switch allerdings erst, wenn es um typische Netzwerk-funktionalität geht: Mittels BGP wird aus einem Layer-2-Switch problemlos ein Layer-3-Router.

Layer-3-Routing für Cloud-Setups

Diese Art des Setups ist besonders bei Cloudanbietern beliebt. Die Idee: An-stelle von simplem Switching im Layer 2 fungiert der Switch als Router, um Pa-kete auf Layer-3-Ebene zuzustellen. Dazu laufen sowohl auf dem Switch als auch auf allen angeschlossenen Hosts BGP-Daemons, zum Beispiel Quagga oder Bird. Jeder Host ist über zwei Netzwerk-karten an zwei unterschiedliche Switches angebunden und verkündet Routen zu seiner Haupt-IP über jene Links. Diese Lösung bildet Hochverfügbarkeit also nicht über Bonding ab und um-geht dabei Probleme, die beim Bonding etwa dann entstehen, wenn spezifische Off loading-Features (zum Beispiel für VXLan) zum Einsatz kommen. Zudem fungieren die Switches auf diese Weise als Router und es lassen sich auf der Switch-Ebene auch Hosts in unterschied-lichen Netzen problemlos miteinander verbinden. Das ist zum Beispiel in solchen Fällen sehr praktisch, wenn Clouds auf mehrere

der Software, die der Endanwender sieht, liegt eine Abstraktionsschicht auf Basis der SAI-Spezifikation. Diese kommuni-ziert nach unten mit der Hardware und exponiert nach oben standardisierte Schnittstellen, etwa im Beispiel Linux durch das Generieren von Netlink-Events in Richtung Kernel (Abbildung 1), wenn ein neues Gerät angeschlossen wird. Auf dieser Abstraktion läuft ein normaler Linux-Kernel in Version 3.16, der oben-drein eine Schnittstelle für die Switch-Firmware – also das SAI – ins System durchschleift.Auf Basis dieses Setups ist es dem Admin überlassen, wie er die Switch-Konfiguration bewerkstelligt: Er kann die Systemressourcen der laufenden Linux-Instanz entweder wie gewohnt nutzen und zusätzliche Netzwerkdienste ver-wenden, oder er setzt auf Dells Control Plane Service (CPS): Das ist ein objekt-orientiertes Framework, das direkt auf die SAI-Schicht zugreift (Abbildung 2) und einer klassischen Herstellerlösung nahe kommt. Dell selbst wird für CPS verschiedene Module anbieten, die Funktionalitäten wie L2-Netzwerk und L3-Routing enthal-ten, also fertige Lösungen darstellen. Der wichtige Punkt dabei ist: Wer CPS nicht nutzen will, darf auf Basis des Standard-Linux-Systems vergleichbare Funktionen

Tit

elth

ema

30

ww

w.lin

ux-m

agaz

in.d

eO

S 1

010

/201

6

Abbildung 2: Die Architekturübersicht von OS 10 zeigt deutlich, dass SAI der zentrale Dreh- und Angelpunkt

der Plattform ist. Er ermöglicht Linux und CPS.

© D

ell

Standorte verteilt sind und unterschied-liche lokale Netze nutzen: Dank des L3-Routings bedarf es in solchen Konstruk-ten keiner zentralen Router mehr (Abbil-

dung 4). Obendrein fügt sich diese Art des Routings deutlich besser in typische Leaf-Spine-Netzwerkarchitekturen ein, wie sie aus Gründen der Skalierbarkeit in Clouds allgemein üblich sind: Im Falle des Ausfalls eines Routers erneuert sich das gesamte BGP-Setup dann automa-tisch so, dass nur funktionierende Pfade übrig bleiben und defekte automatisch wegfallen.Zwar lässt sich ein solches Setup wahl-weise auch mit der proprietären Firmware diverser Hersteller abbilden, doch dafür werden meist saftige Zusatzgebühren fällig. Diese Kosten wiederum machen die Lösung insgesamt schnell unattraktiv. OS 10 löst diese Aufgabe weitaus besser: Quagga oder Bird lassen sich problemlos installieren und jeweils mit einer eige-nen Konfigurationsdatei betreiben – der

Routing-Teil des Setups ist damit dann schon auf der Switch-Ebene umgesetzt.

Automatisierung problemlos

Ein weiteres großes Problem für moderne Workflows ist die bei klassischer Netz-

werkhardware oft anzutreffende statische Konfiguration. Regelmäßig gibt es bei der Hardware etablierter Hersteller nur ein CLI oder eine vom Anbieter spezifizierte, proprietäre Schnittstelle für das Einspie-len einer neuen Konfiguration. Mit den typischen Devops-Workflows der Ge-

31

ww

w.lin

ux-m

agaz

in.d

e

Tit

elth

ema

OS

10

10/2

016

Abbildung 3: OS 10 ist grundsätzlich modular aufgebaut: Das Grundpaket steht frei zur Verfügung; Erweite-

rungen oder CPS-Module werden separat erhältlich sein.

© D

ell

genwart lassen sich diese allerdings nur schwer in Einklang bringen: Hier gilt eher die Annahme, dass sich jeder Server zu jedem Zeitpunkt automatisiert und aus der Ferne neu- oder umkonfigurieren las-sen muss. Mit einem Standard-Linux wie bei OS 10 ist das hingegen sehr leicht: Egal ob Puppet, Chef oder Ansible – Swit-ches mit OS 10 lassen sich aus den gän-gigen Automatisierungslösungen heraus völlig problemlos bearbeiten. Dell hebt dies in der technischen Be-schreibung des OS-10-Base-Moduls [3] auch explizit hervor. Denkbar sind da-mit sogar Workflows, bei denen der neue Switch nach der Installation im Rack automatisiert installiert wird, ohne dass ein Admin sich überhaupt einloggt oder sonstwie händisch eingreift. Das ist mit althergebrachter Netzwerkhardware kaum zu realisieren. Dell erfüllt an die-ser Stelle sein Versprechen des univer-sellen Switch-Betriebssystems, das sich in Devops-Workflows einfügt, bis zum letzten i-Punkt.

Cloudsoftware läuft auch

Gerade weil Switches Server mit vielen Netzwerkkarten sind, ist es sogar denk-bar, Cloudkomponenten nicht länger auf einzelnen Servern zu betreiben, sondern direkt auf den Switches selbst. Alle gän-gigen Cloudansätze sehen so genannte Netzwerkknoten vor; diese versorgen VMs in der Cloud mit Netz nach außen und kümmern sich um VXLan-Tunne-ling und Pakettrennung. Bisher ist es in

Funktionalität des Switch erhöht. Die ist zwar auch auf Basis des Linux-Systems von OS 10 realisiert, sie hat im Hinter-grund allerdings auch direkten Zugriff auf den SAI-Layer. Dells schöne, dynamische Welt bekommt hier zumindest kleine Risse, denn ver-schiedene wichtige Features der Switch-Hardware lassen sich nur per CPS- Schnittstelle konfigurieren, nicht aber über die Linux-Kommandozeile. Dazu gehören Port-Monitoring auf Hardware-Ebene, QoS oder ACLs. Immerhin: Dell hat eine ausführliche Dokumentation zu CPS und dem zugehörenden API veröf-fentlicht und mit vielen Beispielen ge-spickt. Obendrein existieren Bindings für die wichtigste Skriptsprache Python. Wer eines der CPS-only-Features nutzen will, kann dies über die CPS-Schnittstelle also auch tun, ohne Geld an Dell zu überwei-sen (Abbildung 5).Klar ist, dass dies kaum Dells Absicht gewesen sein dürfte: Denn CPS richtet sich spezifisch an jene Unternehmen, die L2- oder L3-Funktionen wollen, ohne sich um die konkrete Umsetzung auf dem Switch zu kümmern. CPS ist auch Dells Antwort auf die Frage, wie Drittherstel-ler ihre Produkte fit für den Einsatz auf OS-10-Switches machen können – indem sie CPS nutzen und ihre Systemanfragen über das dortige API abwickeln. Die ersten Versionen von OS 10 schneiden im direkten Vergleich mit Konkurrenzpro-dukten wie Cumulus allerdings schlecht ab, weil sie noch nicht alle Features der Konkurrenz unterstützen. Auf Basis von CPS dürfte Dell aber versuchen, diesen Feature-Vorsprung einzuholen.

Was hat Open Networking von OS 10?

Apropos Cumulus: Interessant an der Veröffentlichung von OS 10 ist auch die Tatsache, dass Dell in Form von OS 10 einen direkten Konkurrenten zum Cumu-lus-Betriebssystem für Switche anbietet, ohne die existierende Partnerschaft mit Cumulus aufzukündigen. Schon bisher war es nämlich durchaus möglich, Dell-Switche ohne Dell-OS zu bekommen: Dell liefert eigene Switches auch mit Cu-mulus als Betriebssystem aus. Bis jetzt hat Dell dies stets als Teil seiner Open-Networking-Bemühungen ver-

Cloudumgebungen Usus, diese Aufga-ben wahlweise mit auf den Hosts abzu-wickeln, die die VMs betreiben – oder eigene Netzwerkknoten zu bauen, die keine andere Aufgabe haben. Theoretisch hindert Admins schon jetzt nichts daran, auf einem Switch mit ent-sprechenden Ressourcen – besonders RAM und CPU sind ein Thema – die Netzwerkkomponenten etwa von Open Stack zu installieren und zu betreiben. Durchgesetzt haben sich solche Setups bisher aber noch nicht – wohl auch, weil die gängigen SDN-Lösungen für Clouds wie Open Stack von dem Mehr an Infor-mation auf den Switches kaum sinnvoll Gebrauch machen können. Dank Lösungen wie Cumulus oder OS 10 von Dell ist es aber nur eine Frage der Zeit, bis die SDN-Hersteller generische Switches als Zielplattform identifizieren und entsprechende Funktionalität in ihre Lösungen integrieren. OS 10 ist für Setups dieser Art jedenfalls gewappnet.

CPS für den klassischen Weg

Dell sieht OS 10 freilich nicht nur als Switch-Betriebssystem für Firmen, die maximale Flexibilität bei der Verwaltung ihrer Netzwerkhardware wollen. OS 10 soll stattdessen ein universelles System werden, das die Wahl zwischen Flexibi-lität und Lösungen von der Stange bie-tet. Der Control Plane Service ist Teil dieses Konzepts: Es handelt sich um eine Programmier-Schnittstelle, über die Dell Module nachrüstet und die so die

Tit

elth

ema

32

ww

w.lin

ux-m

agaz

in.d

eO

S 1

010

/201

6

Abbildung 4: Eine Leaf-Spine-Architektur lässt sich auf OS 10 mit Bordmitteln und etwa Quagga realisieren.

© D

ell

marktet: Der Open Networking Foun-dation gehören praktisch alle großen Hersteller von Netzwerkhardware an, darunter eben auch Dell. Gemeinsam ar-beiten sie im Rahmen des ONF an dem Ziel, Software Defined Networking zu standardisieren und dessen Verbreitung zu erhöhen.In einer separaten FAQ zum Thema OS 10 stellt Dell klar, dass das System als Ergänzung und Erweiterung der Dell-ONF-Strategie zu verstehen ist und die bestehende Cumulus-Partnerschaft nicht beeinträchtigt. Trotz des großen Marke-ting-Tamtam Anfang 2016 ist die Anzahl der Switches, die OS 10 unterstützen, noch gering. Wer OS 10 will, kann es bei Dell nicht vorinstalliert kaufen, sondern muss OS 10 auf einem kompatiblen Gerät nachinstallieren. Das OS-10-Angebot von Dell hinkt dem Cumulus-Angebot damit hinterher. Solange Dell diese Probleme nicht beseitigt, wäre es unklug, Cumulus den Laufpass zu geben. Klar ist aber auch, dass das langfristig nicht Dells Anspruch sein kann. Eine Zeit lang wird der Hersteller seinen Kunden wohl die Wahl zwischen OS 10 und Cu-mulus lassen, zumindest so lange, bis eine Feature-Parität gegeben ist. Danach müsste es spannend werden.

Fazit: Das Problem ist das Umparken im Kopf

Dell demonstriert mit OS 10, wohin es in Sachen Netz in einem Devops-geprägten Umfeld geht. Den Netzwerk-Dinosauri-

ern – allen voran Ju-niper und Cisco – ist das ebenfalls längst aufgefallen. Juniper etwa versucht aktu-ell, Junos auch als Betriebssystem für andere Hardware zu etablieren. Ver-glichen mit den Be-mühungen von Dell wirkt das jedoch wie der verzweifelte Ver-such, das Pferd von hinten her aufzu-zäumen. Bei OS 10 geht es nämlich gar nicht so sehr um die Ziel-

plattform, auf der das Betriebssystem am Ende läuft. Viel wichtiger ist seine innere Struktur. Und Dells Ansatz könnte radi-kaler kaum sein: Weg von geschlossenen und proprietären Lösungen – hin zu einer offenen Plattform, die Admins sich mit Standardwerkzeugen so einrichten kön-nen, wie sie sie brauchen.Dieser Ansatz ist so radikal, dass er ge-rade für jene Unternehmen eine mentale Hürde darstellt, die klassisches Netzwer-ken auf Basis eines speziellen Herstellers lange gewohnt sind. Wer sich jahrelang auf Juniper konzentriert oder die Zertifi-kate seiner Cisco-Schulungen stolz über dem Schreibtisch hängen hat, tut sich anfänglich schwer damit, dass ein Switch bloß noch ein normaler Linux-Server ist, der so konfiguriert wird, wie alle anderen Geräte auch. Allzu nahe liegt dann der Denkfehler, dass spezifisches Netzwerkwissen da-durch entwertet würde. Dabei ist tatsäch-lich das Gegenteil der Fall: Die Komplexi-tät von Netzwerksetups wird gerade im Kontext mit Software Defined Networ-king steigen. (jcb) n

Infos

[1] OS10:[http://www.dell.com/learn/us/en/

ph/press-releases/2016-01-20-dell-raises-

the-bar-for-open-networking]

[2] Cumulus:[https://www.cumulusnetworks.com]

[3] OS-10-Base-Modul:

[https://www.force10networks.com/

CSPortal20/Software/documentation/

OS10_openEdition_AdminAndProgram.pdf]

Abbildung 5: Für CPS steht eine Python-Integration bereit, sodass sich aus

Python-Skripten wie hier die MAC-Tabelle des Switch auslesen lässt.