Flow-Control-Management

Transkript

1 Flow-Control-Management Philip Wendland Abstract Moderne Netzwerke werden immer schwerer zu verwalten, da jedes Netzwerkgerät manuell und einzeln konfiguriert werden muss. Die wachsende Größe heutiger Netzwerke und die Anzahl der Netzwerkstandards und -funktionen tragen zu dieser Komplexität bei. Es ist praktisch beinahe unmöglich, einen globalen Überblick über die Auslastung und Benutzung eines Netzwerkes zu bekommen, indem man pro Switch bzw. Router paketbasierte Anschauungen nutzt. Aus diesem Grund haben sich flussbasierte Betrachtungsmodelle mit globaler Abdeckung entwickelt. Pakete, die gleiche Quell- und Zieladresse sowie Protokoll und -parameter besitzen, werden hierbei zu einem Fluss (Flow) zusammengefasst. Eine globale Sicht ergibt sich daraus, dass Netzwerkgeräte Informationen zu den Flüssen exportieren. Später entwickelten sich Lösungen, um mit diesem globalem Wissen auch Einfluss auf die Konfiguration der Geräte nehmen zu können. In dieser Arbeit werden aktuelle Flussüberwachungs- und -steuerungssysteme verglichen. 1 Einleitung Das Internet besteht aus Teilnetzwerken unterschiedlicher administrativer Verwaltung, z.b. Provider-, Unternehmens- oder Universitätsnetzwerke. Durch diese hierarchische Unterteilung wird die Komplexität des Internet erst beherrschbar. Aus diesem Grund besitzen Router und Swichtes auch nur ein Teilwissen über die Netzwerkstruktur, um Routing-Entscheidungen zu treffen und Pakete weiterleiten zu können. Dieser Ansatz ist schnell, technisch einfach und gut skalierbar. Nach und nach kamen mehrere unterschiedliche Anforderungen an das Netzwerk auf, wie beispielsweise eine logische Gruppierung. Diese Anforderungen führten zu vielen verschiedenen Standards, zum Beispiel VLAN (Virtual Local Area Network) oder VPN (Virtual Private Network). Die Anzahl der Standards erschwert die Verwaltung und Konfiguration des jeweiligen (Teil-)Netzwerks. Auch die wachsende Größe der Netzwerke trägt dazu bei, da jedes Netzwerkgerät einzeln konfiguriert werden muss. Die Frequenz der benötigten Konfigurationsarbeit hat sich auch erhöht, etwa durch Server-Virtualisierung in Rechenzentren: Man kann mit wenigen Mausklicks in kurzer Zeit viele virtuelle Maschinen aufsetzen, die Konfiguration des darunterliegenden Netzwerkes ist allerdings um ein Vielfaches aufwändiger und damit limitierend. Nicht nur die Konfiguration ist vielen Administratoren ein Dorn im Auge. Es ist auch schwer, die Übersicht über sein Netzwerk zu behalten. Aus diesem Grund haben sich unterschiedliche Lösungen, die bei der Verwaltung der Netzwerke helfen sollen, entwickelt. Diese Lösungen sollen nun verglichen werden. 2 Fluss-Überwachungssysteme 2.1 Motivation Ein Netzwerkadministrator muss den Datenverkehr seines Netzwerks, zum Beispiel in Rechenzentren, überwachen, um überlastete Links, defekte Geräte oder Sicherheitsbedrohungen 1

2 erkennen und lokalisieren zu können. Eine paketweise Betrachtung hat eine unnötig hohe Granularität, weshalb die Anschaulichkeit und Übersichtlichkeit leidet. Pakete mit gleicher Herkunft und mit gleichem Ziel werden deshalb zu einem Fluss (Flow) zusammengefasst, wenn das verwendete Protokoll und die Protokollparameter identisch sind. Moderne Router und Switches besitzen dann die Möglichkeit, diese Flüsse zu überwachen und zu analysieren. Eine manuelle Überwachung jedes einzelnen Gerätes ist aufgrund der Größe des Netzwerkes und der Anzahl der Geräte meist zu aufwendig und umständlich. Aus diesem Grund sind Fluss- Überwachungssysteme entstanden. Informationen zu den Flüssen werden von den Routern und Switches an eine zentrale Sammelstelle (Kollektor) geleitet und können dann zentralisiert ausgewertet werden. 2.2 sflow Architektur In sflow-kompatiblen Switches bzw. Routern ist ein sogenannter sflow-agent integriert. In manchen Fällen ist es sinnvoll, den Agent in verschiedene Sub-Agenten aufzuteilen, zum Beispiel bei einer verteilten Hardware-Struktur. Ein Sub-Agent ist dann für einen bestimmten Teil der Datenquellen verantwortlich. Pro Datenquelle, in der Regel Interfaces, des Geräts gibt es eine oder mehrere sflow-instanzen, welche für die Überwachung der Datenquelle zuständig ist. Die in der sflow-instanz angefallenen Daten werden noch im Gerät vom sflow-agent gesammelt, bevor sie an den sflow-kollektor weitergeleitet werden [PhLa04]. Abbildung 1 gibt einen Überblick über diesen Zusammenhang. Figure 1: Überblick über die sflow-architektur 2

3 2.2.2 Datenaustausch Der Kollektor empfängt von den Agenten die sflow-datagramme und analysiert diese. Ein sflow-datagramm wird mittels UDP (Standard-Port 6343) gesendet und enthält sogenannte Counter-Samples und Flow-Samples. Diese Samples sind Teil eines integrierten Systems. Ein Flow-Sample ist hierbei ein von einer Instanz zufällig ausgewähltes Paket. Es ist bei der Entnahme nicht entscheidend, welchem Fluss das Paket angehört. Die Sample-Rate gibt an, wie viele Pakete entnommen werden sollen. Eine Sample-Rate von beispielsweise 512 spezifiziert, dass im Mittel jedes 512. Paket ausgewählt wird [PhLa04]. Neben Informationen aus dem Paket selbst werden auch zusätzliche Daten dazu entnommen, beispielsweise der Status der Routing/Forwarding-Tabelle [sflo03]. Counter-Samples werden von den Agenten in bestimmten Intervallen oder opportunistisch, um Datagramme zu füllen, gesendet. Sie beinhalten Paketzähler, die einer Datenquelle zugeordnet sind. Das Intervall kann konfiguriert werden [PhLa04]. Counter-Samples beinhalten generische Interface-Informationen wie Status, Geschwindigkeit, Richtung, Anzahl an Fehlern und verworfenen Paketen und Anzahl der Multicast- und Unicast-Pakete. Es sind auch Technologie-spezifische Counter verfügbar, zum Beispiel für Ethernet: Kollisionen oder Carrier-Sense-Fehler, oder für Token-Ring: Token-Fehler, Signalverlust. Prozessorinformationen wie Auslastung oder freier Speicher werden auch gesendet [sflo]. Der Kollektor kann die Agenten mit SNMP ferngesteuert konfigurieren [PhLa04] Gewonnene Informationen sflow bietet eine Sicht auf das komplette Netzwerk, sofern jedes Netzwerkgerät sflow-fähig ist. Da es sich nur um eine reine Traffic-Monitoring-Lösung handelt, erleichtert sflow zwar den Prozess der Informationsgewinnung über ein Netzwerk, aber nicht die Konfiguration der Geräte an sich. Weil mit den Flow-Samples komplette Pakete an den Kollektor geleitet werden und dort ausgewertet werden, können detaillierte Informationen über die Paketflüsse gewonnen werden: Der komplette Paket-Header kann ausgewertet werden, so wie Layer-2- bis Layer-7-Informationen. Durch die zusätzlichen Routing-/Forwarding-Informationen kann der Weg des Flusses durch das Netzwerk verfolgt werden [sflo03]. Selbst Teile des Payloads des Pakets sind einsehbar Sampling Durch Anpassungen der Sample-Rate skaliert sflow gut mit der Größe des Netzwerks und der Geschwindigkeit der Links. So können Links mit 100 Gbps und über 1000 Geräte mit nur einem Kollektor überwacht werden [sflo03]. Sicherlich leidet dabei aber die Auflösung, da die Sample-Rate dann ziemlich hoch gewählt werden muss. Für bestimmte Anwendungen, zum Beispiel Sicherheitsanalysen, ist der Sampling-Modus problematisch. Dem Kollektor liegen die Daten zeitnah vor, sodass Echtzeit-Analysen denkbar sind. Allerdings sind durch das Samplen genaue Aussagen erst nach einer Weile möglich. Bei der Wahl der Sample-Rate muss ein Kompromiss eingegangen werden: Ist sie zu hoch gewählt (wenig Samples), ist die Auflösung unter Umständen zu niedrig, das heißt es werden beispielsweise Flüsse unterschlagen. Ist sie zu niedrig (viele Samples) kann es zur Beeinflussung durch den sflow-traffic selbst (Überlastung von Links) oder zur Überlastung des Kollektors führen. Das Problem der niedrigen Auflösung bzw. Unterschlagung von Informationen besteht bei statistischem Sampling prinzipiell. Der Vorteil dieser Methode ist hingegen, dass viele Informationen pro Fluss, eventuell auch durch Payload-Inspektionen, ausgewertet werden können. Um die Wahl der Sample-Rate zu vereinfachen, gibt es folgenden Trick: Man hält den Anfangswert niedrig, zum Beispiel 128. Im Mittel wird also nun jedes 128. Paket 3

