6. Termin 2: Configure and Program a Network
6.1 Configure a Network
Versetzt euch bitte in folgende Situation:
Wieder in eurem neuen Job:
Ihr habt die erste Aufgabe eures Chefs zu seiner Zufriedenheit gelöst und ihm damit gezeigt, dass ihr auf der Uni doch auch etwas praktisches gelernt habt. Also stellt er jetzt eine anspruchsvollere Aufgabe:
Ihr sollt die Vernetzung der einzelnen, quer über Deutschland verteilten Filialen mit Hilfe von Standleitungen reorganisieren. Alternativ zu den Standleitungen sollen noch DSL-Verbindungen eingeplant werden, die nur bei Ausfällen eingesetzt werden sollen. Da ihr die neue Struktur erst einmal simulieren und analysieren wollt, bevor ihr bei der Telekom die (teuren) Standleitungen beantragt, erinnert ihr euch an ein kleines Programm namens KNet, das ihr damals an der Uni im Praktikum Kommunikationsnetze kennen (und lieben) gelernt habt, mit dem man relativ einfach verschiedene Netzwerktopologien simulieren kann, ohne erst umständlich ein Netzwerk aufbauen zu müssen. Drei kleine Konfigurationsdateien als Beispiele und das Skript des Praktikums als Bedienungsanleitung helfen, die geplante Struktur mittels KNet zu simulieren.
Die drei Konfigurationsdateien (Muenchen.cfg. Nuernberg.cfg und Berlin.cfg) beschreiben die in Abb.16 gezeigte Netzwerkkonfiguration.
Um mit dieser Netzwerkkonfiguration arbeiten zu können, startet ihr in drei terminals's eines Linux-Rechners das KNet-Programm jeweils mit einer der drei Konfigurationsdateien als Parameter:
knet Muenchen.cfg
knet Nuernberg.cfg
knet Berlin.cfg
Startet nun auf dem Netzwerkknoten Muenchen ein ping zum Knoten Berlin.
| KNet(Muenchen): | ping Berlin | ||
| Ping to Berlin (49.1.10.1)\\ | |||
| Ping: Got an Echo for Packet 0 ( 120 ms ) | |||
| Ping: Got an Echo for Packet 1 ( 100 ms ) | |||
| Ping: Got an Echo for Packet 2 ( 100 ms ) | |||
| Ping: Got an Echo for Packet 3 ( 100 ms ) | |||
Während ping weiter sendet, schaltet zum Knoten Nuernberg um und beendet dort das Programm mit dem QUIT-Befehl:
| KNet(Nuernberg): | quit |
Schaltet dann wieder zurück zum Knoten Muenchen.
- Was passiert währendessen beim ping-Prozess im Knoten Muenchen?
- Startet KNet Nuernberg.cfg wieder. Was passiert jetzt in Muenchen?
- Beendet auf dem Netzwerkknoten Muenchen den ping-Prozess, indem ihr dort Ctrl-C drückt.
- Beendet alle drei KNet-Programme mit dem QUIT-Befehl und ändert die Konfigurationsdateien so ab, dass jeder dieser drei Netzwerkknoten auf einen anderen Rechner abgebildet wird.
Dazu sind Änderungen an dem DEVICE-Befehl und dem LINK-Befehl notwendig! Jede Arbeitsgruppe sollte sich jetzt 3 Linux-Rechner aussuchen, an denen sie den Rest des Praktikums arbeitet, damit sie nicht bei jedem Praktikumstermin die Konfigurationsdateien ändern muss. - Testet eure neue Konfiguration wie zuvor. Hat sich das Verhalten der Knoten geändert?
- Ändert erneut die Konfigurationsdateien, indem ihr eine neue Verbindung (Ausweichverbindung) zwischen Muenchen und Berlin (und zurück) erzeugt (zusätzliche LINK- und ROUTE-Befehle!). Diese neue Verbindung soll aber mit einer wesentlich schlechteren METRIC definiert werden (z.B. 20 oder 30)
- Testet die erweiterte Konfiguration wie zuvor und beantwortet folgende Fragen:
- Hat sich das Verhalten der Knoten geändert?
- Wenn ja, unter welchen Umständen treten Veränderungen auf?
- Wann werden Daten so übertragen wie vor der Änderung?
Optional als Hausaufgabe: Nachdem ihr euch mit dem KNet-Programm und den Konfigurationsdateien vertraut gemacht habt und die vorherigen Fragen beantworten konntet, sollt ihr jetzt eine komplexere Netzwerkstruktur (siehe Abb. 17) nachbilden.
Dazu müsst ihr für jeden Netzwerkknoten festlegen, auf welchem Rechner er abgebildet werden soll und die entsprechenden Konfigurationsdateien erstellen.
Testet eure Konfiguration zuerst zwischen den direkt verbundenen Knoten (Nuernberg und Berlin, Hamburg und Hannover, ...). Wenn hierbei keine Fehler auftreten, testet die Verbindung zwischen entfernten Knoten (Nuernberg und Hamburg, ..) und beantwortet die folgenden Fragen:
- Wie werden jetzt die Daten (von Traceroute) zwischen Muenchen und Hamburg übertragen?
- Was passiert, wenn KNet(Hannover) mit QUIT beendet wird?
- Was passiert, wenn zusätzlich KNet(Frankfurt) mit QUIT beendet wird?
- Was passiert, wenn (einige Zeit später) die Verbindung Hannover - Frankfurt wieder gestartet wird?
- Was muss getan werden, damit der ursprüngliche Weg wieder benutzt wird?
6.2 Program a Network
In eurem (nicht mehr ganz so neuen) Job:
Ihr habt bei der Simulation der neuen Netzwerk-Struktur festgestellt, dass in eurer KNet-Version der Routing-Algorithmus nicht alle euch zur Verfügung stehenden Kriterien auswertet. Da ihr aber auch noch die Quell-Dateien des KNet-Programms von damals behalten habt und auch das Programmieren nicht verlernt habt, könnt ihr die Routing-Funktion euren Anforderungen anpassen (Was ihr hiermit auch tut!). Euer Chef ist von euch begeistert, die Probezeit habt ihr hervorragend bestanden.
Im KNet-Netzwerk werden Datenpakete, die von KNet-Applikationen wie ping oder traceroute versendet werden, solange von einem Netzwerk-Knoten zum anderen geleitet, bis diese beim gewünschten Empfänger angekommen sind.
Damit die Pakete nicht "unendlichlange" auf der Reise sind, sollten sie nicht wahllos an irgendwelche Rechner geleitet werden, sondern die Entscheidung sollte nach festgelegten Regeln erfolgen. Diese Regeln nennt man Routing-Kriterien. So wird anhand der Empfängeradresse (bzw. eines Teils davon), dem Netzwerkzustand usw. entschieden, was mit einem Daten-Paket zu geschehen hat.
Im KNet-Programm wird diese Entscheidung von der Funktion routePacket in der Datei route.c unter Zuhilfenahme einiger anderer Funktionen getroffen. Diese Funktion (und die Unterfunktionen) soll von euch reimplementiert werden. Dabei ist von euch vorher festzulegen, welche Kriterien bei der Entscheidung eine Rolle spielen und wie stark sie die Entscheidung beeinflussen.
Hinweis:
Beispielsweise solltet ihr klären, welcher Weg besser ist (d.h. über welche Verbindung die Daten schneller ans Ziel kommen):
- Einer, der mit \(HopCount = 2\) und \(Metric = 5\) oder der mit \(HopCount = 1\) aber \(Metric = 7\) ins Ziel führt?
- Einer, dessen \(Metric = 7\) ist und dessen Verbindung schon aufgebaut ist, oder einer mit einer \(Metric = 5\), aber dessen Verbindung noch aufgebaut werden muss?
- Wenn die Verbindung noch nicht aufgebaut ist, traten bei früheren Versuchen die Verbindung aufzubauen, eventuell Fehler auf? Wenn ja, wie ist dies zu bewerten?
Im Allgemeinen repräsentiert ein kleinerer Metric-Wert die bessere Verbindung. Man kann also z.B. den HopCount zum Metric-Wert addieren (oder beide multiplizieren) und zusammen mit dem Verbindungszustand und der Anzahl der Verbindungsfehler eine Gesamtsumme bilden.
Hinweis:
Die Routing-Entscheidung wird in KNet auf folgendem Weg erreicht:
- Liste aller für diesen Empfänger möglichen Übertragungswege (Routen) erstellen.
- Liste sortieren:
- dazu wird benötigt: Adressen vergleichen (Adresse, Netz-Maske,...)
- außerdem: Metric-Einträge vergleichen ( Metric, HopCount, ...)
- außerdem: Netzwerkzustand auswerten (Verb.Zustand, Verb.Fehler, ...)
Die zum KNet-Programm gehörenden QueIl-Dateien sind in Tabelle 1-1 aufgelistet.
| Dateiname | Funktion |
|---|---|
| route.c | Funktionen, die die Routing- Tabelle verändern und die eigentliche route-Funktion. |
| route.h | die dazugehörige Header-Datei. |
| knet_def.h | alle KNet-globalen Definitionen, z.B. Paket-Kopf-Struktur. |
| link.h | alle Definitionen, die für das Hantieren mit KNet-Links(Verbindungen) beötigt werden. |
| dev.h | alle Definitionen, die für das Hantieren mit KNet-Devices (Schnittstellen) benötigt werden. |
| service.h | Funktionen, die zur Unterscheidung der Applikationen und Netzwerk-Services benötigt werden (lokale Port-Verwaltung). |
| host.h | Funktionen, die die Adress-Namens-Umsetzung zur Verfügung stellen (Name-Service). |
Der Aufruf von make sorgt dafür, dass die Datei class="BlockD-marked code">route.c kompiliert wird (falls ihr sie editiert habt) und mit einem Paket aus allen anderen KNet-Programmteilen zu einem lauffähigen Programm gebunden wird.
make linux/knet Muenchen.cfg
6.3 Tipps und Tricks
Mit dem "debug"-Befehl kann man für verschiedene KNet-Module (route, link, dev, ping, ...) Debug-Meldungen zulassen bzw. unterdrücken. Wenn ihr z.B. den Routing-Algorithmus programmiert, könnt ihr damit verfolgen, was genau während der "Entscheidungsfindung" getan wird.Der "trace"-Befehl ist eine sparsamere Variante des "debug"-Befehls. Während mit "debug" alle Einzelheiten angezeigt werden sollen (z.B. Anzahl der Bytes, die gesendet bzw. empfangen wurden, alle Funktionsaufrufe ...), so wird von "trace" nur die generelle Anzeige von Aktivitäten erwartet (z.B. Verbindung geöffnet bzw. geschlossen, Paket empfangen bzw. gesendet ...).