Software-Defined Networking
Ohne Testen geht es nicht
Softwaredefinierte Netze verhalten sich nicht immer intuitiv. Die Komplexität erhöht sich durch Virtualisierung erheblich. Ausführliches Testen ist der einzige zuverlässige Weg, um zu garantieren, dass solche Netzwerkumgebungen entsprechend ihrer Aufgabenstellungen arbeiten.
Mit SDN (Software-Defined Networking) hält eine neue Netzwerkarchitektur Einzug, die für Enterprise- und Carrier-Netze drei wesentliche Vorteile verspricht: nachhaltige Kostenreduktion unter anderem durch Verwendung von Standard-Servern anstelle proprietärer Hardware, schnellere Einführung von Diensten und Services sowie flexiblere Netzwerktopologien unter Verwendung von virtualisierten Netzelementen (NFV - Network Functions Virtualization). Die grundlegende Architektur von SDN ist hinreichend bekannt. Weil diese Technik nun auf dem Weg in die produktiven Netzwerke ist, gilt es, die Praxistauglichkeit der Konzepte zu validieren, um Fehler möglichst vor der Inbetriebnahme identifizieren zu können.
Um die Akzeptanz von offenem SDN zu erhöhen, beschäftigt sich eine Reihe von Organisationen mit der Standardisierung entsprechender Spezifikationen, allen voran die Open Networking Foundation, aber auch ETSI, OPNFV (Open Platform NFV Project) oder Opendaylight, nicht zu vergessen Openstack für die Orchestrierung von virtuellen Umgebungen wie SDN. Die Mission der Non-Profit-Organisationen sind die Kommerzialisierung und die Promotion von SDN sowie des Openflow-Protokolls. Viele dieser Organisationen haben die Bedeutung des Testens der jeweiligen Herstellerimplementierungen erkannt und entsprechende Arbeitsgruppen eingerichtet. So veranstaltet zum Beispiel die ONF (Open Networking Foundation) mehrmals jährlich sogenannte Plugfests, die dazu dienen, die Konformität der Produkte und Anwendungen mit den Spezifikationen sowie die Kompatibilität mit den Lösungen anderer Hersteller zu überprüfen.
Real World Performance
Andere Anbieter wie zum Beispiel Incntre oder Luxoft stellen Konformitätszertifikate aus: Ein Switch wird dazu in einem gut ausgerüsteten Labor einer Reihe von Standardprozeduren unterzogen und erhält - ein positives Verhalten vorausgesetzt - ein entsprechendes Konformitätssiegel. Dies bedeutet aber noch nicht, dass sich das Produkt innerhalb einer umfassenden Implementierung den Anforderungen entsprechend verhält. Bei Konformitätstests kommen nur funktionelle Tests zum Einsatz, das heißt, dass die Simulation zum Beispiel nur wenige Teilnehmer oder Verbindungen einbezieht. Die Datenlast ist dabei gering. Im Betrieb muss das Netzwerk aber wesentlich mehr Teilnehmer oder Verbindungen verarbeiten und damit einhergehend mehr Datenlast transportieren. Es gilt also, eine möglichst realistische Last zu generieren und diese systematisch zu erhöhen, um die Grenzen des Netzwerks auszutesten und die Folgen abschätzen zu können.
Aus Ende-zu-Ende-Sicht lässt sich SDN als Blackbox betrachten. Viele Testmethoden traditioneller Netzwerke (Laufzeit, Jitter, Paketverluste, Durchsatz, Service-Level-Agreements etc.) sind auch dort anwendbar. Fehlverhalten oder Flaschenhälse innerhalb der "Blackbox" lassen sich so aber nur begrenzt oder gar nicht identifizieren. Hinzu kommen neue SDN-Anwendungen, APIs, Protokolle und Herstellerimplementierungen, die das Verhalten des Netzwerks verändern. Auch sie sind im Hinblick auf ihre Performance zu validieren.
Bewährtes PASS-Konzept
Eine bewährte Methode ist das Testen nach dem PASS-Konzept: Performance, Availability, Security und Scale. Mit der Zentralisierung der Control Plane geraten die SDN-Controller zum wichtigen Kristallisationspunkt der Netzwerk-Availability. Sie müssen mit Veränderungen, die Anwendungen und Geräte kommunizieren, selbst bei schnellen Änderungen zurechtkommen.
Wichtig für die Sicherheit ist, dass Hacker nicht in der Lage sein dürfen, Netzwerkkonfigurationen durch den SDN-Controller zu verändern. Das sogenannte Fuzzing Testing muss in der SDN-Welt zu einem wichtigen Element des Security Testings werden, da es potenzielle Angriffsziele aufzeigt. Ebenso schafft die Skalierung neue Herausforderungen in SDN-Netzen. Controller müssen nicht nur große Netzwerke unterstützen, sondern auch eine sehr große Anzahl von simultanen Requests von Netzwerkgeräten und SDN-Anwendungen verarbeiten können.
Die wesentlichen Elemente von Openflow-Lösungen sind ein oder mehrere Controller, ein oder mehrere Switches sowie sichere Kanäle zur Verbindung dieser Elemente. Was letztendlich für das Unternehmen zählt, ist die Performance des kompletten Systems. Openflow Performance Testing unterscheidet sich vom konventionellen Switch Testing dadurch, dass es nicht ausschließlich auf das Packet Forwarding fokussiert ist. Vielmehr muss es neben dem reinen Packet Processing auch überprüfen, wie schnell ein Switch die "Flow-Mod Messages" verarbeiten kann. Der Ausdruck "Flow-Mod" bezieht sich auf Anweisungen, die ein Controller zu einem Switch sendet, um Regeln in der Forwarding-Tabelle des Switches hinzuzufügen, zu verändern oder zu löschen.
Fokus Flow-Mod Messages
Sobald eine Openflow-Regel in der Forwarding-Tabelle des Switches installiert ist, werden die Pakete typischerweise mit Leitungsgeschwindigkeit weitergeleitet, was sich wiederum mit den bekannten Testmethoden überprüfen lässt. Dazu muss das Messgerät aber in der Lage sein, genau den Test-Traffic automatisiert zu erzeugen, der durch die Flow-Mod Messages definiert ist.
Die Anforderungen an die Openflow Performance können zwischen den unterschiedlichen Lösungen stark variieren - etwa im Hinblick auf das Schlüsselkriterium, wie schnell ein Controller neue Flows zu einer Forwarding-Tabelle eines Switches hinzufügen kann. Eine Lösung, die Openflow nutzt, um einen Ethernet-Exchange-Point zu implementieren, könnte möglicherweise mit einigen neuen Flows pro Sekunde auskommen. Demgegenüber benötigt etwa eine Lösung zur Implementierung eines dynamischen IP-Routings vielleicht Hunderte von neuen Flows pro Sekunde.
Aus diesem Grund ist es wichtig, die Zahl von Flow-Mods pro Sekunde zu messen, die der Controller senden und in der Tabelle des Switches installieren kann. Der Flaschenhals liegt dabei gewöhnlich innerhalb des Switches zwischen der CPU und dem ASIC für die Speicherung der Tabelle. Die Performance-Testergebnisse können dort dramatisch variieren - von wenigen Flow-Mods pro Sekunde bis hin zu Hunderten - sogar im selben Switch, etwa vor und nach einem Firmware-Upgrade.
Spirent Communications beispielsweise hat wesentliche Bereiche identifiziert, um die Openflow Performance eines Switches zu messen: Table Capacity Testing, Flow-Mod-Performance, Packet In/Out Performance, Table-Miss Performance, Flow Statistic Testing sowie Pipeline Processing Performance und Failover-Szenarien. Für jeden Test sollte das genutzte Equipment das Verhalten des Openflow-Controllers emulieren und ebenso mit den Data Plane Ports des Switches verbunden sein. Auf diese Weise kann das Test-Equipment Anweisungen zum Switch senden, um zu überprüfen, dass Forwarding-Regeln, die der emulierte Controller einstreut, sauber installiert werden.
Weitere verfügbare Methoden
Bereits heute steht eine Reihe von Testmethoden bereit, und deren Zahl wächst kontinuierlich. Diese ermöglichen das Testen in den kritischen Funktionsbereichen. So ist etwa der "Secure Channel" ein Mechanismus zur Initiierung und Aufrechterhaltung der Kommunikation zwischen Openflow-Controllern und einem oder mehreren Switches. Die reibungslose Funktion des Secure Channels ist wichtig für die erfolgreiche Implementierung eines Openflow-Netzwerks, weil dieser die Konfiguration, die Verwaltung, den Empfang von Events und den Versand von Pakten durch den Controller ermöglicht. Zu testen ist dazu die sichere Channel Connection.
Jeder Openflow-Switch nutzt eine Flow-Tabelle, um die Pakte weiterzuleiten. Um sauber zu arbeiten, muss er in der Lage sein, Flows vom Controller zu akzeptieren, die einkommenden Pakete zu vergleichen, diese gegebenenfalls zu modifizieren und an den jeweiligen Switch-Port weiterzuleiten. Testfokus ist dabei der "Flow Table Push".
Die Flow-Einträge zu einem Openflow-Switch besitzen einen optionalen Timeout, der sich nutzen lässt, um einen Flow zu entfernen, wenn eine gewisse Zeitspanne abgelaufen ist. Wenn ein "harter" Timeout stattfindet, entfernt der Switch den entsprechenden Flow. Demgegenüber kommt ein "Idle"-Timeout zum Einsatz, wenn es nach einer gegebenen Zeitspanne keine Aktivitäten gegeben hat. Beide Timeouts sind wichtig, um den effizienten Betrieb sicherzustellen, indem der Switch jeweils nur über die aktuellen Flows verfügt. Überprüfen lässt sich dies mit dem Flow-Timeout-Test.
Bei Empfang eines "Barrier Requests" muss ein Openflow-Switch die Verarbeitung nachfolgend empfangener Protokollanweisungen aussetzen, bis alle Kommandos, die er vor dem Barrier Request empfangen hat, verarbeitet sind. Ein Openflow-Controller nutzt diese Funktion, um sicherzustellen, dass alle beteiligten Instanzen bedient und alle Anweisungen ausgeführt wurden. Testziel ist dafür die "Barrier Request Message Response".
Failover-Szenarien wiederum simulieren den Ausfall von Controllern oder Switches sowie die Fähigkeit des Netzes, diese zu erkennen und zu kompensieren beziehungsweise die Zeit, die zur Ermittlung nötig ist. Und schließlich ermöglicht der "Flow-Table-Scale"-Test die Prüfung der Fähigkeit des Switches, eine große Zahl von Flow-Einträgen sauber zu hand-haben.
Lesen Sie mehr zum Thema