4 als Probe entnommen. Werden dann pro Sekunde zu viele Samples gesendet, verdoppelt der Agent automatisch die Sample-Rate (256). Die Sample-Rate wird nicht wieder verringert [PhLa04]. Dieses Verfahren wird one-way backoff genannt. Die auf diese Weise ermittelte Sample-Rate ist gut auf das Netzwerk abgestimmt - auch für Situationen mit Spitzenlast. Die Genauigkeit sollte sich trotz statistischem Sampling mit fortlaufender Analyse-Zeit einem guten Wert annähern, statistische Anomalien können aber nicht prinzipiell ausgeschlossen werden Sicherheit Eine Verschlüsselung der sflow-datagramme ist nicht vorgesehen. Die Informationen werden unverschlüsselt von den Agenten zu dem/den Kollektor(en) gesendet und können daher abgefangen werden. Dem Kollektor steht auch keine Möglichkeit zur Verfügung, die Authentizität der sflow-agenten sicher zu überprüfen. Auffällig können aber falsche Sequenznummern oder Quelladressen sein [PhPM01]. Der Kollektor ist deshalb je nach Implementierung anfällig für Spoofing (Identitätsverschleierung). Durch das Paket-Sampling ist es fast ausgeschlossen, dass ein Angreifer eine fortlaufende Sequenz von Paketen eines Flusses bekommt. Der Kollektor sollte trotzdem vor Zugriffen geschützt sein, da man eventuell Rückschlüsse durch Analyse von Traffic-Mustern ziehen kann. Eventuell ist es sinnvoll, ein separates geschütztes Netzwerk für sflow-datagramme einzurichten, etwa ein VPN (Virutal Private Network). [PhLa04] Typische Anwendungen Typische Anwendungen von sflow sind etwa das Auffinden von Problemen und ausgelasteten Links im Netzwerk, Sicherheitsanalysen, Verfolgen und Optimieren des Routings einzelner Flüsse, oder eine Kostenabrechnung nach spezifischen Parametern (zum Beispiel Tageszeit, Art des Traffics) im ISP-Bereich Berechnungsaufwand sflow ist in der Hinsicht effizient, dass für die Router und Switches kaum Berechnungs- Overhead anfällt, denn Flow-Samples müssen nur an den Kollektor weitergeleitet werden. Die eher aufwendige Auswertung der Samples findet dann dort statt. Auch die Erfordernisse für die Counter-Samples sind nicht mit hohem Berechnungsaufwand verbunden. Auf diese Weise ist eine Analyse mit annähernd wire-speed möglich, das zusätzliche Datenaufkommen ist aber nicht zu vernachlässigen Transportprotokoll Die sflow-datagramme werden mit UDP (User Datagram Protocol) gesendet. Dadurch verspricht man sich deutliche Performance-Vorteile gegenüber TCP (Transport Control Protocol), weil eine Paketsortierung und -pufferung nicht notwendig ist, genauso wie Algorithmen zur Reaktion auf Paketverluste. Der Verlust eines sflow-datagramms hat geringe Auswirkungen auf die Aussagefähigkeit: Der Verlust von Flow-Samples ist im technischen Sinne nur eine geringe Erhöhung der effektiven Sample-Rate (Verringerung der Auflösung), neue Counter- Samples werden beim nächsten Intervall gesendet [Jasi01]. 4

5 2.2.9 Offenheit und Verbreitung sflow ist ein Industriestandard, spezifiziert von einem Industriekonsortium (Mitglieder sind unter anderem HP, Hitachi). Die Spezifikation ist einsehbar auf Die Version 5 ersetzt Version 4 (RFC 3176). Hauptsächlich geändert wurden das Format des MIB (Management Information Base) und sflow-datagramms [PhLa04] [PhPM01]. Die hohe Verbreitung macht den Einsatz unter Umständen kostengünstig, da viele Netzwerkgeräte bereits sflow-unterstützung bieten sollten. Es gibt eine Vielzahl von Anbietern für Kollektor- Software (unter anderen Alcatel-Lucent, Hewlett-Packard oder InMon Corp.) und sflowkompatiblen Switches (zum Beispiel Cisco, D-Link und IBM). Für eine vollständige und aktuelle Anbieter-Liste siehe und sflow.org/products/network.php. 2.3 NetFlow Architektur Das grundlegende Architekturprinzip von NetFlow ist ähnlich dem von sflow: NetFlow- Prozesse in Routern bzw. Switches exportieren Informationen über Paketflüsse an einen Kollektor, wo sie anschließend analysiert werden Datenaustausch Der größte Unterschied zu sflow besteht darin, was und wann es gesendet wird. Die Netzwerkgeräte erstellen sogenannte Flow-Records (Fluss-Berichte). Diese Flow-Records beinhalten in Version 5 das Interface, auf dem das Paket/der Fluss angekommen ist, TOS (Type-of-Service, ein Feld im IP-Header), das verwendete Protokoll, und Quell- und Ziel-IP-Adresse und -Port und Paketzähler [Cisc03]. Ein Flow-Record wird exportiert, wenn ein Fluss beendet wird. Ein Fluss wird als beendet klassifiziert, wenn er seit 15 Sekunden (Standardwert) inaktiv ist oder bei TCP-Verbindungen ein RST/FIN-Flag gesetzt wurde, also die TCP-Session beendet wurde. Zusätzlich werden Flow-Records erstellt, wenn ein Fluss seit 30 Minuten (Standardwert) aktiv war. Um diese Beobachtungen machen zu können, werden Informationen zu den Flüssen im Netzwerkgerät zwischengespeichert. Ein Flow-Record kann auch dann exportiert werden, wenn dieser Cache voll ist. Auf diese Weise wird ein Überlaufen des Caches vermieden. Seit Version 8 können Flow-Records aggregiert exportiert werden, was zu einer Reduzierung des Export-Traffics führen soll [Cisc04b] [Clai04]. Die Größe der von dem Netzwerkgeräten gesendeten Export-Pakete beträgt etwa 1500 Byte. Diese Pakete beinhalten circa 20 bis 50 Flow-Records. Die Frequenz der gesendeten Export-Pakete erhöht sich mit dem Traffic, der durch das jeweilige Netzwerkgerät fließt [Cisc04a]. Die Kommunikation findet wie bei sflow über UDP (Standardport 2055) statt [Clai04]. Da sich bisher bei jeder neuen Version das Exportformat geändert hatte und dies für die Partner bei der Umstellung hohen Aufwand bedeutete, entschloss sich Cisco, in Version 9 auf ein Template-basiertes Verfahren [Cisc04b] umzustellen. Dies ermöglicht es beispielsweise, Datenfelder hinzuzufügen, ohne dass die Struktur der Flow-Records geändert werden muss und somit Software umgeschrieben und/oder neu kompiliert werden muss. Der Kollektor empfängt sogenannte Template-Records. Diese beinhalten FlowSet ID, Template ID, Feld- Anzahl, Name und Länge der Felder. Diese Template-Records beschreiben die Struktur und Interpretation der Data-Flow-Sets, die die Data-Records beinhalten. Die Data-Records können dann mit dieser Information dekodiert und interpretiert werden [Cisc04b] [Clai04]. Abbildung 2 gibt einen Überblick über diesen Zusammenhang. 5

