Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- sdn-start-mit-mininet-vm-ryu-floodlight-opendaylight [2014/07/25 14:49] – benny
+++ sdn-start-mit-mininet-vm-ryu-floodlight-opendaylight [2024/06/09 10:29] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 1: / Zeile 1: @@
-====== Software-Defined-Networks (SDN) Einstieg ohne Hardware mit Mininet VM und Ryu/Floodlight/OpenDaylight Controller ======
+====== Software-Defined-Network (SDN) Einstieg (ohne Hardware) mit Mininet VM und Ryu SDN Controller ======
-<WRAP center round todo 60%>
+<WRAP center round alert 60%>
-Dieser Artikel befindet sich noch im Aufbau! :)
+Dieser Artikel ist nicht veröffentlicht. Bitte über die Startseite zugreifen!)
 </WRAP>
-Aller Anfang ist schwer oder doch nicht? Die virtuellen Maschinen von [[http://sdnhub.org/tutorials/sdn-tutorial-vm/|SDN Hub]] machen uns den Einstieg leicht(er)!
+Aller Anfang ist schwer oder doch nicht? Die virtuellen Maschinen von [[http://sdnhub.org/tutorials/sdn-tutorial-vm/|SDN Hub]] machen uns den Einstieg leicht(er)! Ziel dieses Artikels ist es einen Überblick zu Software-Defined-Network (SDN) mit Mininet und Ryu zu geben, ohne dafür spezielle Switch-Hardware zu benötigen.
 ===== Voraussetzungen =====
@@ Zeile 14: / Zeile 15: @@
 ===== Einstieg =====
-Die virtuelle Maschine bringt eine große Anzahl von SDN Controllern bereits mit. Wir fokussieren uns in diesem Artikel allerdings auf [[http://osrg.github.io/ryu/|Ryu]], später vielleicht noch auf Floodlight und OpenDaylight.
+Die virtuelle Maschine bringt eine Vielzahl von SDN Controllern bereits mit. Wir fokussieren uns in diesem Artikel allerdings auf [[http://osrg.github.io/ryu/|Ryu]].
+Ryu ist ein SDN-Controller der von der [[http://www.ntt.co.jp/index_e.html|NTT]] (Nippon Telegraph and Telephone Corporation) entwickelt wird. In Europa kennt man vielleicht eher die Tochtergesellschaft [[http://www.dimensiondata.com/de-DE|Dimension Data]].
-Ryu ist ein SDN-Controller der von der NTT (Nippon Telegraph and Telephone Corporation) entwickelt wird. In Europa kennt man vielleicht eher die Tochtergesellschaft [[http://www.dimensiondata.com/de-DE
+Mir gefällt dieser Controller besonders gut, da die Community ([[https://lists.sourceforge.net/lists/listinfo/ryu-devel|ryu-devel Mailingliste]]) sehr hilfsbereit ist. Es fällt auf dass die Entwickler sich selbst Zeit nehmen um auf die Fragen zu reagieren und den Controller auch auf Anfragen hin weiterentwickeln wenn eine API o.ä. bisher nicht vorhanden ist. Ryu ist in [[https://www.python.org/|Python]] entwickelt und kommt mit diverse Beispielapplikationen mit denen man testen kann. (Natürlich kann man Ryu auch selbst erweitern, dies würde aber den Rahmen dieses Artikels sprengen! :))
-|Dimension Data]]. Mir gefällt dieser Controller besonders gut, da die Community (ryu-devel Mailingliste) sehr hilfsbereit ist. Es fällt auf dass die Entwickler sich selbst Zeit nehmen um auf die Anfragen zu reagieren und den Controller auch auf Anfragen hin weiterentwickeln wenn eine API o.ä. bisher nicht vorhanden ist. Ryu ist in [[https://www.python.org/|Python]] entwickelt und kommt mit diverse Beispiel Applikationen mit denen man arbeiten kann. (Natürlich kann man Ryu auch selbst erweitern, dies würde aber den Rahmen dieses Artikels sprengen ...)
-Neben dem SDN Controller ist in der VM noch [[http://mininet.org/|Mininet]] enthalten. Mininet erlaubt uns neben einem oder mehreren Switches auch noch Clients/Teilnehmer am Netz zu simulieren.
+Neben dem SDN Controller ist in der VM auch [[http://mininet.org/|Mininet]] enthalten. Mininet erlaubt es uns neben einem oder mehreren Switches auch noch Clients/Teilnehmer am Netz zu simulieren.
 Jeder der hier angesprochenen Bausteine hätte seinen eigenen kilometerlangen Artikel verdient, aber heute möchte ich nur Starthilfe geben. :)
@@ Zeile 134: / Zeile 136: @@
 </code>
 {{ ::xtermh1.png?nolink |}}
+=== Nach Abschluss der Tests mit Mininet aufräumen ===
+<WRAP center round important 60%>
+Dieses Kommando erst nach Beendigung der Tests durchführen!
+</WRAP>
+<code>
+$ sudo mn -c
+</code>
 ===== SDN-Controller: Ryu =====
@@ Zeile 157: / Zeile 167: @@
 Im Rahmen dieses Artikels ist es nicht wirklich relevant welche "Buffer" oder "Table"-Fähigkeiten der virtuelle Switch hat, dies ist aber später auf physikalischen Switches sehr wichtig zu wissen.
 </WRAP>
+===== Erkunden der SDN-Lösung: Relevante OpenFlow Details =====
+==== OpenFlow Kommunikation zwischen Mininet Switch und Ryu ====
+Um sehen zu können was passiert, sollte der in der VM enthaltene Wireshark gestartet werden. Damit wir darin alle Schnittstellen sehen, ist es notwendig diesen mit "sudo" zu starten.
+<code>
+$ sudo wireshark &
+</code>
+{{ ::wireshark-sdn.png?nolink |}}
+Da wir alle Kommunikation lokal abwickeln, sollte um die OpenFlow-Kommunikation zu sehen auf der "Loopback: lo" Schnittstelle mitgeschnitten werden.
+==== Anzeige der hinterlegten Flows ====
+Bevor wir jetzt zwischen den Teilnehmern / Hosts pingen, sollten wir uns die hinterlegten Flows im OpenVSwitch (OVS) anschauen.
+<code>
+mininet> dpctl dump-flows --protocols OpenFlow13
+*** s1 ------------------------------------------------------------------------
+OFPST_FLOW reply (OF1.3) (xid=0x2):
+ cookie=0x0, duration=3026.918s, table=0, n_packets=0, n_bytes=0, priority=0 actions=CONTROLLER:65535
+</code>
+Dieser Flow besagt: Alles zum Controller schicken! Normalerweise ist dies die "Regel des letzten Auswegs" (sonst würde der Datenverkehr verloren gehen!). Der OVS wird also alles was an Daten an ihn herangetragen wird an den SDN-Controller schicken, der ihm darauf sagen wird wie er damit in Zukunft umzugehen hat.
+==== Der erste Ping ====
+Genug mit der Theorie, ich will pingen!
+<code>
+mininet> h1 ping h2
+PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
+bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=210 ms
+bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.963 ms
+bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.092 ms
+bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.086 ms
+bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.096 ms
+^C
+--- 10.0.0.2 ping statistics ---
+packets transmitted, 5 received, 0% packet loss, time 4001ms
+rtt min/avg/max/mdev = 0.086/42.443/210.978/84.268 ms
+mininet> dpctl dump-flows --protocols OpenFlow13
+*** s1 ------------------------------------------------------------------------
+OFPST_FLOW reply (OF1.3) (xid=0x2):
+ cookie=0x0, duration=4169.600s, table=0, n_packets=3, n_bytes=182, priority=0 actions=CONTROLLER:65535
+ cookie=0x0, duration=145.181s, table=0, n_packets=6, n_bytes=532, priority=1,in_port=3,dl_dst=00:00:00:00:00:01 actions=output:1
+ cookie=0x0, duration=145.075s, table=0, n_packets=5, n_bytes=434, priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:3
+mininet>
+</code>
+Wie man sehen kann, wurden dadurch zwei neue Flow-Einträge erzeugt. (Außerdem kann man sehen wieviel Pakete/Bytes diese Vorgänge erzeugt haben.)
+==== Woher kommen diese Einträge? ====
+Durch den Eintrag dass alle unbekannten Daten an den Controller gesendet werden, hat Ryu diese Anfragen erhalten und entschieden was damit zu tun ist.
+{{ ::ryu-events.png?nolink |}}
+Im Wireshark können wir nun auch eine Reihe von neuen Paketen sehen (wichtig ist hier nach "OFPT_PACKET_IN" zu gucken).
+{{ ::of1-arp.png?nolink |}}
+Dies ist der Versuch von **h1** den Partner **h2** zu erreichen. Da h1 nicht weiß welche MAC-Adresse h2 hat, wird zuerst ein ARP-Request zum Auflösen der h2-IP -> MAC-Adresse gesendet. Außerdem ist oben die Information enthalten auf welchem OFB-IN-Port (1) das Paket reingekommen ist. Wir müssen auch besondere Aufmerksamkeit auf die **Buffer ID: 256** legen, denn hier hat der OVS das Paket abgespeichert bis der SDN-Controller ihm sagt wie damit zu verfahren ist.
+{{ ::of2-flood.png?nolink |}}
+Da auch der SDN-Controller bisher keine Übersicht hat, was wo angeschlossen (wenn auch virtuell) ist, wird der OVS instruiert das Paket auf alle Ports außer dem eingehenden zu senden (flood). Hier kann man auch die im vorherigen Schritt verwendete **Buffer ID: 256** wiederfinden (damit weiß der OVS um welches Paket es geht).
+{{ ::of3-reply.png?nolink |}}
+Durch den "Flood" hat **h2** den ARP-Request erhalten und antwortet nun mit einem ARP-Reply.
+Der OVS hat für diese Kommunikation bisher noch keinen vollständigen Flow-Eintrag, daher landet auch dieses Paket beim Controller (**Buffer ID: 257**).
+{{ ::ov4-1-flowmod.png?nolink |}}
+{{ ::of4-2-flowmod.png?nolink |}}
+Nun passiert etwas sehr wichtiges, der SDN-Controller fügt einen Flow-Eintrag hinzu da jetzt genug Informationen über die Kommunikation vorliegen. Dieser bedeutet: Wenn ein Paket auf OFB-IN-PORT 3 (dort ist **h2** angeschlossen) reinkommt und als Ziel die MAC-Adresse (ETH-DST) von **h1** hat, dann sende das Paket auf OF-PORT 1 raus. (Dies vermeidet dass für weitere Pakete dieser Art der Controller gefragt werden muss.) //Besonderheit: Ryu referenziert in diesem Fall nicht die **Buffer ID: 257**, was man eigentlich hätte tun können damit dieser Flow nicht nur im OVS eingetragen wird sondern das Paket auch gleich so behandelt wird. Ob dies eine Spezialität dieser Ryu-Beispielapplikation ist, muss ich noch testen.//
+{{ ::of4-3output.png?nolink |}}
+Hier referenziert Ryu nun die **Buffer ID: 257** und instruiert den OVS das Paket auf OF-Port 1 zu senden.
+{{ ::of5-icmp.png?nolink |}}
+Hier geht nun der eigentliche "Ping" von **h1** zu **h2** los. Vielleicht fragt ihr euch nun warum das Paket hier wieder im SDN-Controller landet obwohl wir nun eben beim "ARP" dies schonmal durchlaufen haben (**Buffer ID: 258**): Es handelt sich __erstmalig__ aus dieser Richtung um ein Paket das alle Informationen enthält (inkl. der Ziel-MAC-Adresse von **h2**, bisher war die im ARP-Request nämlich 00:00:00:00:00:00 bzw. ff:ff:ff:ff:ff:ff gesetzt!)
+{{ ::of6-1-flowmod.png?nolink |}}
+{{ ::of6-2-flowmod.png?nolink |}}
+Hier kann man nun den Eintrag des Flows von OFB-IN-PORT 1 zu **h2** (ETH_DST) sehen.
+{{ ::of7.png?nolink |}}
+Hier nun abschließend die Instruktion an den OVS das Paket an **Buffer ID: 258** auf OF-Port 3 rauszuschicken.
+==== Mininet Flow-Table ====
+Mit allem was wir uns angeschaut haben, machen diese Einträge nun auch Sinn!
+    * Bei eingehenden Paket auf Port (in_port) 1 mit dem Ziel dl_dst=00:00:00:00:00:02 (dl = Data Link)
+      * Aussenden auf Port 3
+    * Bei eingehenden Paket auf Port (in_port) 3 mit dem Ziel dl_dst=00:00:00:00:00:01 (dl = Data Link)
+      * Aussenden auf Port 1
+    * Passen die eingehenden Pakete nicht auf diese Flows, dann sende die Pakete an den Controller
+<code>
+mininet> dpctl dump-flows --protocols OpenFlow13
+*** s1 ------------------------------------------------------------------------
+OFPST_FLOW reply (OF1.3) (xid=0x2):
+ cookie=0x0, duration=4921.582s, table=0, n_packets=3, n_bytes=182, priority=0 actions=CONTROLLER:65535
+ cookie=0x0, duration=897.163s, table=0, n_packets=6, n_bytes=532, priority=1,in_port=3,dl_dst=00:00:00:00:00:01 actions=output:1
+ cookie=0x0, duration=897.057s, table=0, n_packets=5, n_bytes=434, priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:3
+</code>
+==== Abschließende Informationen ====
+=== Idle Timeout ===
+Beim **Idle Timeout** handelt es sich die Zeit (in Sekunden) nach der der Flow aufgrund von Inaktivität (Flow hat nicht auf eingehende Pakete gepasst, engl. "match") entfernt wird.
+= unendlich
+=== Hard Timeout ===
+Beim **Hard Timeout** handelt es sich die Zeit (in Sekunden) nach der der Flow **trotz Aktivität** entfernt wird.
+= unendlich
+=== Priority ===
+Je höher die **Priority**, desto wichtiger ist der Eintrag. Soll heissen, passt ein Paket auf einen Flow mit der Priorität 500 und würde auch auf einen Eintrag mit der Priorität 300 passen, wird der OVS/Switch bis zu diesem Eintrag nie kommen da die Abarbeitung der Tabelle nach dem ersten Eintrag stoppt und die Aktion ausgeführt wird.
+===== Relevante Dokumentation =====
+  * [[https://github.com/mininet/openflow-tutorial/wiki|Mininet Openflow Tutorial]]
+  * [[http://ryu.readthedocs.org/en/latest/|Aktuellste Ryu Dokumentation]]
+  * [[http://sdnhub.org/tutorials/|SDN Hub Tutorials (verschiedene SDN-Controller)]]