1. 1. Software Defined Networking (SDN) mit OpenDaylight BETEILIGTE PERSONEN FH Joanneum- Informationsmanagement JG 2013: SCHLGL Ferdinand JANUSCH Micheal URCH Stephan BESCHREIBUNG/ZIELSETZUNG Software Defined Networking (SDN) wurde als neuer Ansatz zu Aufbau und Management von Computernetzen konzipiert. OpenDaylight ist einer der ersten umfassenden Implementierungskonzepte auf Open Source-Basis. In dieser Arbeit soll das Konzept von SDNs und Network Function Virtualization (NFV) anhand von OpenDaylight dargestellt werden und der Stand der Implementierung an einem Prototyp praktisch erprobt werden.
2. 2. INHALT Beteiligte Personen.......................................................................................................................................1 Beschreibung/Zielsetzung.............................................................................................................................1 1 Software Defined Networking ..............................................................................................................3 1.1 Begriffe und Erklrung ..................................................................................................................3 1.2 Layer und Northbound/Southbound APIs ....................................................................................4 1.3 Vorteile von SDN...........................................................................................................................5 1.4 Mgliche Nachteile von SDN-Lsungen........................................................................................5 1.5 NFV................................................................................................................................................6 1.6 NFV + SDN .....................................................................................................................................6 2 Praxisanwendung von OpenDaylight....................................................................................................7 2.1 Allgemeines...................................................................................................................................7 2.2 Funktionalitt und Aufbau............................................................................................................8 2.3 Hardware und Software Requirements........................................................................................9 2.4 Mininet........................................................................................................................................10 2.5 Maven .........................................................................................................................................10 2.6 Praxisteil: Einrichten eines SDN Controllers ...............................................................................11 2.7 Grafische Oberflche des OpenDaylight Controllers..................................................................19 2.8 Eine Flussregel (Flow rule) mit der GUI erstellen........................................................................21 3 Programmcode des HUB/L2 MAC learning Switch .............................................................................23 4 Resmee..............................................................................................................................................27 5 Quellenverzeichnis..............................................................................................................................29 5.1 Literatur/Onlinequellen ..............................................................................................................29 5.2 Bildquellen ..................................................................................................................................31
3. 3. Abbildung 2: Layerdarstellung [2] 1 SOFTWARE DEFINED NETWORKING 1.1 BEGRIFFE UND ERKLRUNG Der Begriff "Software-Defined Networking" wurde 2009 von Kate Greene geprgt, und somit ein recht neuer Ansatz in der Netzwerktechnik. Software-Defined Networking (oder abgekrzt: SDN) ist ein Ansatz zum Bau von Computernetzwerk-Gerten und Software. In herkmmlichen Netzwerken befand sich die Logik, welche fr die Paketweiterleitung zustndig ist direkt in den Gerten (Control Plane z.B. Statische Routen, benachbarte Gerte, Informationen von Routingprotokollen). Abhngig von diesen Informationen werden die Pakete dann ber die Data Plane (Datenleitungen im herkmmlichen Sinn) versendet. Abbildung 1: SDN Konzept [1] Bei SDN Lsungen wird die Data Plane und Control Plane voneinander getrennt. Somit knnen die Pakete zentral von einem Controller gesteuert werden. Diese Controller bieten Programmierschnittstellen (APIs) um andere Programmen/Applikationen an den Controller anbinden zu knnen. Dadurch ist es mglich sehr individuelle Softwarelsungen fr die Netzwerksteuerung zu erstellen oder auch das Einbinden von Netzwerkfunktionen in jede beliebige Applikation. Des Weiteren ermglicht SDN Netzwerkadministratoren, das Netzwerk einfacher zu verwalten, indem die unteren Funktionsebenen in virtuelle Services abstrahiert werden. Die Hardware
4. 4. muss also nicht mehr manuell konfiguriert werden. SDN gibt den Netzwerkadministratoren eine programmierbare, zentrale Steuerung des Netzwerkverkehrs, ohne manuellen Zugriff auf die einzelnen physischen Netzwerkkomponenten vornehmen zu mssen. Eine weitere Strke von SDNs sind die vielen APIs. Wie viele davon angeboten werden hngt vom SDN Produkt ab. Eine Voraussetzung fr SDN ist ein Kommunikationskanal zwischen Data Plane und Control Plane, damit der Datenfluss in der Data Plane auch die Anweisungen ber die Control Plane bekommt. Dafr gibt es verschiedene Protokolle, ein weitverbreitetes Protokoll ist das OpenFlow Protokoll. OpenFlow wird auch in OpenDaylight verwendet. 1.2 LAYER UND NORTHBOUND/SOUTHBOUND APIS Ein SDN Netzwerk lsst sich schematisch in drei Layer/Komponenten aufteilen, der Infrastructure Layer, der Control Layer und der Application Layer. Im Control Layer befindet sich der SDN Controller, der die Logik und Regeln des Netzwerkes enthlt. Der SDN Controller im Control Layer kommuniziert mit den Gerten im darunterliegenden Infrastructure Layer ber sogenannte Southbound APIs (sdliche Schnittstellen = nach unten, vom Controller aus gesehen; Kommunikationsweg zu einem Gert das hierarchisch darunterliegt). Wie oben erwhnt ist OpenFlow eine vebreitete Southbound-API, es gibt aber noch andere Kommunikationsprotokolle wie z.B. NETCONF, OVSDB, LISP, BGP, SNMP (auch sehr verbreitete Southbound-Schnittstelle). ber dem Control Layer befindet sich der Application Layer, in diesem werden die Applikation dargestellt, die mit dem Controller kommunizieren. Das knnen selbstgeschriebene Programme sein die das Netzwerk steuern oder konfigurieren knnen oder auch andere Anwendungen die ber sogenannte Northbound APIs (Norden= nach oben, vom Controller aus; hhere Anwendungsschicht) kommunizieren. Beispielsweise die Rest Api mit welche man dann mit Python, Java, C Anwendungen interagieren kann. Abbildung 3:Layer und N/S-APIs
5. 5. 1.3 VORTEILE VON SDN Direkte Programmierbarkeit Der Netzwerkfluss kann individuell beeinflusst werden und direkt anprogrammiert werden. Flexibilitt Da die Flusskontrolle einheitlich und sehr schnell fr alle Gerte gendert werden, da sie abstrahiert ist und als Ganzes gendert werden kann. Zentrale Verwaltung Die Netzwerklogik (die Intelligenz) kann zentral fr alle Gerte verwaltet werden, sie liegt im SDN- Controller, dadurch erhlt man mehr bersicht ber alle Regeln und Einstellungen der einzelnen Devices. Es ist mglich eine riesige Anzahl von Gerten mit wenig Aufwand zu konfigurieren. Programmatische Konfiguration In SDN Netzwerken ist es mglich auf den SDN-Controller automatische SDN Programme auszufhren, die z.B. Einstellungen fr gewisse Devices ausrollen etc Kosten/Zeitersparnis Durch die zentrale Verwaltung kann Zeit gespart werden, weil man nicht jedes Gert einzeln konfigurieren muss, bzw. keine Entfernungen zurcklegen muss um die Gerte zu erreichen. Es lsst sich alles am Controller konfigurieren. Monitoring Auch das berwachen und Aufzeichnen wird dadurch leichter, der Controller kann den Gesamten Traffic des Netzwerkes zentral berwachen. Quelloffene Lsungen Es gibt Open Source SDN Controller und auch viele offene Standards werden benutzt (OpenFlow) Modularitt In SDN Netzwerken lassen sich viele Vorgnge, wie z.B. das Konfigurieren von Gerten, als Funktionen auslagern. Diese Module knnen dann per Software in verschiedenen Anwendungsfllen immer aufgerufen werden. Sicherheit Durch die zentrale Verwaltung von allen Netzwerkregeln (Routen, Firewall settings,) hat man erheblich mehr bersicht ber bereits implementierte Sicherheitsregeln. 1.4 MGLICHE NACHTEILE VON SDN-LSUNGEN Durch die starke Zentralisierung der Netzwerklogik und Regeln auf einen oder mehreren SDN Controllern verringert man die Angriffsflche fr Attacken zwar erheblich, jedoch hngt dann das ganze Netzwerk von diesen Controllern ab. Diese mssen ausfallsicher konzipiert werden, des Weiteren muss fremdes Zugreifen und Einwirken verhindert werden, da sonst die Sicherheit des gesamten Netzwerkes in Gefahr ist. Ein weiterer Nachteil ist, dass viele Gerte keine passenden Southbound-APIs untersttzen, da der SDN Gedanke und die darin benutzten Protokolle recht neu sind. In der Praxis werden aber gerne noch Gerte
6. 6. eingesetzt die durchaus lter als 10 Jahre sind und zu dieser Zeit das SDN Konzept erst im Anfangsstadium war. Viele moderne Netzwerkgerte untersttzen z.B. das OpenFlow Protokoll, jedoch knnen die Anschaffungskosten moderner Router/Switches recht hoch werden, je nach Netzwerkgre. 1.5 NFV NFV ist ein ganz neues Konzept im Netzwerkbereich. Konkret wurde das Konzept erstmals in einem White Paper 2012 behandelt. NFV steht fr Network Functions Virtualisation. NFV soll die Virtualisierung von ganzen Netzwerkfunktionen ermglichen. Damit knnte man z.B. Firewalls, Load-Balancer und Intrusion Detection-Devices vollstndig virtualisieren. Abbildung 4: NFV Prinzip [4] Damit lassen sich sehr flexible Netzwerke aufbauen und man kann dadurch Geld sparen 1.6 NFV + SDN Virtualisierte Netzwerkkomponenten (NFV) in Kombination mit SDN Controllern, die die gesamte Netzwerklogik steuern knnen und als Softwareschnittstelle fungieren, sind ideale Komponenten fr um hochflexible Netzwerke aufbauen zu knnen. Netzwerke knnen mit virtuellen Gerten sehr dynamisch und flexibel erweitert werden, die Steuerung der neu erstellten virtuellen Netzwerkgerte bernimmt der
7. 7. SDN Controller. Diese Anforderungen werden sehr oft bei neuen Cloud Technologien verwendet und haben groes Zukunftspotential. 2 PRAXISANWENDUNG VON OPENDAYLIGHT 2.1 ALLGEMEINES Das OpenDaylight Projekt ist ein quelloffenes Projekt der Linux Foundation. Ziel des Projektes ist es den Einsatz von SDN Netzwerken zu frdern und eine solide Basis fr NFV-Komponenten zu bieten. Am 8. April 2013 wurde die Grndung des Projektes von der Linux Foundation angekndigt. Viele Firmen untersttzen das Projekt: Abbildung 5: Platinum Partner [4] Dies sind nur die Platinum Member(Hauptpartner/Untersttzer des Projektes), es gibt jedoch noch viele andere Partnerschaften. Die aktuelle/stabile Version des Projektes ist OpenDaylight Helium, der nchste geplante Release soll Lithium heien. Im folgenden Kapitel wird die Funktionalitt von OpenDaylight erklrt.
8. 8. 2.2 FUNKTIONALITT UND AUFBAU Mit OpenDaylight kann ein Anwender/in selber einen SDN Controller erstellen und damit auf die Control Plane der Netzwerkgerte zugreifen und somit den Netzwerkverkehr zentral steuern und Gerte zentral verwalten. Vorausgesetzt die Hardware Komponenten untersttzen ein Protokoll, das fr eine SDN Controlleransteuerung geeignet ist. OpenFlow ist ein sehr gut geeigneter Standard fr solche Anwendungen, jedoch mssen die Gerte dafr OpenFlow Enabled sein um mit dem Controller kommunizieren zu knnen (siehe Grafik). Des Weiteren werden viele andere Protokolle untersttzt. In der Controller Komponente befindenden sich einige integrierte Basisfunktionen (Topologie Manager, Switch Manager, Stats Manager) und sind ohne weiteren Installationsaufwand und Programmieraufwand zugnglich. Diese werden in einem spteren Kapitel noch genau vorgestellt. Ganz oben in der Grafik sind die Northbound APIs abgebildet, sie sind fr die Kommunikation mit hierarchisch hhere Objekte zustndig. Z.B. DLUX, eine grafische Oberflche. Abbildung 6: OpenDaylight Schema [5]
9. 9. 2.3 HARDWARE UND SOFTWARE REQUIREMENTS Die OpenDaylight Software ist Linux-basierend, man bentigt dazu also ein Linux Betriebssystem und das JDK 1.7+ (Java Developement Kit), auch Maven wird bentigt um die Controllerapplikation zu builden. OpenDaylight Controller sind nichts anderes als Java Programme und laufen in einer Java VM. Fr Testzwecke eignet sich eine virtuelle Maschine mit einer gngigen Linux Distribution sehr gut (VirtualBox, VmWarePlayer). Auf der VM kann dann der OpenDaylight Controller installiert und gestartet werden. Die virtuelle Maschine sollte jedoch gengend Arbeitsspeicher zur Verfgung haben, da der Controller im Betrieb sehr rechenintensiv ist, vor allem wenn mehrere Virtualisierungschichten (Linux Virtualisierung, Java Virtual Machine) dazwischen liegen. Die Hardware die man verwendet muss OpenFlow-enabled sein. Die uns angebotenen 2911-Router von Cisco sind nicht OpenFlow-enabled, also entschieden wir uns fr ein virtuelle Lsung. Um ein bungsnetzwerk mit Hosts und Hubs/Switches vollkommen zu simulieren bzw. virtualisieren zu knnen bentigten wir dazu eine geeignete Software, das Linux Programm Mininet. Wir machten jedoch die Erfahrung, dass eine virtuelle Linux Maschine, die ein Netzwerk virtualisiert und auf der ein SDN Controller luft sehr viel Arbeitsspeicher bentigt. Wir empfehlen hier 4GB+ Arbeitsspeicher zuzuweisen. Testszenario:
10. 10. 2.4 MININET Mit Mininet lassen sich ganze Netzwerke mit vielen Hosts, Switches und Hubs mit einem einzigen Befehl erzeugen. Das Pingen und Erzeugen von Traffic kann ber das Programm simuliert werden, des Weiteren knnen IP Adressen/MAC Adressen konfiguriert werden. Abbildung 7: Mininet [6] 2.5 MAVEN Wie bereits erwhnt sind OpenDaylight SDN-Controller Java Programme, um diese verwalten und erstellen zu knnen wird Maven bentigt. Typisch fr Maven ist, dass Projekte eine pom.xml Datei enthalten, in der Informationen ber das Softwareprojekt enthalten.
11. 11. 2.6 PRAXISTEIL: EINRICHTEN EINES SDNCONTROLLERS Es gibt zwei Mglichkeiten fr einen SDN-Konrolleraufbau: Komplettes manuelles Zusammensetzen der bentigten Komponenten: Auswahl einer Linux Distribution, Installieren der OpenDaylight Software mit den gewnschten Features, bentigte APIs und Bibliotheken manuell auswhlen und downloaden, Eventuell Netzwerkvirtualisierungssoftware installieren (Mininet etc..) , Softwareentwicklungsumgebung (z.B. Eclipse), Maven fr den Controllerbuild, JDK downloaden Vorgefertigte VMs fr Test- und Entwicklerzwecke benutzten: Es gibt fr Tutorial und Testzwecke bereits vorgefertigte Virtuelle Maschinen, die man fr Entwicklungs- und Probeszenarien verwenden kann. Wir entschieden uns fr eine vorgefertigte VM und fr die Virtualisierungssoftware Virtual Box: http://sdnhub.org/tutorials/sdn-tutorial-vm/ https://www.virtualbox.org/ Nach dem Download und der Installation von Virtualbox kann man die VM in Virtualbox einbinden: Das Importieren kann eine Weile dauern Danach sollte ein Fenster mit den Hardware-Spezifikationen erscheinen, diese sollten wie oben bereits erwhnt grozgig gewhlt werden und vor dem Starten der Maschine konfiguriert werden.
12. 12. Nach dem richtige konfigurieren kann die VM gestartet werden, die Ubuntu Maschine sollte nun laufen und ein Firefox Fenster mit einer SDN Startseite sollte erscheinen:
13. 13. Danach wird es Zeit ein Testnetzwerk mit dem Programm Mininet zu simulieren. Dazu wird eine Terminalkonsole geffnet und folgender Befehl verwendet: sudo mn: startet das Programm Mininet im Superuser Modus --topo tree: erstellt eine Netzwerk-Baumtopologie --depth=3: gibt die Tiefe des Netzwerkes an, wir whlten 3 --fanout=2: erstellt zweo Hosts an jedem Eckpunkt --switch ovsk,prtocols=OpenFlow13: Gertetyp fr Switches, Open vSwitch, erstellt virtuelle Switches die OpenFlow 1.3 verstehen --controller remote: gibt an, dass ein Controller die Gerte verwaltet, wir benutzen den OpenDaylight Controller dafr Mit Mininet lassen sich auch sehr schnell viele andere Netzwerktopologien simulieren. Auch die Hosts knnen nach Bedarf konfiguriert werden (MAC, IP). Desweitern verfgt Mininet ber eine Python API. Hier wird Minnet sehr gut beschrieben: http://conferences.sigcomm.org/sigcomm/2014/doc/slides/mininet-intro.pdf Nach dem Eingeben des Befehls sollte sich das virtualisierte Netzwerk aufbauen, man kann beobachten wie Hosts und Nodes erstellt werden:
14. 14. Nach dem Erstellen testeten wir das Netzwerk mit dem Ping Befehl. In Mininet kann man mit dem Befehl ping Pings simulieren: Es gibt keine Verbindung zwischen den Hosts weil es in diesem Netzwerk noch keinen Controller gibt, der das Netzwerk verwaltet, die virtuellen Switches sind in Wirklichkeit eigentlich noch keine Switches, sondern nur leere Gerte, die auf Anweisungen/Regeln eines Controllers warten. Man muss ihnen noch beibringen wie sie sich verhalten sollen. Jedes Verhalten der Netzwerkgerte wird in SDN Netzwerke vom Controller gesteuert. Abbildung 8: Mininet ohne ODL Controller [7] Ohne Controller existiert lediglich eine Forwarding Plane, auch Data Plane. Diese Forwarding Plane ist ohne Logik funktionlos. Der Controller wird dann die Logik fr die Forwarding Plane bereitstellten:
15. 15. Hier nun die Darstellung mit ODL Controller Abbildung 9: Mininet mit ODL Controller [7] Als nchstes wird der Controller gestartet, dazu muss man ein weiteres Terminal ffnen und in das OpenDaylight Verzeichnis wechseln, hier befinden sich die verschiedenen ODL-Projekte (OpenDaylight Projekte). In der Testmaschine befindet sich ein Projekt fr einen HUB/L2 learning Switch. Um den Controller mit diesem Code laufen zu lassen muss zuerst mit Maven das Java Programm erstellt werden (der SDN Controller ist eine Java Anwendung, die in einer JavaVM luft), danach startet man das von Maven erstellte Java Programm, dies ist dann der SDN Controller fr das Netzwerk. Praktisch ist, dass in der Testmaschine die Entwicklungsumgebung Eclipse mitinstalliert ist, man kann das Java Projekt und den Code darin komfortabel verndern und betrachten. Auf den Code wird im nchsten Hauptkapitel noch genauer eingegangen. Mit dem Befehl mvn install nsu sucht Maven im aktuellen Verzeichnis (Das OpenDaylight Verzeichnis) nach Projekten die zu Java Anwendung zusammengefgt werden knnen. Das sogennante builden startet:
16. 16. Am Ende sollte eine Meldung BUILD SUCCESS das erfolgreiche Builden der Controlleranwendung besttigen. Jetzt wird der Controller gestartet.
17. 17. Maven hat im Projektverzeichnis des HUB/L2 Switch eine run.sh Datei erstellt, mit dieser Datei kann der Controller gestartet werden. Dazu wird in das Verzeichnis gewechselt und mit ./run.sh der Controller gestartet: Der SDN Controller luft nun. Oben kann man nun erkennen, dass der Controller Gerte gefunden hat, das sind die virtuellen Netzwerk-Nodes die zuvor im Mininet virtuell erstellt worden sind. Mit dem command ss lassen sich auch die Bundles anzeigen, welche im Controller aktiv sind. Darunter sollte sich auch unser HUB/L2 Swtich Bundle befinden, auch ein Tomcat Sever befindet sich darunter, der fr das Webinterface zustndig ist.
18. 18. Mit dem Befehl printnodes werden alle Netzwerkgerte angezeigt, die mit dem Controller verbunden sind: Hier sieht man nun sieben verbundene Gerte. Jetzt wird es Zeit fr einen weiteren Ping Test, man wechselt wieder zurck in das Mininet Terminal und testet mit hX ping hX die Verbindung: Getestet wird die Verbindung zwischen Host 1 und Host 2. Diesmal funktioniert der Test, weil ein Controller luft. Der Controller enthlt den Code/Regeln fr den Netzwerkfluss. Ein weiterer Test wurde durchgefhrt: Bei beiden Tests kann man erkennen, dass der 1. Ping signifikant lnger dauert als die anderen. Der Grund dafr ist, dass die Gerte beim ersten Ping die MAC-Tabellen aufbauen. Beim zweiten Paket kann man bei beiden Tests erkennen, dass die Antwortzeit stark gesunken ist. Die Schwankungen und nicht ganz realen Werte lassen sich durch die Virtualisierung erklren. Anmerkung: Auf der virtuellen Linux Maschine luft eine virtuelle Java Maschine (SDN Controller) und parallel dazu wird ein ganzes Netzwerk virtualisiert. Hier kommt es gelegentlich zu Performance Problemen beim Testen.
19. 19. 2.7 GRAFISCHE OBERFLCHE DES OPENDAYLIGHT CONTROLLERS Der ODL Controller bietet auch eine grafische Oberflche an, diese luft auf einem Webserver auf Port 8080. Man kann mit folgender Adresse die Oberflche im Browser ffnen: http://localhost:8080 Die Standard Login Daten sind: Username: admin Passwort: admin Als nchstes sollte sich eine grafische Oberflche ffnen. Man sieht im Hauptbildschirm die Netzwerktopologie, leider ist eine automatische Anordnung der Elemente noch nicht implementiert und man muss die Gerte manuell anordnen. Die grafische Oberflche ist recht simpel aufgebaut und einige Grundeinstellungen knnen vorgenommen werden, jedoch werden komplexere Regeln/Anweisungen direkt im Projektordner des SDN Controllers mit Java programmiert. Fr einfache Einstellungen ist die grafische Oberflche sehr wohl geeignet.
20. 20. Gesamtbersicht GUI: Links befindet sich die Liste mit allen Netzwerkgerten, die mit dem Controller verbunden sind. Mit einem Doppeklick kann man sie auch umbenennen, fr eine bessere bersicht. Das Fenster im linken unteren Ecke ist fr statischen Routen reserviert, hier kann der/die Anwender/in statischen Routen fr die Gerte eintragen. Detailaufnahme Topologie:
21. 21. Im Fenster unterhalb des Topologie Bereichs befindet sich Informationen ber das aktuell ausgewhlte Objekt in der Topologie Karte. 2.8 EINE FLUSSREGEL (FLOW RULE) MIT DER GUI ERSTELLEN Um die grafische Oberflche zu testen, werden wir eine Flussregel fr ein Gert erstellen, diese dann installieren und anschlieend mit Ping-Befehlen testen. Geplant ist eine Regel am Switch OF13|1 (oberster Switch im Tree), die dafr sorgt, dass keine Datenpakete am Switch vorbeigelassen werden. Somit knnen Hosts 10.0.0.1 bis 10.0.0.4 keinen der Hosts 10.0.0.5 bis 10.0.0.8 erreichen und umgekehrt. Die Flussregel wird erstellt indem man links auf den Button Add Flow Entry klickt. Danach ffnet sich ein Fenster, in dem weiter Einstellungen zu ttigen sind. Neben dem Namen der Flussregel, muss hier der node, also das Gert auf dem die Regel wirken soll, und anschlieend der Input Port ausgewhlt werden. Am Ende des Fensters wird unter Actions ausgewht, was die Regel ausfhren soll. In unserem Fall wollen wir, dass alle Pakete verworfen werden, also ist hier Drop auszuwhlen. Anschlieend wird unter Save Flow die Flussregel gespeichert. Nun schliet sich das Fenster und wir sehen auf der linken Seite, dass die Flussregel erscheint. Diese kann jetzt ausgewhlt werden und wird durch das Klicken auf Install Flow im Fenster unter der Topologiefrafik angewandt.
22. 22. Um die Flussregel nun zu testen, probieren wir nun einfach einen Ping von Host 1 auf Host 8 aus. Anschlieend ein Ping von Host 1 auf Host 4. Da die Flussregel auf den Switch OF 13|1 wirkt, darf der erste Ping (Host 1 auf Host 8) nicht funktionieren. Der zweite jedoch (Host 1 auf Host 4), soll wie gewohnt ablaufen. h1 kann h8 nicht pingen h1 kann h4 pingen
23. 23. 3 PROGRAMMCODE DES HUB/L2 MAC LEARNING SWITCH Hier wird kurz auf den Programmcode eingegangen, den wir fr unseren SDN Controller verwendeten. Am Anfang werden die bentigten Imports gemacht, danach Grundvariablen definiert. Die folgenden Funktionen sind fr den Dependency Manager. Die eigentliche Hauptlogik des Switches/HUBs ist fett markiert und wird genauer betrachtet (siehe rote Kommentare //). /* * Copyright (C) 2014 SDN Hub Licensed under the GNU GENERAL PUBLIC LICENSE, Version 3. You may not use this file except in compliance with this License. You may obtain a copy of the License at http://www.gnu.org/licenses/gpl-3.0.txt Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * */ package org.opendaylight.tutorial.tutorial_L2_forwarding.internal; import java.net.InetAddress; import java.net.UnknownHostException; import java.util.List; import java.util.ArrayList; import java.util.Collections; import java.util.HashSet; import java.util.Set; import java.lang.String; import java.util.Map; import java.util.HashMap; import java.util.Timer; import java.util.TimerTask; import java.util.concurrent.ConcurrentHashMap; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.osgi.framework.Bundle; import org.osgi.framework.BundleContext; import org.osgi.framework.BundleException; import org.osgi.framework.FrameworkUtil; import org.opendaylight.controller.sal.core.ConstructionException; import org.opendaylight.controller.sal.core.Node; import org.opendaylight.controller.sal.core.NodeConnector; import org.opendaylight.controller.sal.flowprogrammer.IFlowProgrammerService; import org.opendaylight.controller.sal.flowprogrammer.Flow; import org.opendaylight.controller.sal.packet.ARP; import org.opendaylight.controller.sal.packet.BitBufferHelper; import org.opendaylight.controller.sal.packet.Ethernet; import org.opendaylight.controller.sal.packet.ICMP; import org.opendaylight.controller.sal.packet.IDataPacketService; import org.opendaylight.controller.sal.packet.IListenDataPacket; import org.opendaylight.controller.sal.packet.Packet; import org.opendaylight.controller.sal.packet.PacketResult; import org.opendaylight.controller.sal.packet.RawPacket; import org.opendaylight.controller.sal.action.Action; import org.opendaylight.controller.sal.action.Output;
24. 24. import org.opendaylight.controller.sal.action.Flood; import org.opendaylight.controller.sal.match.Match; import org.opendaylight.controller.sal.match.MatchType; import org.opendaylight.controller.sal.match.MatchField; import org.opendaylight.controller.sal.utils.EtherTypes; import org.opendaylight.controller.sal.utils.Status; import org.opendaylight.controller.sal.utils.NetUtils; import org.opendaylight.controller.switchmanager.ISwitchManager; import org.opendaylight.controller.switchmanager.Subnet; public class TutorialL2Forwarding implements IListenDataPacket { private static final Logger logger = LoggerFactory .getLogger(TutorialL2Forwarding.class); private ISwitchManager switchManager = null; private IFlowProgrammerService programmer = null; private IDataPacketService dataPacketService = null; private Map mac_to_port = new HashMap(); private String function = "switch"; void setDataPacketService(IDataPacketService s) { this.dataPacketService = s; } void unsetDataPacketService(IDataPacketService s) { if (this.dataPacketService == s) { this.dataPacketService = null; } } public void setFlowProgrammerService(IFlowProgrammerService s) { this.programmer = s; } public void unsetFlowProgrammerService(IFlowProgrammerService s) { if (this.programmer == s) { this.programmer = null; } } void setSwitchManager(ISwitchManager s) { logger.debug("SwitchManager set"); this.switchManager = s; } void unsetSwitchManager(ISwitchManager s) { if (this.switchManager == s) { logger.debug("SwitchManager removed!"); this.switchManager = null; } } void init() { logger.info("Initialized"); // Disabling the SimpleForwarding and ARPHandler bundle to not conflict with this one BundleContext bundleContext = FrameworkUtil.getBundle(this.getClass()).getBundleContext(); for(Bundle bundle : bundleContext.getBundles()) { if (bundle.getSymbolicName().contains("simpleforwarding")) { try { bundle.uninstall(); } catch (BundleException e) { logger.error("Exception in Bundle uninstall "+bundle.getSymbolicName(), e); } } }
25. 25. } void destroy() { } void start() { logger.info("Started"); } void stop() { logger.info("Stopped"); } private void floodPacket(RawPacket inPkt) { NodeConnector incoming_connector = inPkt.getIncomingNodeConnector(); Node incoming_node = incoming_connector.getNode(); Set nodeConnectors = this.switchManager.getUpNodeConnectors(incoming_node); for (NodeConnector p : nodeConnectors) { if (!p.equals(incoming_connector)) { try { RawPacket destPkt = new RawPacket(inPkt); destPkt.setOutgoingNodeConnector(p); this.dataPacketService.transmitDataPacket(destPkt); } catch (ConstructionException e2) { continue; } } } } @Override // Hier wird die Funktion fr das erhalten von Paketen berschrieben, Was soll ich bei einem incoming Packet tun? public PacketResult receiveDataPacket(RawPacket inPkt) { if (inPkt == null) { //hier wird geprft ob das incoming Packet null ist, um NullPointerExceptions zu vermeiden return PacketResult.IGNORED; } NodeConnector incoming_connector = inPkt.getIncomingNodeConnector(); // Hub implementation, man kann mit der functions Variabel den Switch auch auf einen einfachen HUB umstellen if (function.equals("hub")) { floodPacket(inPkt); // dann flooded er einfach alle Pakete an alle Ports, floodPacket() } else { Packet formattedPak = this.dataPacketService.decodeDataPacket(inPkt); //wenn er nicht im HUB Mode ist, if (!(formattedPak instanceof Ethernet)) { // wird das Packet decodiert/zerlegt return PacketResult.IGNORED; } learnSourceMAC(formattedPak, incoming_connector); // und danach vom zerlegten Packet (formattedPak) die NodeConnector outgoing_connector = // Source MAC Adresse gelernt und mit dem Port verknpft // (in die MAC Table aufnehmen, siehe Funktion learnSource // MAC) knowDestinationMAC(formattedPak); // Hier wird dann die Ziel MAC mit dem richtigen Zielport // verknfpt, das Packet kann jetzt dahin weitergeleitet // werden if (outgoing_connector == null) { // falls es hier aber zu einen Nullpointer kommt, kennt der floodPacket(inPkt); // Switch das Ziel noch nicht und flooded das Packet } else { // (broadcasten) if (!programFlow(formattedPak, incoming_connector, outgoing_connector)) { return PacketResult.IGNORED; } inPkt.setOutgoingNodeConnector(outgoing_connector); // falls es zu keinen Nullpointer kam, kennt der Switch // das Ziel und das Packet wird nun an den Outgoing // Connector (Port mit der Destination MAC) weitergeleitet
26. 26. // und somit versendet this.dataPacketService.transmitDataPacket(inPkt); } } return PacketResult.CONSUME; } private void learnSourceMAC(Packet formattedPak, NodeConnector incoming_connector) { byte[] srcMAC = ((Ethernet)formattedPak).getSourceMACAddress(); long srcMAC_val = BitBufferHelper.toNumber(srcMAC); this.mac_to_port.put(srcMAC_val, incoming_connector); } // Hier ist die Funktion fr das Lernen der MAC Adresse, zuerst wird das zerlegte Packet (formattedPak) // mit .getSourceMACAddress() angesprochen, diese wird dann als byte Folge gespeichert und nachher in ein // Variable des Typs long umgewandelt, danach wird sie mit dem icoming Port in einer Hashmap ( globale Variable // mac_to_port, sozusagen die MAC Table) verknpft private NodeConnector knowDestinationMAC(Packet formattedPak) { byte[] dstMAC = ((Ethernet)formattedPak).getDestinationMACAddress(); long dstMAC_val = BitBufferHelper.toNumber(dstMAC); return this.mac_to_port.get(dstMAC_val) ; } // In der knowDestinationMAC Funktion wird der Ziel Port fr eine bestimmte MAC zurckgegeben, // die Funktion liefer null zurck, wenn dieser nicht bekannt ist, im Code oben wird in so einem Fall // dann gebroadcastet (siehe if (outgoing_connector == null)) private boolean programFlow(Packet formattedPak, NodeConnector incoming_connector, NodeConnector outgoing_connector) { byte[] dstMAC = ((Ethernet)formattedPak).getDestinationMACAddress(); Match match = new Match(); match.setField( new MatchField(MatchType.IN_PORT, incoming_connector) ); match.setField( new MatchField(MatchType.DL_DST, dstMAC.clone()) ); List actions = new ArrayList(); actions.add(new Output(outgoing_connector)); Flow f = new Flow(match, actions); f.setIdleTimeout((short)5); // Modify the flow on the network node Node incoming_node = incoming_connector.getNode(); Status status = programmer.addFlow(incoming_node, f); if (!status.isSuccess()) { logger.warn("SDN Plugin failed to program the flow: {}. The failure is: {}", f, status.getDescription()); return false; } else { return true; } } }
27. 27. 4 RESMEE Grundstzlich ist die Idee von SDN-Netzwerken sehr gut, jedoch der aktuelle Status der Software (OpenDaylight) ist noch sehr weit von einer Marktreife entfernt. Es gibt zwar eine grafische Oberfche, diese ist jedoch mehr ein kleines Feature und keine richtige Oberflche mit vielen Funktionen. Wir haben es auch sehr lstig empfunden, das OpenDaylight nicht mit der neuesten Java Version funktioniert, wir hatten nmlich eine Linux Maschinen manuell zusammengestellt (mit der neuesten Java Version-JDK) und danach funktionierte der Controller nicht. Wir mussten ein Downgrade durchfhren und hatten dabei keinen Erfolg, da es bei Linux keine so komfortable Softwareverwaltung wie bei Windows gibt. Daher mussten wir die Maschine neu aufsetzen. Aufgefallen ist uns auerdem der Hardwarehunger des Controllers, zugegeben wir virtualisierten ein ganzes Netzwerk nebenbei, jedoch sollte eine virtuelle Maschinen mit einem OpenDaylight Controller mindestens 4GB Arbeitsspeicher haben. Mit mininet machten wir gute Erfahrungen, mit diesem Programm ist es enorm einfach Netzwerke zu simulieren. Mit einem Befehl lassen sich groe Netzwerke virtualisieren, die auch sehr leicht zu konfigurieren sind (IP, MAC). Aber ab einer gewissen Gre bentigt man auch wieder mehr Arbeitsspeicher, man sollte es bei 3-5 Knoten und 5-15 Hosts belassen, wenn man nicht gerade High-End Gerte besitzt. Nun zum Controller, die Logik der Controller sind in Java geschrieben, der Code ist eigentlich auch nicht schwer zu verstehen, jedoch findet man wenig Literatur und Sourcecodes fr Netzwerkgerte. Es ist mglich jedes Netzwerkgert komplett manuell zu programmieren (Alles, die Logik, die Funktionen, das Verhalten, Sicherheitsregeln). Man kann z.B. eingehende Pakete bis zu Layer 2 zerlegen und dann programmatische Anweisungen geben, was mit dem Paket passieren soll. Auch ist es mglich andere Applikation mit integrieren, also eine sehr mchtige Lsung. Wir sehen aber genau bei diesen Punkten ein groes Problem, durch das vollstndige Individualisieren der Netzwerkfunktion mit eigenen Programmcode kann es zu groen Sicherheitsproblemen kommen, allein schon durch die Tatsache, dass z.B. ein Admin einfach nicht alle Sicherheitslcken programmatisch eliminiert, weil es fast unmglich ist an alle Eventualitten zu denken. Auerdem, wenn die SDN Controller ausfallen, funktioniert das gesamte Netzwerk nicht mehr, auch wenn ein Hacker den Controller bernimmt, hat er Vollzugriff auf Alles. Fr Unterrichtszwecke wrde sich ein OpenDaylight Szenario unserer Meinung nach sehr gut eignen, vor allem fr IMA Studenten ab dem 4. Semester. Man bentigt so ziemlich genau all jene Dinge, die man im Studiengang gelernt hat. Grundlagen Linux: SADML Java Kenntnisse fr den Controllercode: SWENGA, SWENGB Netzwerkkentnisse/Protokolle: HVSYS, Netzwerkfcher Ein Problem wre aber die unserer Meinung nach die sehr instabile Arbeitsumgebung, weil das Produkt noch nicht ausgereift ist. Die aktuelle Version ist fr ein nicht kommerzielles Projekt schon recht weit, aber man sollte weiter Entwicklungen abwarten. Die Technologie ist sehr vielversprechend!
28. 28. Wir finden es sehr gut, dass man wirklich jedes Netzwerkgert selber programmieren kann, sehen jedoch auch die mglichen Sicherheitsrisiken. Wir sind der Meinung, Firmen sollten SDN Lsungen mit Vorsicht einsetzen, am besten nur in isolierten Netzwerkbereichen, vielleicht nur in internen Umgebungen.
29. 29. 5 QUELLENVERZEICHNIS 5.1 LITERATUR/ONLINEQUELLEN Hier sind die Quellen kapitelweise aufgefhrt, die Inhalte wurden teilweise mit eigenen Wissen ergnzt. Englische Texte wurden sinngem bersetzt. Kapitel oder Bilder ohne Quellenangaben wurden vollstndig selbst erfasst oder erstellt. Software Defined Networking: Begriffe und Erklrung: http://en.wikipedia.org/wiki/Software-defined_networking http://de.wikipedia.org/wiki/Software-defined_networking https://www.opennetworking.org/sdn-resources/sdn-definition Layer und North/Southbound API: http://networkstatic.net/the-northbound-api-2/ Vorteile von SDN: https://www.opennetworking.org/sdn-resources/sdn-definition NFV: https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-sdn-nvf- solution.pdf NFV + SDN: https://www.sdxcentral.com/sdn-nfv-use-cases/data-center-optimization/ http://en.wikipedia.org/wiki/Network_functions_virtualization#Relationship_to_SDN http://www.opendaylight.org/resources/about-sdn-and-nfv
30. 30. https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-sdn-nvf- solution.pdf OpenDaylight: Allgemeines: http://www.opendaylight.org/project/members http://www.opendaylight.org/project/about http://en.wikipedia.org/wiki/OpenDaylight_Project https://wiki.opendaylight.org/view/Simultaneous_Release:Helium_Release_Plan Hardware und Software Requirements: https://wiki.opendaylight.org/view/Installing_OpenDaylight Mininet: http://mininet.org/ Maven: http://de.wikipedia.org/wiki/Apache_Maven
31. 31. 5.2 BILDQUELLEN [1] http://blogs.cisco.com/ciscoit/sdn-101-what-it-is-why-it-matters-and-how-to-do-it [2] https://www.opennetworking.org/sdn-resources/sdn-definition [3] http://networkstatic.net/the-northbound-api-2/ [4] http://www.opendaylight.org/project/members [5] http://www.opendaylight.org/sites/www.opendaylight.org/files/pages/images/odp_diagram_helium.jp g [6] http://mininet.org/ [7] https://www.youtube.com/watch?v=TnVON_3bM08