6 Figure 2: Überblick über den Zusammenhang zwischen Template- und Data-Records Den schon beschriebenen Vorteilen durch den Template-basierten Export steht eine leichte Erhöhung der benötigten Bandbreite gegenüber. Durch die Einführung der Templates ist es prinzipiell einfacher und schneller möglich, auf eventuell aktualisierte Versionen von NetFlow umzusteigen. Es liegt aber auch an den Herstellern der NetFlow-fähigen Netzwerkgeräte, diese Vorteile zu nutzen oder überhaupt Updates anzubieten Gewonnene Informationen NetFlow klassifiziert Flüsse nach IP-Adressen, verwendetem Protokoll und Ports und einigen weiteren Faktoren [Cisc03]. Informationen zu den Flüssen werden an den Kollektor gesendet. Da der Payload der Pakete nicht an den Kollektor weitergeleitet wird, ist es nicht möglich, Anwendungen mittels Deep-Packet-Inspection zu klassifizieren. Cisco stellt hierfür eine separate Lösung namens NBAR (Network-based Application Recognition) zu Verfügung. In Version 9 wurde IPv6- (Internet Protocol Version 6), MPLS- (Multi Protocol Label Switching), BGP- (Border Gateway Protocol, Export von Next-Hop-Informationen) und Multicast- Unterstützung eingeführt. IPv6-Unterstützung ist allerdings nicht zwingend durch Version 9 vorgeschrieben. NetFlow hat eine hohe Genauigkeit, vor allem wenn kein Sampling eingesetzt wird Sampling Ursprünglich war NetFlow ohne Sampling-Mechanismus entworfen, das heißt jedes Paket wird verarbeitet. Dies ist in manchen Anwendungsbereichen, zum Beispiel bei Internet-Backbones zu aufwendig, da diese eine große Anzahl an unterschiedlichen Flüssen passieren und eine paketweise Bearbeitung bei der großen Anzahl an Paketen nicht skaliert. In Version 5 kann deshalb im Header-Feld des NetFlow-Datagramms eine Sample-Rate für das Gerät bekanntgegeben werden (SAMPLING INTERVAL in Feld-Typ-Definitionen) [Cisc]. In Version 9 können pro Interface unterschiedliche Sample-Raten gesetzt werden (in einem options data record) [Cisc11]. 6

7 2.3.5 Sicherheit Da die Informationen unverschlüsselt übertragen werden, können diese mitgelesen werden. Deshalb ist es möglicherweise nützlich, diese über ein privates Netzwerk zu übertragen. Der Kollektor ist zusätzlich anfällig für DoS-Attacken (Denial of Service) [Clai04]. Aus Geschwindigkeitsgründen gibt hat man sich entschieden, Vertraulichkeit, Integrität oder Authentifizierung nicht zu ermöglichen [Clai04] Typische Anwendungen Eine typische Anwendung von NetFlow ist die Unterstützung bei Traffic-Engineering durch Bestimmung der Auslastung des Netzwerks oder Teile davon. Auch die Kapazitätsplanung kann durch NetFlow unterstützt werden. Das Routing der Pakete und der Anteil des Peering- Traffics kann eingesehen werden. Abrechnungen je nach Auslastungen sind möglich [Cisc03]. NetFlow hilft auch bei Sicherheitsanalysen oder bei der frühzeitigen Erkennung eines Angriffs, zum Beispiel durch DoS-Attacken (Denial of Service) [Cisc04a] Berechnungsaufwand Ein relativ hoher Aufwand ergibt sich aus der Tatsache, dass die Netzwerkgeräte Informationen und Status der Flüsse speichern müssen, da erst später entschieden wird, wann ein Fluss-Bericht exportiert wird. Nach dem Exportieren werden die Daten meistens aus dem Cache genommen, um Speicherplatz zu sparen Transportprotokoll Da für den Export das UDP-Protokoll verwendet wird, ergibt sich daraus ein mögliches Problem: Geht durch Überlastung des Kollektors oder Netzwerkes eine Export-Paket verloren, kann dieses nicht wiederhergestellt werden. Eine Kommunikation über WAN-Strecken (Wide Area Network) verschlimmert diese Problematik. Erstens merkt der Kollektor unter Umständen gar nicht, dass ein Paket verloren gegangen ist. Zweitens wäre ein erneutes Senden gar nicht mehr möglich, da der Switch die dazu benötigten zwischengespeicherten Daten wahrscheinlich bereits gelöscht hat. Der Verlust kann bedeutenden Einfluss auf die Aussagefähigkeit der gewonnenen Daten haben, da ein Export-Paket Informationen von 20 bis 50 Flüssen beinhaltet. Diese Flüsse gehen in der Statistik komplett unter, da zu diesen in der Regel erst Informationen exportiert werden, wenn sie beendet sind. Eine Aggregation der Flüsse verschlimmert diese Problematik zusätzlich. Es ist deshalb unter Umständen sinnvoll, sich Gedanken über die Anbindung und Rechenkapazität des Kollektors zu machen. Eventuell ist sogar ein dedizierter Link zweckmäßig. Manche Geräte unterstützen den Einsatz von SCTP (Stream Transmission Protocol), welches aber Geschwindigkeitseinbußen bei vielen Switches/Routern nach sich zieht. TCP hätte zu große Geschwindigkeitsnachteile und wäre damit völlig ungeeignet Offenheit und Verbreitung NetFlow wurde ursprünglich von Cisco entwickelt. Version 5 ist noch weit verbreitet. Version 9 wurde von Cisco in einem Request for Comments (Informational) (RFC 3954) offengelegt, stellt aber keinen Internet-Standard dar. NetFlow in der Version 9 wurde als Basis für IPFIX (Internet Protocol Flow Information export) von der IETF (Internet Engineering Taskforce) gewählt. Es gibt einige Anbieter unterschiedlicher Kollektor-Software. NetFlow wird von 7

8 fast allen Cisco-Routern und Switches unterstützt. Einige andere Anbieter von Routern und Switches bieten aber keine Unterstützung an, vermutlich weil eine Implementierung relativ teuer und aufwändig ist Flexible NetFlow Flexible NetFlow (flexibles NetFlow) ist eine Weiterentwicklung von Cisco. Nutzer können nun selbst spezifizieren, welche Informationen zur Klassifikation und zum Export betrachtet werden sollen [Cisc08a]. Dadurch werden weniger Flow-Records erzeugt. Es können auch Teile des Pakets exportiert werden [Cisc08a], dadurch ist eine Klassifikation mittel Deep-Packet- Inspection möglich. Dies kann zusammen mit anderen benutzerdefinierten Daten dabei helfen, Anomalien und Sicherheitsrisiken zu identifizieren. Als Export-Format wird NetFlow Version 9 verwendet [Cisc08b], da dieses bereits Template-basierten Export ermöglicht. Soll dieses Feature genutzt werden, muss also darauf geachtet werden, dass Switches, Router und die Kollektor-Software neben der Unterstützung von Version 9 dafür geeignet sind. 2.4 Tabellarischer Vergleich der Flussüberwachungslösungen Eigenschaft sflow netflow Sicherheit Verbindung zu Kollektor unverschlüsselt; Kollektor anfällig für Angriffe Verbindung zu Kollektor unverschlüsselt; Kollektor anfällig für Angriffe Skalierbarkeit Anzahl sflow-export-pakete Sampling möglich; höherer direkt proportional zu Paketanzahl Berechnungsaufwand für durch Router; An- Switches als bei sflow passbarkeit der Sample- Rate Genauigkeit Beeinträchtigung durch Sampling Verfügbare Daten Detaillierte Informationen, allerdings nur jedes X. Paketes Implementierungsaufwand gering, da keine Zusatz- Hardware nötig Beeinträchtigung bei Sampling; steigende Last der Geräte In frühen Versionen kaum Unterstützung von höheren Layern, ab Flexible NetFlow und mit NBAR viele mögliche Daten hoch, Caches und Zusatz- Hardware nötig Kollektor-Verfügbarkeit sehr große Auswahl große Auswahl Hardware- sehr viele Hersteller einige Hersteller Unterstützung Offenheit Industrie-Standard, offengelegt Deep Packet Inspection Teile des Payloads jedes X. Paketes einsehbar Anpassbarkeit an Anforderungen kaum Entwicklung von Cisco; Version 9 offengelegt mit NBAR ab Flexible NetFlow Table 1: Vergleich der Flussüberwachungslösungen 8

9 3 Fluss-Steuerungssysteme 3.1 Motivation Der Grund für das Aufkommen von Fluss-Steuerungssystemen ist unter anderem die Komplexität heutiger Switches. Viele Funktionen sind in diese integriert, zum Beispiel OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), Multicast, NAT (Network Adress Translation), Firewalls oder MPLS (Multi-Protocol Label Switching). Diese Funktionen benötigen zusätzliche Rechenleistung - das führt zu teurem Hardware-Aufwand und hohem Stromverbrauch [McKe09]. Zusätzlich erhöht sich der Konfigurations- und Managementaufwand, etwa durch vermehrten Server-zu-Server-Traffic (east-west-traffic) in Rechenzentren, der zum Beispiel durch Migration von virtuellen Maschinen oder durch Backups entsteht. In einem Netzwerk sind normalerweise viele Switches vorhanden, die alle ihre eigene Konfiguration besitzen - Jeder Switch muss vom Administrator über eine Kommandozeilenschnittstelle oder mit SNMP (Simple Network Management Protocol) einzeln konfiguriert werden. Aufkommende Entwicklungen wie Server-Virtualisierung machen ständig eine erneute Konfiguration des Netzwerks nötig. Dieser Aufwand lässt sich zunehmend schwieriger bewältigen. Um diese Komplexität zu verringern, ist eine zentrale Konfiguration des Netzwerks erstrebenswert. An dieser zentralen Stelle ist sogar eine dynamische beziehungsweise automatische Konfiguration möglich. Auf diese Weise kann auch schnell auf dynamisch auftretende Ereignisse reagiert werden. Anwendungen, die mit einer API an der Kontrollschicht ansetzen, können innovationsfördernd wirken. Bisher wurden Netzwerkfunktionen einzeln realisiert, was zum Aufkommen neuer Standards führte, welche von den Herstellern erst implementiert werden mussten. Je nach Update-Politik der Hersteller war das ärgerlich für den Kunden, da eine Unterstützung des neuen Standards häufig zu erneuten Hardware-Investitionen führte oder man lange auf Updates warten musste. Die Realisierung der Funktionen an einer einheitlichen API in Software kann die Vorlaufzeit und den Innovationsaufwand stark verringern. Ein Weg zum programmierbaren Netzwerk ist Softwaredefined-Networking (SDN). Erste Konzepte hierzu kamen erstmals 2005 von der Universität Stanford auf. Mit SDN ergeben sich viele neue Möglichkeiten, zum Beispiel automatische Isolation von BYOD-Geräten in Firmennetzwerken. Google erzielt durch vorsichtiges Routing mittels OpenFlow beispielsweise eine WAN-Link-Auslastung von annähernd 100% [Dix13, S. 6f.]. 3.2 Implementierungsvarianten von SDN-Konzepten Viele unterschiedliche Auffassungen von Software-defined-Networking (SDN) und Möglichkeiten, diese Konzepte zu implementieren, machen eine einheitliche Definition nicht leicht. Der ursprüngliche SDN-Begriff wurde durch OpenFlow geprägt und bezeichnet (nach der Open Networking Foundation) ein System, das die Control Plane strikt von der Data Plane trennt und damit ein Agent/Controller-Modell mit einem logisch zentralem, aber möglicherweise physisch verteilten Controller vorschreibt [Foun]. Oftmals wird SDN auch fälschlicherweise mit OpenFlow gleichgesetzt. Cisco geht mit dem Open Network Environment (ONE) einen anderen Weg: Der SDN-Begriff wird hier weiter aufgefasst, sodass Control-Plane- Aspekte teilweise auch auf Netzwerkgeräten selbst ablaufen können. Mit ONE ist auch eine gänzlich andere Möglichkeit geboten, nämlich die direkte Nutzung von APIs der Netzwerkgeräte. Die Abstraktionsschicht ergibt sich sowohl bei OpenFlow, also auch bei ONE aus der logisch zentralen und eventuell automatisierten Konfiguration von Netzwerkgeräten. Bei WMware NSX ergibt sich die Abstraktionsschicht im Gegensatz durch ein komplett virtualisiertes Netzwerk, das prinzipiell unabhängig von der zugrundeliegenden Netzwerkhardware ist. Einzig IP-Konnektivität wird dabei vorausgesetzt. Abbildung 3 veranschaulicht das grafisch. 9

10 Figure 3: Implementierungsvarianten von SDN-Konzepten 3.3 OpenFlow Architektur Das Design von OpenFlow sieht drei Ebenen vor: Die Infrastruktur-, die Kontroll- und die Anwendungsschicht. Die Infrastruktur besteht aus den Netzwerkgeräten. Diese kommunizieren mit dem Controller (Kontroll-Schicht) über das OpenFlow-Protokoll und umgekehrt. In der Anwendungsschicht laufen benutzerspezifische Anwendungen, die über eine API auf die von der Kontrollschicht bereitgestellten Funktionen zugreifen können [KLCK + 13]. Abbildung 4 veranschaulicht das. Figure 4: Überblick über OpenFlow Das OpenFlow-Protokoll beruht darauf, interne Flow-Tabellen von Routern und Switches zu manipulieren [MABP + 08]. Die meisten Router/Switches besitzen solche Flow-Tabellen. Durch diese Tabellen wird z.b Routing, Firewalls, NAT, QoS usw. mit line-rate Geschwindigkeit verwirklicht. Die Flow-Tabelle wird in der Regel mit TCAM (Ternary Contentaddressable Memory) realisiert. Durch den don t-care-zustand im TCAM kann die Adresse zusammen mit der Subnetzmaske gespeichert werden und effizient adressiert werden, um beispielsweise einen Routing-Eintrag auszulesen. Der don t-care-zustand verhindert, dass die 10

11 Subnetzmaske separat gespeichert und nach dem Auslesen der IP-Adresse darauf gematcht werden muss, was einer schnelleren Ausführung dient. Die internen Flow-Tabellen variieren natürlich von Hersteller zu Hersteller. Man hat aber eine gemeinsame Menge an Funktionen herausfinden können, die man ausnutzen kann [MABP + 08]. Ein OpenFlow-Switch besteht mindestens aus einer Flow-Tabelle, einem sicheren Kanal zum Controller und dem OpenFlow- Protokoll. Man muss zwischen dedizierten OpenFlow-Switches, die normale Layer-2 und Layer-3-Bearbeitung gar nicht mehr beherrschen, und bestehenden kommerziellen Switches, die um eine OpenFlow-Funktionalität erweitert wurden, unterscheiden [MABP + 08]. Bei letzteren werden in der Regel bestehende TCAMs für die OpenFlow-Tabellen verwendet, der Kanal und das Protokoll im Betriebssystem implementiert. Es ist auch eine Bearbeitungspipeline aus mehreren hintereinander geschalteten OpenFlow-Tabellen möglich. Eine OpenFlow-Flow-Tabelle besteht aus: Match Fields, Priorität, Zähler, Instruktionen, Timeouts und Cookies (Abbildung 5) [NPLH + 13, S. 15ff.]. Figure 5: Hauptkomponenten eines Flow-Eintrages Das Match Field ist dazu da, um Pakete einem Fluss, also einem Eintrag in der Flow-Tabelle zuzuordnen. Das Match Field besteht aus dem Interface, auf dem das Paket angekommen ist, dem Paket-Header und Metadaten, die dazu verwendet werden können um Informationen zwischen den einzelnen Flow-Tabellen durchzugeben [NPLH + 13, S. 15ff.][MABP + 08]. Eine Zuordnung erfolgt bei passendem Match Field bei dem Eintrag mit höchster Priorität. Da keine beliebigen Wildcards (z.b. 192.*6*.**1) in den Match-Feldern vorgesehen sind, werden die Möglichkeiten der Klassifizierung der Flüsse anhand spezieller Subnetze eingeschränkt. Ist ein passender Eintrag gefunden, wird der entsprechende Zähler erhöht und die hinterlegte Instruktion ausgeführt. Diese kann im Falle einer mehrstufigen Bearbeitungspipeline das Paket an eine weitere Flow-Tabelle weiterleiten oder eine folgenden, immer unterstützten Aktionen veranlassen: Weiterleiten des Pakets im Netzwerk, Verpacken und Weiterleiten an den Controller, oder Verwerfen (zum Beispiel aus Sicherheitsgründen). Beim Weiterleiten an den Controller wird das Paket oder Teile davon in eine OFPT PACKET IN-Nachricht verpackt, und zusätzliche Informationen wie beispielsweise der Grund des Weiterleitens, die ID der Tabelle beim Lookup, der Cookie des Flusses und andere Metadaten mitgesendet. Optional sind zusätzliche Aktionen möglich, sofern sie unterstützt werden: Z.B. Hinzufügen oder Entfernen von VLAN- oder MPLS-Headern oder das Verändern des TTL-Felds (Timeto-live) zu Routing-Zwecken [NPLH + 13, S. 22ff.]. Wird kein Paket für eine gewisse Zeit einem Fluss zugeordnet, kann der Fluss-Eintrag verworfen werden - je nach gesetztem Timeout. Das Cookie ist ein Wert, der vom Controller verwendet wird, um zum Beispiel Statistiken zu Flüssen zu filtern [NPLH + 13, S. 15ff.]. Durch die Verwendung der Flow-Tabellen in Switches verspricht man sich hohe Geschwindigkeiten bei der Bearbeitung der Pakete und geringe Implementationskosten für die Hersteller der Geräte [MABP + 08]. Die Verbindung zwischen Controller und Switch wird meistens mit TLS (Transport Layer Security) verschlüsselt. Über diese Verbindung konfiguriert der Controller die Switches und wird über deren Zustand und Ereignisse im Netzwerk informiert [NPLH + 13, S. 26]. Der Kanal garantiert, dass keine Nachrichten verloren gehen. Die Reihenfolge ist aber nicht garantiert, das heißt, dass beispielsweise Flow-Einträge in einer anderen Reihenfolge modifiziert werden als in der von Controller gesendeten Reihenfolge [NPLH + 13, S. 29]. Die Folgen eines Controller-Ausfalls können immens sein, wenn kein Rückfall auf einen Betrieb ohne Controller möglich ist. Dies ist besonders der Fall, wenn dedizierte OpenFlow-Switches eingesetzt werden, da diese selbst manche Funktionen der Vermittlungs- und Sicherungsschicht nicht selbstständig beherrschen. Sind alle Netzwerkgeräte im Stande, Pakete auch ohne Controller weiterleiten zu können, ist eventuell eine zusätzliche vorherige Konfiguration bestimmter Funktionen notwendig. Durch 11

12 den Einsatz von mehreren Controllern (Redundanz) kann die Wahrscheinlichkeit eines Totalausfalls verringert werden. Dadurch werden allerdings der Konfigurationsaufwand und die Komplexität des Systems erhöht. Die zentrale Konfiguration der Geräte macht es wahrscheinlicher, dass Konfigurationsfehler vermieden werden. Wird jedes Gerät einzeln konfiguriert, sind menschliche Fehler vermutlich eher möglich. Hieraus und aus einheitlichen Sicherheitspolitiken ergeben sich auch Sicherheitsvorteile Verhaltensmodelle und Skalierbarkeit Um eine bessere Geschwindigkeit, Skalierbarkeit oder Ausfallsicherheit gewährleisten zu können, ist es möglich, mehrere Controller einzusetzen. Ein Switch kann von mehreren Controllern bedient werden. Das Hand-Over wird von den Controllern selbst geregelt, wodurch zum Beispiel Last-Balancierung zwischen verschiedenen Controllern möglich ist [NPLH + 13, S. 31ff.]. Ein Controller kann seit Version Änderungen an der Flow-Tabelle überwachen, die von anderen Controllern vorgenommen wurden [NPLH + 13, S. 202]. Außerdem gibt es Lösungen, die das Netzwerk in Bereiche unterteilt und diese unterschiedlichen Controllern zuteilt, z.b. FlowVisor. Der Controller fügt der Flow-Tabelle Klassifikationsregeln für Flüsse zusammen mit der zugehörigen Aktion hinzu oder löscht diese (etwa zu Experimentierzwecken). Dieser Controller kann beispielsweise eine Applikation auf einem herkömmlichen x86-rechner sein. Es sind unterschiedliche Verhaltensmodelle möglich. Man kann zum Beispiel alle Pakete zu dem Controller weiterleiten lassen und dort bearbeiten. Auch das Weiterleiten nur von bisher nicht klassifizierten Paketen, d.h. Pakete, für die noch kein anderer Flow-Eintrag vorhanden ist, ist möglich. Das Senden von Paketen an einen bestimmten und speziellen Switch, um dort Bearbeitungen am Paket durchzuführen ist denkbar, um den Controller zu entlasten [MABP + 08]. Die zentralisierte Control Plane vereinfacht vieles, bringt aber Skalierbarkeits-Bedenken mit sich. Die Beeinflussung der Geschwindigkeit der Paketweiterleitung ist stark abhängig von der Art des Einsatzes. Wird nur jeder neue Fluss an den Controller geleitet und dort klassifiziert, können vom Switch Pakete bereits bekannter Flüsse mit line-rate-geschwindigkeit und ohne große Erhöhung der Latenz bearbeitet werden. Bei Ankommen eines neuen Flusses kann die Latenz der ersten Pakete stark beeinträchtigt werden, da diese erst an den Controller weitergeleitet und dort bearbeitet werden müssen. Der Flow-Eintrag muss dann an den Switch gesendet werden, erst dann kann eine Entscheidung und das Weiterleiten des Pakets erfolgen. Die Auswirkung in diesem Fall hängt auch stark von der Latenz zum Controller, dessen Auslastung und Verarbeitungsgeschwindigkeit und allgemein von der Netzwerkstruktur ab. Wenn jedes Paket an den Controller weitergeleitet wird, gewinnt man Flexibilität auf Kosten stark verringerter Performance. Dies ist sicherlich eher zu Forschungszwecken interessant. In jedem Fall ist der Controller ein potentieller Flaschenhals, was die Geschwindigkeit betrifft. Die benötigte Rechenleistung, Anbindung und Anzahl (Last-Balancierung) des/der Controller sollte individuell sorgfältig ermittelt werden Netzwerkfunktionen und Anwendungen OpenFlow bietet je nach API bzw. Implementierung des Controllers viele unterschiedliche Einsatzmöglichkeiten und Funktionen. OpenFlow soll einen großen Bereich von Forschungen unterstützen, wie z.b. Campus-übergreifende Forschungsnetzwerke. Wenn OpenFlow an vielen Einrichtungen, zum Beispiel in Universitäten, eingesetzt wird, besteht die Möglichkeit, relativ einfach große Forschungsnetzwerke aufzuspannen. Diese Netzwerke müssen nicht 12

13 zwangsweise auf IP-Netzwerke beschränkt sein. Es soll dabei sichergestellt sein, dass experimenteller von produktiv-traffic getrennt wird. Um diese Netzwerken zu trennen, sind zwei Möglichkeiten denkbar: Das Weiterleiten des Pakets durch die normale Bearbeitungspipeline (Der Controller bestimmt dabei die Weiterleitungsregeln) oder Definieren von separaten VLANs [MABP + 08]. Weil Forschung erleichtert wird, sind schnelle Innovationen möglich. Neue Funktionen können im Controller (in Anwendungen) realisiert werden, es muss somit nicht mehr auf Produktzyklen oder Updates der Netzwerkgeräte-Hersteller gewartet werden [Foun12]. Es ist für den Benutzer auch möglich, Anwendungen selbst zu entwerfen, die speziellen Anforderungen gerecht werden. OpenFlow kann auch beim Netzwerkmanagement behilflich sein, z.b. durch Zugriffskontrolle im Netzwerk: Der Controller kann bestimmte Flüsse unterbinden. Auf gleiche Weise können Traffic-Isolation und virtuelle Netzwerke (VLAN-Funktionalität) einfach verwirklicht werden [MABP + 08]. Eine gezielte Manipulation der Paket-Header kann NAT oder ähnliche Funktionen (Adress-Verschleierung) nachbilden. OpenFlow ermöglicht viele Funktionen im Bereich des Traffic- und Route-Engineerings, zum Beispiel Lösung von Problemen, die bei Wifi-VOIP (Voice over IP) entstehen. Der Controller hat den Überblick über die Position des Gerätes. Ändert der Telefonierende seine Position und das Gerät seinen Access Point, so kann OpenFlow für ein nahtloses Re-Routing der Pakete ohne Unterbrechung des Gespräches sorgen. OpenFlow unterstützt Multicast und Multipath. Das kann bei Bandbreitenmanagement oder bei der Ausfallsicherheit von Bereichen des Netzwerkes helfen, zum Beispiel indem bestimmte Links als Backup spezifiziert werden [KLCK + 13]. Multicast wird durch Gruppen-Aktionen realisiert, das Multicast-Paket wird direkt auf dem Switch dupliziert und Kopien an alle Empfänger weitergeleitet [NPLH + 13, S. 18f.]. Der Controller kann die Flow-Tables der Siwtches konfigurieren, sodass Multipath- Routing ermöglicht wird. Anbieter von Controller-Software oder auch Benutzer selbst können durch die API des Controllers auf einfache Weise Anwendungen erstellen, die spezifische Anforderungen und Funktionalität erfüllen. Der Aufwand der Erstellung dieser Programme kann für den einzelnen Benutzer aber unter Umständen zu hoch sein. Auch eine Zugriffssteuerung am Controller ist je nach Implementierung möglich. Rollenbasierte Zugriffssteuerung (RBAC) bietet sich beispielsweise an, um die Möglichkeiten der Konfiguration einzuschränken oder auch Netzwerkressourcen zuzuteilen Komplexität der und Abhängigkeit von Netzwerkgeräten OpenFlow stellt eine Schnittstelle zu vielen Swichtes verschiedener Hersteller dar. Durch das Prinzip der Manipulation der Flow-Tabellen wird vermieden, dass Hersteller durch die Unterstützung von OpenFlow interne Strukturen ihrer Produkte offenlegen müssen. Es ist auch unwahrscheinlich, dass sich verschiedene Hersteller von Netzwerkgeräten in naher Zukunft auf einen Standard einigen, der auf der Offenlegung interner Details beruht, da dahinter teilweise jahrelange Forschungs- und Entwicklungsarbeit steckt [MABP + 08]. Die Unterstützung von Switches unterschiedlicher Hersteller ist ein Vorteil von OpenFlow. Wenn man sich für OpenFlow entscheidet, ist man also nicht an einen bestimmten Ausrüster gebunden. Durch OpenFlow wird nicht nur die Komplexität des Managements der Netzwerke reduziert, sondern auch die der benötigten Netzwerkhardware, da der Controller den Geräten viel Arbeit abnimmt [Foun12]. Dies führt zu geringeren Anforderungen an die Netzwerkhardware und eventuell auf lange Sicht zu geringeren Anschaffungskosten. Eine stufenweise Umstellung auf OpenFlow ist möglich und hat den Vorteil, dass die Folgen und Risiken einfacher einzuschätzen und beherrschbarer sind [Foun12]. 13

14 3.4 Cisco Open Network Environment (ONE) Architektur Cisco bietet mit ONE (Open Network Environment) eine eigene Plattform für Softwaredefined-Networking an. Vollständige OpenFlow Unterstützung ist Teil von ONE. Für die Zukunft ist die Unterstützung weiterhin vorgesehen [Cisc13d]. Es ist also davon auszugehen, dass auch neuere Versionen von OpenFlow unterstützt werden. Der SDN-Gedanke von Open- Flow beziehungsweise der Open Networking Foundation ist die strikte Trennung der Data Plane von der Control Plane. Daraus folgt das Agent/Controller-Prinzip von OpenFlow. Cisco will diesem Modell nicht strikt folgen, sondern mehrere Möglichkeiten der Programmierung des Netzwerks ermöglichen. Um diese Möglichkeiten zu realisieren, stehen neben OpenFlow zusätzliche Bibliotheken zur Verfügung [Cisc13d]. Die API, über die man auf diese zugreifen kann, heißt onepk (ONE Platform Kit). Die API ist einheitlich für verschiedene Cisco-Betriebssysteme (IOS, IOS XE, NX-OS, IOS-XR). Programme hierfür werden in C oder Java geschrieben, Unterstützung anderer Sprachen ist in Zukunft vorgesehen [KiKi13]. Die Funktionalität der API wird in Service Sets unterteilt. Diese umfassen ein DataPath Service Set, Policy Service Set, Routing Service Set, Element Service Set, Discovery Service Set, Utility Service Set und ein Developer Service Set (Abbildung 6). Figure 6: onepk Service Sets Mit dem DataPath Service Set kann eine Anwendung Pakete aus einem Paket-Fluss in einem Cisco Switch oder Router extrahieren und bearbeiten. Das geschieht entweder durch Kopieren oder Entnehmen (hierbei setzt das Gerät die Bearbeitung des Pakets erst fort, wenn die Anwendung es zurückgibt). Das Policy Service Kit dient dazu, Access Control Lists (ACLs, Zugriffskontrolllisten), Access Control Engines (ACEs) und Quality of Service (QoS) Politiken zu konfigurieren. Das Routing Service Set bietet die Möglichkeit, die RIB (Route Information Base) des Geräts zu manipulieren. Mit dem Element Service Set wird die Sitzung mit dem Gerät geregelt und Zugriff auf den Zustand, die Statistiken und Eigenschaften des Gerätes und der Interfaces gewährt. Das Discovery Service Set dient dazu, entfernte oder lokale Netzwerkelemente aufzufinden und Informationen über die Netzwerktopologie und onepk Services zu erhalten. Das Utilities Service Set gewährt Zugriff auf den Syslog und spezielle Funktionen in dem Gerät. Das Developer Service Set ist für Entwickler bestimmt und hilft beim Deployment oder Debugging der Anwendungen [Cisc13c] [Schi13]. Der von Cisco entwickelte Controller heißt extensible Network Controller (XNC), der sowohl OpenFlow als auch onepk unterstützt [KiKi13]. Der Controller ist dafür zuständig, APIs für spezifische Funktionen, die über mehrere Einheiten verlaufen und normalerweise auf die Agenten (onepk oder OpenFlow) angewiesen sind, bereitzustellen. Die Agenten laufen auf den Netzwerkgeräten und sind dafür zuständig, den lokalen Geräte-Status zu ändern oder zu extrahieren [Cisc13a]. Der Controller bekommt Informationen entweder durch OpenFlowoder onepk-agenten [Cisc13b]. Diese Informationen werden strukturiert (zum Beispiel im REST-Format) an die Anwendungen gesendet, welche Regeln erstellen. Diese Regeln werden an den Controller gesendet, der diese an die Agenten entsprechend weiterleitet. Anschließend 14

15 konfigurieren die Agenten die Netzwerkgeräte. Ist für die realisierte Funktion keine globale Sicht auf das Netzwerk nötig, kann die Anwendung anstatt auf einem Controller auch auf dem Switch ablaufen [Cisc13a]. Siehe Abbildung 7. Figure 7: Reines SDN mit Cisco ONE Verhaltensmodelle und Skalierbarkeit onepk Anwendungen können auf verschiedene Weisen deployed werden. Erstens ist es möglich, die Programme direkt auf den Netzwerkgeräten laufen zu lassen (Process Hosting). Diese werden durch Software-Container vom Netzwerkprozess isoliert, die Kommunikation findet mit spezieller IPC (Interprozeskommunikation) statt. Die zweite Möglichkeit besteht in dem Deployment im selben Chassis wie der Router beziehungsweise Switch, aber auf dedizierter Hardware (Blade Hosting). Drittens besteht die Möglichkeit, die Anwendungen auf einem dedizierten Rechner (Controller) zu platzieren (End-Point Hosting) [Cisc13c]. Hierzu wird eine sichere Verbindung zum Controller aufgebaut [Cisc13a]. Cisco unterstützt mit ONE also verschiedene Methoden, um programmierbare Netzwerke umzusetzen: Die Nutzung der APIs (onepk) der Netzwerkgeräte mit verschiedenen Deployment-Modellen oder pures Softwaredefined-Networking via OpenFlow [KiKi13]. Die unterschiedlichen Deployment-Methoden, die einem mit Cisco ONE für seine Anwendungen zur Verfügung stehen, führen zu besserer Flexibilität und Anpassbarkeit der Anwendungen in Bezug auf die benötigten Ressourcen und die Struktur des Netzwerks. Werden Anwendungen auf den Netzwerkgeräten platziert, führt das dazu, dass diese schneller ablaufen. Die erhöhte Latenz, die durch den Weg zum Controller entsteht, fällt damit weg. Bedenken bezüglich der Skalierbarkeit sind nicht in dem Maße angebracht, wie bei einem reinen Agent/Controller-Modell. Tatsächlich ist es sogar wahrscheinlich, dass dadurch Anwendungen entstehen, die mit einem reinen Software-defined-Networking beziehungsweise Agent/Controller-Prinzip zwar technisch möglich, praktisch aber nicht sinnvoll, da für gewisse Netzwerke nicht skalierbar sind (zum Beispiel Firewalls mit Deep-Packet-Inspection). Je nach Deployment-Modell und Berechnungsaufwand kann aber trotzdem die Hardware des Gerätes, auf dem die Anwendung gehostet wird, limitierend sein. Der Vorteil von ONE ist, dass man sich für eines der Deployment-Modelle entscheiden kann. Bei Verwendung von OpenFlow beziehungsweise onepk in der SDN-Version entstehen prinzipiell die gleichen Vor- und Nachteile die bereits in Abschnitt 3.3 aufgezeigt wurden. Die Skalierbarkeit des Controllers bei der Verwendung von onepk kann sich aber durchaus gegenüber OpenFlow ändern. 15

16 3.4.3 Netzwerkfunktionen und Anwendungen Durch das Deployment der Applikationen direkt auf den Geräten können auch Funktionen realisiert werden, die kurze Reaktionszeiten benötigen, zum Beispiel Firewalls [Cisc13d]. Durch Inspizieren des Payloads der Pakete können Funktionen, die Application-awareness voraussetzen, implementiert werden, zum Beispiel eine Malware-Erkennung. Nach Erkennen der Malware anhand des Payloads kann man mit ONE das betroffene Gerät aus dem Netzwerk isolieren [Cisc13d]. Der Payload kann auch manipuliert werden - ein mögliches Einsatzgebiet ist das Verschlüsseln auf dem Gerät mit benutzerdefinierten Algorithmen [Cisc13d]. Cisco ONE kann auch dazu verwendet werden, Geräte zu managen und zu überwachen. Netzwerkgeräte können sich ihre initiale Konfiguration von einem Server laden. Manche Service-Funktionen können automatisiert werden oder auf self-service-schnittstellen bereitgestellt werden. Echtzeitanalysen und Traffic-Visualisierung können dem Administrator beim Netzwerkmanagement eine Hilfe sein [Cisc13a] [Cisc13d]. Die Flexibilität des Deployments wird mit einigen Nachteilen erkauft. Zum Einen ist es in bestimmten Fällen aufwändiger, entsprechende Anwendungen zu entwickeln. Dies trifft insbesondere zu, wenn diese Anwendungen mit anderen Geräten kommunizieren müssen, um ihre Funktionalität zu ermöglichen. Über diese Kommunikation und möglicherweise notwendige Synchronisation der Anwendungen muss nicht nachgedacht werden, wenn man auf reines Software-defined-Networking setzt. Einige dieser Anwendungen können ihre Funktionalität teils nicht mehr bereitstellen, sobald ein Switch ausfällt, da dessen Informationen eventuell benötigt werden Komplexität der und Abhängigkeit von Netzwerkgeräten Durch SDN verspricht man sich außerdem eine Verringerung der Komplexität der Netzwerkgeräte an sich und damit sinkende Kosten bei der Anschaffung. ONE führt im Gegensatz eher zu erhöhten Hardware-Anforderungen der Geräte. Die Abhängigkeit zu Cisco, was Netzwerk-Elemente betrifft, kann ebenso erhöhte Anschaffungskosten bedeuten - und andere Nachteile nach sich ziehen. 3.5 VMware NSX Architektur VMware NSX basiert auf Entwicklungen von Nicira, ein Unternehmen, das im Juli 2012 von VMware eingekauft wurde [VMwa12]. Nicira konzentrierte sich auf virtualisierte Netzwerke. NSX entkoppelt nicht die Control Plane von der Data Plane der Netzwerkgeräte an sich, sondern reproduziert Layer 2, 3 und 4 (Sicherungs-, Vermittlungs- und Transportschicht) des Netzwerks in Software und erstellt somit ein virtualisiertes Netzwerk. Layer-4- bis Layer-7- Funktionen können mit Addon-Modulen nachgebildet werden [VMwa13]. Die Anwendungen auf den Servern sehen dabei keinen Unterschied zu traditionellen Netzwerken. Die physischen Netzwerkgeräte werden natürlich weiterhin benötigt, da diese von den Komponenten der virtualisierten Netzwerke als simple Paketweiterleitungseinrichtungen genutzt werden. Die Architektur von NSX besteht aus fünf Komponenten: Den vswitches in den Hypervisorn, den Gateways, dem Controller Cluster, dem NSX Manager und den NSX-Partnern beziehungsweise -Erweiterungen [Nagu13]. Da Server in Rechenzentren in der Regel schon virtualisiert sind und der erste Hop eines Paketes auf seinem Pfad auf den Servern geschieht, hat sich VMware dazu entschieden, auch dort die Data Plane des virtualisierten Netzwerkes zu implementieren [Davi13]. Dort läuft das 16

17 Mapping zwischen dem physischen und dem virtuellen Netzwerk ab. VMwares vshpere Distributed Switch (VDS) oder Open vswitch ( stellen diese Schnittstelle dar [Sequ13]. Die vswitches besitzen eine Konfigurationsdatenbank, auf die der Controller mit OVSDB (Open vswitch Database Management Protocol) zugreifen kann [Nagu13]. Sollten nicht-virtualisierte Geräte in das virtuelle Netzwerk eingebunden werden oder für Traffic, der aus dem oder in das Rechenzentrum geht, gibt es zwei Möglichkeiten: (1) Ein Softwarebasiertes Gateway, das eine Instanz eines Open vswitch enthält. Der Open vswitch ist unter der Kontrolle des NSX Controllers und bildet die physischen Ports in das logische Netzwerk ab. Das NSX Gateway macht es sogar möglich, bereits vorhandene VLAN-Netzwerke in das virtualisierte Netzwerk einzubinden [VMwa13]. Für eine größere Anzahl von nichtvirtualisierten Geräten (z.b. ein ganzes Rack) ist der Software-basierte Ansatz nicht geeignet. (2) Hier kommen VXLAN-kompatible (Virtual Extensible Local Area Network) Switches ins Spiel. Der VXLAN-Tunnel wird dem Data-Plane-Aspekt bei der Abbildung von physischen auf virtuelle Netzwerke gerecht. Ein Control-Plane-Mechanismus ist allerdings auch nötig, sodass der Controller dem Switch und umgekehrt alle benötigten Informationen mitteilen kann [Davi13]. Diese Informationen beinhalten: Informationen zu den VXLAN-Tunneln, z.b. Virtual-Network-Identifier und Ziel-IP- Adressen der Tunnel, da der Switch diese benötigt. Abbildungen zwischen den MAC-Adressen der virtuellen Maschinen (VMs) und den VXLAN-Tunneln, sodass der Switch weiß, wie Pakete zu einer bestimmten VM weitergeleitet werden müssen. Instruktionen für den Switch, zu welchen Ports welche logischen Netzwerke verbunden werden sollen. Umgekehrt muss der Switch dem Controller Informationen über das physische Netzwerk mitteilen, z.b. physische MAC-Adressen der Geräte, die an den Ports des Switches erreicht werden können. Diese Informationen werden über OVSDB (Open vswitch Database Management Protocol) ausgetauscht, der Switch muss dieses Protokoll also unterstützen [Davi13]. Der Controller Cluster besteht aus x86-rechnern, die die virtuelle Netzwerk-Topologie (je nach NSX-API-Anforderung) berechnen und die vswitches und Gateways entsprechend konfigurieren. Der Controller Cluster ist logisch zentralisiert, aber physisch verteilt. Jeder Rechner führt einen Teil der Berechnung aus, so ist Last-Balancierung und Skalierbarkeit gegeben. Ein Controller des Clusters bearbeitet im Gegensatz zu OpenFlow nie ein Datenpaket aus dem Netzwerk [Nagu13]. Das Zusammenspiel der Komponenten wird in Abbildung 8 veranschaulicht. Mit dem NSX-Manager steht dem Administrator ein web-basiertes GUI (Graphical User Interface) Management Dashboard zur Verfügung. Hiermit können unter anderem Logs und der Verbindungsstatus der Komponenten eingesehen werden. Es ist auch möglich, Snapshots des aktuellen Netzwerks als Backup zu erstellen [Nagu13]. Die NSX-API ermöglicht es Partnern, dem virtuellen Netzwerk Layer-4- bis 7-Services bereitzustellen Verhaltensmodelle und Skalierbarkeit Der Software-only-Ansatz ruft Bedenken bezüglich der Performance des Systems hervor. Dies trifft insbesondere dann zu, wenn das zu virtualisierende Netzwerk noch viele Komponenten enthält, die nicht virtualisierbar sind und somit mit NSX Gateways eingebunden werden müssen. 17

18 Figure 8: Zusammenspiel der NSX-Komponenten Netzwerkfunktionen und Anwendungen NSX bietet durch den Software-only-Ansatz eine hohe Flexibilität, was die Struktur des virtuellen Netzwerkes betrifft und ermöglicht somit viele verschiedene virtuelle Netzwerktopologien [VMwa13]. Es stellt virtuelle Switches, Router, Firewalls, Lastbalancierer usw. zur Verfügung. In den virtuellen Switches ist die komplette Switching-Funktionalität des Layers 2 und 3 in Software nachgebildet, losgelöst von darunterliegender Hardware. Da auch die Routing-Funktionalität virtualisiert wird, kann das gewünschte Forwarding-Verhalten von den Controllern dynamisch bestimmt werden. Die logische Firewall läuft im Kernel der Hypervisor mit line-rate-geschwindigkeit und ist sich über die virtuellen Netzwerkstrukturen bewusst. Eine Isolation und Vermietung von Teilen des Netzwerks beziehungsweise zugehöriger Komponenten ist mit NSX auch machbar [VMwa13]. Mit der NSX-API können Partner die Funktionalität um beispielsweise Netzwerk-Gateway-Services, Plattformen für Netzwerksicherheit, Anwendungsbereitstellung oder Sicherheitsservices erweitern. Die Hauptanwendung von NSX findet sich wohl in der Automatisierung von Rechenzentren. Es sind aber auch isolierte Test-Netzwerke auf dem selben zugrundeliegendem physischen Netzwerk möglich. Die Hypervisor haben zusammen vollen Einblick auf den Zustand des virtuellen Netzwerks. Gleichzeitig testet NSX den Zustand des physischen (Teil-)Netzwerks, das die virtuellen Switches und Gateways umfasst. Diese Statistiken können im NSX-Manager in Echtzeit eingesehen werden oder auch durch IPFIX exportiert werden, was Administration bei der Problembehandlung entlasten sollte [Hedl13]. Die Vorlaufzeit von neuen Netzwerkservices dürfte sich mit NSX verringern, weil diese in Software entwickelt werden können. VMWare NSX scheint eher für Rechenzentren geeignet. Das eigentliche Ziel war es offenbar, den Konfigurationsaufwand bei physischen Netzwerken drastisch zu reduzieren und nicht etwa neue Funktionen zu ermöglichen. Es gibt aber ein NSX-Partnernetzwerk, das Erweiterungen mithilfe der NSX API bereitstellt. Diese Erweiterungen umfassen unter anderem eine logis- 18

19 che Firewall, einen logischen Lastausgleich und ein logisches VPN. Eine Flexibilität wie bei Software-defined-Networking ist aber wohl nicht gegeben Komplexität der und Abhängigkeit von Netzwerkgeräten Die Einrichtung und Konfiguration der virtuellen Netzwerke mit einer Cloud Management Plattform beziehungsweise des NSX-Managers ist schnell und einfach möglich. Für den Administrator kann dies aber bedeuten, dass er den Überblick über das physische Netzwerk verliert. Der Administrator hat nun zwei Netzwerke zu betreuen: Das Physische und das Virtuelle. Sollten Probleme auftreten, bei denen NSX den Administrator nicht mit ausreichend Informationen versorgen kann, kann das das Debuggen erschweren. Problematisch sind besonders Inkonsistenzen zwischen dem virtuellen und physischen Netzwerk. Die Unabhängigkeit zur Netzwerk-Hardware ist vorteilhaft, da keine neue Hardware gekauft werden muss. Nachteilig ist aber, dass komplexe Netzwerkgeräte weiterhin gebraucht werden. NSX sorgt so eigentlich zunächst für zusätzliche Investitionskosten und vereinfacht nur die Einrichtung von logischen Netzwerken. Da es auf eine darunterliegende funktionierende IP- Hardware aufsetzt, muss diese weiterhin konfiguriert werden, wenn auch bedeutend weniger Services (zum Beispiel eine Firewall). Neue Traffic-Muster, die durch NSX verursacht werden, können zur Notwendigkeit von Hardware-Upgrades führen. 19

20 3.6 Tabellarischer Vergleich der Flusssteuerungslösungen Eigenschaft OpenFlow Cisco ONE VMware NSX Ausfallsicherheit Relativ hohe Controller-Redundanz Redundanz von vielen Wahrscheinlichkeit möglich; je nach Komponenten möglich; bei Einsatz nur eines Deployment unterschiedlicsistezen Probleme bei Inkon- Controllers; Redundanz möglich zwischen virt. und phys. Netzwerk Skalierbarkeit Last-Balancierung zwischen Controllern, aber keine Verteilung auf Netzwerkgeräten Offenheit offene Spezifikationen für Switches und Protokoll Deployment- Möglichkeiten Komplexität der Anwendungen Komplexität des Managements Komplexität der Hardware Einfluss auf Performance gering bis hoch, abhängig von den eingesetzten Anwendungen geringer als traditionelle Hardware (OpenFlowonly) Latenz-Erhöhung durch Controller Entwicklungsmöglichkeiten für Anwendungen hoch wegen unterschiedlicher Deployment-Modelle proprietär nur in Controller in Controller; in Geräten selbst; geteilt eher gering je nach Deployment und Struktur gering bis sehr hoch gering bis hoch, abhängig von den eingesetzten Anwendungen höher als traditionelle Hardware je nach Deployment und Anwendung kaum bis hohe Verringerung Balancierung zwischen Controllern im Cluster; CPU-Last durch Virtualisierung proprietär Erweiterungen nur mit API möglich NSX-Partnerschaft nötig gering keine Änderung gegenüber traditioneller Hardware CPU-Last und evtl. Latenz- Erhöhung durch vswitches; evtl. neue Traffic-Muster viele Funktionen sehr viele Funktionen NSX-Partnerschaft nötig, um Anwendungen entwickeln zu können Einsatzgebiete alle erdenklichen alle erdenklichen eher Rechen- und Datenzentren mögliche Kosten Interoperabilität der Netzwerkhardware hoch; viele unterschiedliche Geräte und Hersteller auf lange Sicht Verringerung, anfangs Hardware-Investitionen anfangs Investitionen; möglicherweise Erhöhung durch Herstellerabhängigkeit Abhängigkeit zu Cisco; Nur Cisco-Geräte nur NSX und Anwednungen; Netzwerkgeräte wie bisher keine Abhängigkeit, prinzipiell jede IP- Hardware Table 2: Vergleich der Flussüberwachungslösungen 20