cow-dateisystem und softwareinstallation einrichtung von...

Projektpraktikum VNUML SS06

COW-Dateisystem und Softwareinstallation

Einrichtung von DHCP, DNS und Routing in VNUML

Uli Eckstein, Rufus Linke, Martin Pätzold

Inhaltsverzeichnis

1 Einleitung........................................................................................................................3

2 Softwareinstallation in den virtuellen Maschinen..........................................................3

2.1 Das COW-Dateisystem in VNUML.......................................................................3

2.2 Vergrößerung des Dateisystems und Umstellung auf ext3.....................................4

2.3 Softwareinstallationen mit apt-get..........................................................................5

3 Entwurf einer Netzstruktur.............................................................................................6

3.1 Übersicht.................................................................................................................6

3.2 Implementation der Netzwerke in VNUML...........................................................7

4 Einrichtung von DHCP...................................................................................................9

4.1 Server......................................................................................................................9

4.2 Client.....................................................................................................................10

4.3 Ablauf einer DHCP-Anfrage................................................................................11

4.4 Aufgaben...............................................................................................................12

5 Einrichtung von DNS...................................................................................................15

5.1 Installation des DNS-Servers BIND.....................................................................15

5.2 Entworfene DNS-Hierarchie.................................................................................15

5.3 Konfiguration der DNS-Server.............................................................................15

5.4 DNS-Anfragen......................................................................................................19

5.5 Aufgaben...............................................................................................................21

6 Routing.........................................................................................................................26

6.1 Installation und Konfiguration von Zebra.............................................................26

6.2 Aufbau der Routingtabellen..................................................................................27

6.3 Aufgabe.................................................................................................................28

7 Literaturverzeichnis......................................................................................................30

2

1 Einleitung

Ziel des Projektpraktikums „Simulationen mit User Mode Linux“ im Sommersemester

2006 war, mit VNUML ein komplexes virtuelles Netzwerk zu erstellen und darin die

üblichen Dienste zu implementieren und zu administrieren.

Unsere Aufgabe bestand darin, zunächst eine Basis zur Softwareinstallation in den

virtuellen Maschinen zu schaffen. Im weiteren Verlauf nutzten wir diese, um

anschließend die Netzwerkdienste DHCP und DNS einzurichten. Schließlich

unterteilten wir das Netzwerk in drei separate Netze, um so sinnvoll Routingaufgaben

mittels RIP zu demonstrieren.

Alle folgenden Angaben beziehen sich auf VNUML Version 1.5.

2 Softwareinstallation in den virtuellen Maschinen

2.1 Das COW-Dateisystem in VNUML

Normalerweise wird in VNUML, vor allem um Speicherplatz zu sparen, nicht für jeden

virtuellen Rechner ein eigenes Dateisystem angelegt, sondern ein Root-Dateisystem

verwendet, an welchem die virtuellen Maschinen selbst keine Änderungen vornehmen

können. Sämtliche simulierten Rechner booten von diesem Image und haben zunächst

alle denselben Datenbestand. Falls ein Rechner im Netzwerk Veränderungen am

Dateisystem vornimmt, werden diese nicht in das ursprüngliche Image geschrieben,

sondern in einer separaten Datei, der sogenannten COW-Datei (Copy On Write)

abgelegt. Diese befindet sich im Dateisystem des Hostrechners unter:

/var/vnuml/<Name_des_Szenarios>

Findet ein Zugriff auf ein COW-Dateisystem statt, wird zunächst geprüft, ob in der

COW-Datei eine Änderung vorliegt. Trifft dies zu, so werden die Daten aus der COW-

Datei gelesen. Andernfalls referenziert die COW-Datei auf das ursprüngliche Root-

Dateisystem. So wird mit einem minimalem Mehrbedarf an Speicherplatz ermöglicht,

verschiedene Dateisystemkonfigurationen zu nutzen. Dabei ist natürlich zu beachten,

dass bei Löschung der COW-Dateien sämtliche Änderungen an den Dateisystemen der

virtuellen Maschinen verloren gehen.

Außerdem ist zu beachten, dass die COW-Dateien neu angelegt werden müssen, sobald

das Ursprungsdateisystem verändert wird, da sie auf dieses referenzieren und durch

diese Änderung die Verweise ungültig werden. Sind keine COW-Dateien vorhanden, so

3

werden diese beim Starten von VNUML automatisch neu angelegt.

Möchte man die in einer virtuellen Maschine vorgenommenen Änderungen in das

Originalimage zurückschreiben, und damit für sämtliche Rechner, die auf dieses

zugreifen, übernehmen, so bietet sich das Tool „uml_moo“ an. Die Anwendung

gestaltet sich folgendermaßen:

Entweder man schreibt alle Änderungen direkt in die vorherige Root-Imagedatei und

überschreibt sie damit

rechnet1:~# uml_moo d <cow_file>

oder erstellt ein neues Image auf Basis des Originals mit den Änderungen der COW-

Datei.

rechnet1:~# uml_moo <cow_file> <new_image_file>

Anschließend ist nun daran zu denken, die COW-Dateien aller virtuellen Rechner, die

auf dieses Image zugreifen, zu löschen (s.o.).

2.2 Vergrößerung des Dateisystems und Umstellung auf ext3

Das mit UML mitgelieferte Dateisystem „root_fs_tutorial“, auf dem wir in dieser Arbeit

aufbauen, bietet nicht genügend freien Speicherplatz. Daher vergrößern wir es, um

weitere Softwareinstallationen zu ermöglichen. Zunächst sollte man das Dateisystem

mit Hilfe von e2fsck auf Fehler überprüfen:

rechnet1:~# e2fsck f <Imagedatei>

Danach kann man es folgendermaßen vergrößern:

rechnet1:~# dd if=/dev/zero of=<Imagedatei> bs=1 count=1 \ seek=<neue_Größe> conv=notrunc

rechnet1:~# resize2fs p <Imagedatei>

Es kann aufgrund von Filesystemchecks beim Starten größerer Szenarien zu langen

Wartezeiten kommen. Um dieses Problem zu umgehen, haben wir uns entschlossen,

das Dateisystem auf ext3 umzustellen. Ext3 bietet im Gegensatz zu ext2 die Funktion

des Journaling, wodurch Filesystemchecks nach Abstürzen signifikant beschleunigt

werden. Dazu dient das Programm tune2fs:

rechnet1:~# tune2fs j <Imagedatei>

Zu beachten ist, dass der Kernel nun ext3 unterstützen muss.

4

2.3 Softwareinstallationen mit apt-get

Da das ursprüngliche Dateisystem auf Debian basiert, ist die einfachste Möglichkeit zur

Installation zusätzlicher Software die Paketverwaltung „apt-get“, die die benötigten

Pakete über das Internet bezieht und gleichzeitig eventuelle Abhängigkeiten auflöst.

Dazu benötigen die virtuellen Maschinen jedoch Internetzugriff über den Host. Hierzu

muss der Host IP-Forwarding und NAT unterstützen und auf den virtuellen Rechnern

als Standardgateway eingetragen werden.

Aktivieren von IP-Forwarding auf dem Host:

rechnet1:~# echo "1" > /proc/sys/net/ipv4/ip_forward

Aktivieren von NAT auf dem Host:

rechnet1:~# iptables t nat A POSTROUTING o eth0 j \

MASQUERADE

Desweiteren muss auf den virtuellen Rechnern in die Datei /etc/resolv.conf ein

erreichbarer Internetnameserver eingetragen werden (beispielsweise Uni Koblenz:

141.26.64.1).

Die Standardgröße des Arbeitsspeichers von 32 MB in VNUML reicht für die

Benutzung von apt-get nicht aus. Daher haben wir sie mit Hilfe des <mem>-Tags in der

XML-Szenariospezifikation auf 100 MB erweitert.

Apt-get bezieht seine Paketquellen aus der Datei /etc/apt/sources.list. Im vorhandenen

Dateisystem root_fs_tutorial sind einige der in dieser Datei stehenden Server nicht mehr

ansprechbar, daher ersetzen wir sie durch folgende Quellen:

# Debian GNU/Linux "Stable":

deb http://ftp2.de.debian.org/debian/ stable main nonfree contrib

debsrc http://ftp2.de.debian.org/debian/ stable main nonfree contrib

deb http://nonus.debian.org/debiannonUS stable/nonUS main contrib nonfree

debsrc http://nonus.debian.org/debiannonUS stable/nonUS main contrib nonfree

deb http://security.debian.org/ stable/updates main contrib nonfree

Nun sind alle Voraussetzungen geschaffen um apt-get auszuführen. Dabei stellen wir

hier nur die wichtigsten Befehle vor. Eine komplette Übersicht erhält man mit man

aptget.

Paketdatenbank aktualisieren:

dns1:~# aptget update

5

Installieren von Paketen:

dns1:~# aptget install <Paketname>

Löschen von Paketen:

dns1:~# aptget remove <Paketname>

Da das vorhandene Dateisystem veraltet ist, haben wir die ganze Debian-Distribution

mittels

dns1:~# aptget distupgrade

auf die aktuelle Stable-Version (3.1) gebracht.

3 Entwurf einer Netzstruktur

3.1 Übersicht

Folgende Netzstruktur wurde im Verlauf des Praktikums entworfen:

Es existieren drei Netze, die über drei Router paarweise verbunden sind. Die Bezeichner

an den roten Verbindungen zu den Netzen geben die IP-Adresse des angeschlossenen

Rechners an. So hat zum Beispiel der Rechner router0 in Net1 die Adresse 10.0.1.10

6

und in Net0 die Adresse 10.0.0.10. Die blauen Bezeichner geben an, dass die IP-

Adresse komplett dynamisch über DHCP vergeben wird, während die grünen Namen

eine statische Adressvergabe anzeigen. Die DHCP-Server müssen bereits vor allen

anderen Rechnern über die XML-Spezifikation eine feste IP-Adresse erhalten, dies wird

über ein * in der Grafik angezeigt. Zwischen vpn und host2 existiert ein virtuelles

privates Netzwerk, welches in einer anderen Projektgruppe bearbeitet wurde. Auf die

weiteren Dienste (www-ftp, nis-nfs), die hier bereits eingezeichnet sind, wird ebenfalls

in den anderen Arbeitsgruppen weiter eingegangen. Die Rechner host0 bis host2 stellen

Beispielclients dar und übernehmen keine weiteren Aufgaben im Netzwerk.

3.2 Implementation der Netzwerke in VNUML

In VNUML wird eine virtuelle Netzwerkumgebung über eine XML-Datei erstellt. Die

komplette XML-Datei unserer Simulation findet sich auf der Homepage des

Projektpraktikums. Zur Erklärung stellen wir hier die Besonderheiten vor.

Innerhalb von <global>:

<automac offset="1"/>

Zur Vergabe der statischen IP-Adressen über DHCP definieren wir in der XML-Datei

feste MAC-Adressen. Die automatisch von VNUML vergebenen MAC-Adressen haben

folgende Form: fe:fd:0:Z:X:Y. Die Variable X bezeichnet die Nummer des

virtuellen Rechners und Y die Netzwerkschnittstelle. Über Z kann man optional einen

Offsetwert angeben, bei dem die Vergabe anfangen soll. Unsere selbstvergebenen

Hardwareadressen benutzen hier den Wert 0. Um Konflikte zu vermeiden, setzen wir

den Offsetwert für automatische Vergabe auf 1.

<default_filesystem type="cow">

/usr/local/share/vnuml/filesystems/root_fs_pp06

</default_filesystem>

<default_kernel>

/usr/local/share/vnuml/kernels/linux2.6.101mv2

</default_kernel>

<basedir>/usr/local/share/vnuml/examples</basedir>

Mit den beiden <default>-Tags legen wir das Dateisystem und den Kernel für alle

virtuellen Maschinen fest. Da wir häufig das <filetree>-Tag benutzen, setzen wir

7

mit <basedir> den Standardpfad zu den darin benutzten Dateien.

Im Folgenden werden wir anhand eines Beispielrechners die Konfiguration der

simulierten Rechner erklären.

<vm name="dns1">

<mem>50M</mem>

<if id="1" net="Net0">

<ipv4>10.0.0.1</ipv4>

</if>

<filetree root="/etc/bind" when="always">

vnuml_pp06/dns1/bind

</filetree>

<filetree root="/root/config" when="always">

vnuml_pp06/dns1/config

</filetree>

<exec seq="config" type="verbatim">

/root/config/dns1_config

</exec>

</vm>

Um Speicherengpässen vorzubeugen wird der Arbeitsspeicher mittels <mem> vom

Standardwert 32 MB auf 50 MB erhöht. Dieser Rechner fungiert als DHCP-Server und

muss daher die IP-Adresse im Voraus fest zugeteilt bekommen.

In unserer Simulation benutzen alle virtuellen Maschinen das gleiche Dateisystem,

benötigen jedoch zum Starten unterschiedlicher Dienste eigene Startkonfigurationen.

Diese Konfigurationen haben wir in ein für jeden Rechner eigens angelegtes

Verzeichnis gespeichert (basedir/vnuml_pp06/Rechnername). Diese werden

über das <filetree>-Tag beim Starten der Simulation in die entsprechenden Ordner

der virtuellen Rechner kopiert. Die einzelnen Dienste werden über das

Rechnername_config-Skript gestartet, welches über <filetree> ins

Verzeichnis /root/config jedes virtuellen Rechners kopiert wird. Es wird

anschließend mit Hilfe der <exec>-Sequenz „config“ ausgeführt.

Grundlegend sind alle Rechner auf diese Weise spezifiziert. Auf Abweichungen davon

gehen wir nun ein.

Auszug aus der Konfiguration von dns4:


<mac>fe:fd:00:00:00:04</mac>

</if>

8

Dieser Rechner erhält eine statische IP-Adresse über DHCP und benötigt daher eine

feste MAC-Adresse, die über das <mac>-Tag gesetzt wird. Die Rechner, welche

dynamische IP-Adressen vom DHCP-Server beziehen, benötigen aufgrund von

<automac> keinerlei Angaben im <if>-Tag.

Auszug aus der Konfiguration von router0:

<forwarding type="ipv4"/>

Um die Funktionalität der Router zu gewährleisten, wird bei ihnen das Forwarding für

IPv4 aktiviert.

Nach dem Starten der Simulation lassen sich nun alle benötigten Dienste mit dem

Befehl

rechnet1:~# vnumlparser.pl x config@vnuml_pp06.xml

aktivieren, so dass das Netzwerk einsatzbereit ist.

4 Einrichtung von DHCP

4.1 Server

Die DHCP-Server Software muss zunächst installiert werden.

dns1:~# aptget install dhcp

Die Konfiguration des Servers erfolgt über die Datei /etc/dhcpd.conf. Die Einträge

defaultleasetime 100000;

maxleasetime 120000;

geben in Sekunden an, wie lange vergebene IP-Adressen gültig bleiben sollen, bis

Clients eine neue Adresse anfordern müssen. defaultleasetime bezeichnet

dabei die Dauer der Vergabe, falls der Client keine bestimmte lease-time anfordert.

maxleasetime gibt die maximal mögliche Vergabedauer an.

subnet 10.0.0.0 netmask 255.255.255.0 {

range 10.0.0.100 10.0.0.200;

option domainnameservers 10.0.0.1;

host router0 {

hardware ethernet fe:fd:00:00:00:10;

fixedaddress 10.0.0.10;


}

}

9

Über subnet wird ein Subnetz angegeben, für welches der DHCP-Server IP-Adressen

vergibt. Das obige Beispiel ist ein Auszug aus der Konfiguration von dns1, er verwaltet

die IP-Adressen im Netz 10.0.0.0/24 (Net0). range definiert den Bereich der

dynamisch zu vergebenen Adressen, dns1 teilt dynamischen Clients also IP-Adressen

von 10.0.0.100 bis 10.0.0.200 zu. Die option domainnameservers gibt an,

dass der Server allen dynamischen Clients den folgenden DNS-Server (hier dns1 selbst)

mitteilen soll. Clients mit statischer IP-Adresse werden über das host-Statement

konfiguriert. Dabei gibt man zunächst die Hardwareadresse des Clients, anschließend

mittels fixedaddress die zuzuweisende IP-Adresse an. Dieser Client erhält dann

bei jeder Adressanfrage diese Adresse. Auch hier kann man die option domain

nameservers angeben. Weitere Konfigurationsmöglichkeiten bieten die Manpages

zu dhcpd.conf.

Standardmäßig nimmt der Server Anfragen auf eth0 an. Dieses Interface ist jedoch bei

VNUML immer als Managementinterface reserviert. Daher lassen wir den DHCP-

Server an eth1 laufen. Das Startskript /etc/init.d/dhcp bezieht seine Optionen

aus der Datei /etc/default/dhcp, deshalb ändern wir dort den Eintrag

INTERFACES.

INTERFACES="eth1"

Durch apt-get wird der Server so konfiguriert, dass er beim booten automatisch

hochfährt. In unserem Dateisystem startet der dhcpd jedoch nicht automatisch, sondern

wird auf den entsprechenden Rechnern über das <exec>-Tag „config“ gestartet.

Manuell lässt sich der Server mit

dns1:~# /etc/init.d/dhcp start

dns1:~# /etc/init.d/dhcp restart

starten bzw. neustarten.

4.2 Client

Wie der Server muss der DHCP-Client zunächst installiert werden:

host0:~# aptget install dhcpcd

Zur Konfiguration dient die Datei /etc/dhcpc/config. Auch hier wird das Interface auf

eth1 gesetzt

case ${INTERFACE} in

eth1)

10

Damit die Clients den vom Server zugeteilten DNS-Server in ihre

/etc/resolv.conf eintragen, entfernen wir den Kommentar in der Zeile

# SET_DNS='yes'

Jetzt kann man den Client mit

host0:~# dhcpcd eth1

starten.

4.3 Ablauf einer DHCP-Anfrage

Möchte ein Client eine IP-Adresse beziehen, so schickt er ein DHCP-Broadcastpaket

mit der Absenderadresse 0.0.0.0 (da er noch keine IP-Adresse besitzt) an alle Rechner

im Netzwerk (255.255.255.255) auf den Port 67. Der Server lauscht am angegebenen

Interface auf eingehende IP-Pakete. Empfängt er ein solches Paket, antwortet er anhand

seiner dhcpd.conf mit einem die IP-Adresse beinhaltenden Ethernetpaket an den Client

(Port 68). Von nun an kann der Client mit dieser Adresse auch über IP kommunizieren.

Um dies zu demonstrieren, zunächst der Zustand des Clients dns4 vor der IP-Vergabe:

dns4:~# ifconfig

eth1 Link encap:Ethernet HWaddr FE:FD:00:00:00:04

inet6 addr: fe80::fcfd:ff:fe00:4/64 Scope:Link

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:17 errors:0 dropped:0 overruns:0 frame:0

TX packets:5 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:968 (968.0 b) TX bytes:378 (378.0 b)

Interrupt:5

Wie man sieht, besitzt dns4 noch keine IPv4-Adresse für das Device eth1. Nun werden

der Server- sowie der Clientdaemon gestartet. Verfolgen kann man den Vorgang mit

tcpdump:

IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:04, length: 548

IP 10.0.1.1.bootps > 10.0.1.4.bootpc: BOOTP/DHCP, Reply, length: 300

In der ersten Zeile sieht man, wie der Client mit der MAC-Adresse

fe:fd:00:00:00:04 eine IPv4-Adresse anfordert. Anschließend teilt der DHCP-

Server 10.0.1.1 dem Client seine neue IPv4-Adresse 10.0.1.4 mit. Ifconfig zeigt

nun, dass das Device eine Adresse erhalten hat.

11

dns4:~# ifconfig

eth1 Link encap:Ethernet HWaddr FE:FD:00:00:00:04

inet addr:10.0.1.4 Bcast:10.0.1.255 Mask:255.255.255.0

inet6 addr: fe80::fcfd:ff:fe00:4/64 Scope:Link

UP BROADCAST NOTRAILERS RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:20 errors:0 dropped:0 overruns:0 frame:0

TX packets:7 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:1918 (1.8 KiB) TX bytes:1028 (1.0 KiB)

Interrupt:5

Einen Überblick über die dynamisch vergebenen Adressen findet man auf dem Server in

der Datei /var/lib/dhcp/dhcpd.leases:

lease 10.0.1.100 {

starts 3 2006/08/16 15:40:43;

ends 3 2006/08/16 15:40:42;


uid 01:fe:fd:00:01:14:01;

clienthostname "host1";

}

An diesem Eintrag kann man beispielsweise ablesen, an welche MAC-Adresse die IP-

Adresse 10.0.1.100 vergeben wurde und wie lange sie gültig bleibt. Der Client findet

Informationen über die ihm zugeteilte Adresse in der Datei

/var/lib/dhcpc/dhcpcdeth1.info.

4.4 Aufgaben

Ins bestehende Netzwerk soll ein neuer DNS-Server eingebunden werden.

a) Erweitern Sie dazu die Simulation so, dass ein weiterer Rechner mit dem Namen

dns8 im Netzwerk Net2 gestartet wird. Da dieser Rechner als Server eine feste IP-

Adresse benötigt, denken Sie daran, ihm eine feste (eindeutige) MAC-Adresse

zuzuweisen.

b) Fügen Sie diesen neu erstellten Rechner in die DHCP-Konfiguration des Servers

dns3 ein und weisen Sie ihm damit eine IP-Adresse zu.

12

c) Ändern Sie die dhcpd.conf des Servers so ab, dass die Clients nach kurzer Zeit

eine neue IP-Adresse anfordern müssen. Verfolgen Sie den Vorgang mit tcpdump oder

ähnlichen Tools.

Lösungen:

a) Erweiterung der Datei vnuml_pp06.xml um:

<vm name="dns8">

<mem>50M</mem>


<mac>fe:fd:00:00:00:08</mac>

</if>

</vm>

b) Nach dem Starten der Simulation und des <exec>-Tags „config“

(vnumlparser.pl x config@vnuml_pp06.xml) fügt man in der Datei

/etc/dhcpd.conf auf dns3 folgenden Eintrag im subnet 10.0.2.0 hinzu:

host dns8 {


fixedaddress 10.0.2.8;


}

Um die neue Konfiguration zu lesen, muss man den DHCP-Serverdaemon neustarten.


Startet man nun auf dem Client den DHCP-Clientdaemon mittels

dns8:~# dhcpcd eth1

bezieht der neu eingerichtete Rechner die ihm zugeteilte Adresse.

c) In der dhcpd.conf auf dns3 wird die default-lease-time auf 10 Sekunden

heruntergesetzt:

defaultleasetime 10;

Der DHCP-Server muss daraufhin wieder neugestartet werden


Damit der Client sein lease auch erneuert, muss auch hier der Daemon neugestartet

werden. Dazu zunächst den Clientdaemon beenden:

13

dns8:~# killall dhcpcdbin

Dann kann er neugestartet werden:

dns8:~# dhcpcd eth1

In der Datei /var/lib/dhcpc/dhcpcdeth1.info kann man nun die neue

lease-time sehen:

dns8:~# cat /var/lib/dhcpc/dhcpcdeth1.info

(...)

LEASETIME=10

RENEWALTIME=5

(...)

Nach Ablauf der RENEWALTIME fordert der Client eine neue Adresse an. Tcpdump

macht dies ersichtlich:

16:41:05.604618 IP 10.0.2.8.bootpc > 10.0.2.1.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:08, length: 548

16:41:05.607089 IP 10.0.2.1.bootps > 10.0.2.8.bootpc: BOOTP/DHCP, Reply, length: 300





Anmerkungen:

Die Simulation ist auf drei physikalisch getrennte Netze verteilt, zwischen denen über

Router vermittelt wird. Damit der neu erstellte Rechner auch mit den anderen beiden

Netzen kommunizieren kann, muss seine Routingtabelle angepasst werden. Der

folgende Befehl setzt als Standardgateway den Router2:

dns8:~# route add default gw 10.0.2.20 eth1

Außerdem muss die Option rp_filter abgeschaltet werden:

dns8:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo \

0 > $f; done

Mehr dazu in Abschnitt 6 Routing.

14

5 Einrichtung von DNS

5.1 Installation des DNS-Servers BIND

Im benutzten Dateisystem war der DNS-Server BIND bereits installiert. Dieser war in

UML aufgrund eines Segmentation Faults nicht lauffähig, daher haben wir ihn durch die

vom Quellcode kompilierte Version 9.3.2 ersetzt.

5.2 Entworfene DNS-Hierarchie

Der Root-Nameserver der Hierarchie ist dns1, er verwaltet die Domain vnuml. Alle

Rechner auf dieser Ebene des Baumes liegen im IP-Netz 10.0.0.0/24. Darunter befinden

sich zwei Subdomains site1., verwaltet von dns2, und site2., verwaltet von dns3 mit den

IP-Netzen 10.0.1.0/24 beziehungsweise 10.0.2.0/24. Unter diesen beiden gibt es jeweils

noch zwei weitere Subdomains dept11. (dns4) und dept12. (dns5), sowie dept21. (dns6)

und dept22. (dns7), die jedoch keine eigenen IP-Netze besitzen.

5.3 Konfiguration der DNS-Server

Die Konfigurationsdateien des DNS-Servers BIND liegen im Verzeichnis

/etc/bind. Die einzelnen Zonen, die der Nameserver verwalten soll, werden in

sogenannten Zonendateien abgelegt. Sie werden in Debian nach der Konvention

db.zonenname benannt. Zur Erklärung des Aufbaus dieser Dateien folgen als

Beispiel Ausschnitte aus der Zonendatei db.vnuml des Nameservers dns1.

15

; Domain .vnuml

$TTL 300

vnuml. IN SOA dns1.vnuml. root.dns1.vnuml. (

1 ; serial

3600 ; refresh (1hour)

1800 ; retry (30 min)

604800 ; expire (7 days)

3600 ; minimum (1 hour)

)

vnuml. IN NS dns1.vnuml.

dns1.vnuml. IN A 10.0.0.1

Mit einem Semikolon gekennzeichnete Zeilen bezeichnen Kommentare. Die Direktive

$TTL gibt die standardmäßige Time-To-Live für alle folgenden Einträge in Sekunden

an. Darauf folgt der erste Zoneneintrag. IN gibt an, dass das Internetprotokoll verwendet

wird. Für die Zone vnuml. ist dns1.vnuml der primary nameserver, dies wird durch die

Angabe von SOA (Start Of Authority) festgelegt. Außerdem wird hier die Email-

Adresse des zuständigen Administrators angegeben. Diese ist hier [email protected],

der erste Punkt ist folglich durch ein @ zu ersetzen. In der Klammer steht hier zunächst

die Seriennummer der Zonendatei, gefolgt von den verschiedenen TTLs. Im nächsten

Eintrag gibt man nun alle autoritativen Nameserver (NS) der Zone an, in unserem

Beispiel lediglich dns1.vnuml. Damit der Name dns1.vnuml bereits aufgelöst werden

kann, muss hier eine Adresszuordnung stattfinden, welche über den A-Resource Record

geschieht. Der Name dns1.vnuml wird also in die IP-Adresse 10.0.0.1 übersetzt.

; Host entries

wwwftp.vnuml. IN A 10.0.0.2

www.vnuml. IN CNAME wwwftp

ftp.vnuml. IN CNAME wwwftp

nisnfs.vnuml. IN A 10.0.0.3

nis.vnuml. IN CNAME nisnfs

nfs.vnuml. IN CNAME nisnfs

Nun folgen die Einträge für die Umsetzung der Hostnamen der Zone in IP-Adressen.

Beispielsweise erhält www-ftp.vnuml die IP-Adresse 10.0.0.2. Außerdem werden für

www-ftp.vnuml die Aliasnamen www.vnuml und ftp.vnuml mit Hilfe des Resource

Records CNAME eingerichtet.

; Delegation of zone site1

site1.vnuml. IN NS dns2.site1.vnuml.

16

dns2.site1.vnuml. IN A 10.0.1.1

; Delegation of zone site2

site2.vnuml. IN NS dns3.site2.vnuml.

dns3.site2.vnuml. IN A 10.0.2.1

Anfragen an Subdomains site1.vnuml und site2.vnuml werden hier an die

entsprechenden Server delegiert. So leitet dieser Server zum Beispiel alle Anfragen an

die Domain site1.vnuml an den Nameserver dns2.site1.vnuml weiter. Natürlich muss

hier auch die IP-Adresse von dns2.site1.vnuml angegeben werden, weil sein Name sonst

nicht bekannt ist.

Eingebunden werden diese zonefiles über die Datei /etc/bind/named.conf.

Unter Debian stehen in dieser Datei einige Standardeinträge, Ergänzungen sollten in die

Datei /etc/bind/named.conf.local geschrieben werden, welche in

named.conf eingebunden wird. named.conf.local von dns1:

zone "vnuml." {

type master;

file "/etc/bind/db.vnuml";

};

zone "10.inaddr.arpa." {

type master;

file "/etc/bind/db.10";

};

Wie man sieht wird zunächst die Zone angegeben, anschließend der Typ des Servers für

diese Zone (master oder slave) und die Datei, in der die Zone spezifiziert wird. Die

untere Zone 10.in-addr.arpa wird benötigt für den Reverse Lookup, also die

Übersetzung von IP-Adressen in DNS-Namen.

Damit der Nameserver nicht auf dem Managementinterface von VNUML (eth0) auf

Anfragen wartet, müssen in der /etc/bind/named.conf.options noch die

Devices angegeben werden, auf denen der Server auf Anfragen reagieren soll.

options {

(...)

listenon { 10.0.0.1; 127.0.0.1; };

listenonv6 { none; };

(...)

};

17

Um das Programm rndc zur Verwaltung des Nameserver-Daemons named verwenden

zu können, muss man es konfigurieren. Dazu wird die Datei

/etc/bind/rndc.conf mit folgendem Inhalt erstellt:

key "rndckey" {

algorithm hmacmd5;

secret "99XD4Hi7WX7GTwE7kfRTJw==";

};

options {

defaultserver localhost;

defaultkey "rndckey";

};

Die Datei /etc/bind/rndc.key sollte standardmäßig im Dateisystem vorhanden

sein, falls nicht, muss sie für dieses Beispiel folgendes enthalten:

key "rndckey" {

algorithm hmacmd5;

secret "99XD4Hi7WX7GTwE7kfRTJw==";

};

Weiterhin bedarf die Datei named.conf.options dieser Ergänzung:

controls {

inet 127.0.0.1 allow { localhost; } keys { rndckey; };

};

include "/etc/bind/rndc.key";

Jetzt sollte sich rndc mit

dns1:~# rndc c /etc/bind/rndc.conf Befehl

benutzen lassen. Eine Übersicht der Befehle erhält man durch Starten von rndc ohne

weitere Parameter. Ausgaben, wie beispielsweise ein Cachedump, werden in

/var/cache/bind (wie in named.conf.options über directory definiert)

abgelegt.

Zum Starten des Servers muss zunächst noch in der Datei /etc/default/bind9

folgende Option eingetragen werden:

OPTIONS="u bind c /etc/bind/named.conf"

Dann lässt sich der Server durch

dns1:~# /etc/init.d/bind9 start

starten.

18

Auf Clientseite genügt es zur Konfiguration von DNS, in die Datei

/etc/resolv.conf einen erreichbaren Nameserver einzutragen. Diese Aufgabe

wird jedoch in unserem Szenario bereits vom DHCP-Server übernommen.

5.4 DNS-Anfragen

Zur Auflösung der DNS-Namen von Hand, dient das Tool dig. Um zum Beispiel auf

Server dns4 den Namen dns6.dept21.site2.vnuml aufzulösen, startet man einfach dig

mit

dns4:~# dig dns6.dept21.site2.vnuml

Als Antwort erhält man:

; <<>> DiG 9.3.2 <<>> dns6.dept21.site2.vnuml

;; global options: printcmd

;; Got answer:

;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 2828

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;dns6.dept21.site2.vnuml. IN A

;; ANSWER SECTION:

dns6.dept21.site2.vnuml. 300 IN A 10.0.2.6

;; AUTHORITY SECTION:

dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.

;; Query time: 95 msec

;; SERVER: 10.0.1.4#53(10.0.1.4)

;; WHEN: Thu Aug 17 17:13:04 2006

;; MSG SIZE rcvd: 71

In der Question Section wird zunächst unsere Anfrage wiederholt. In der Answer

Section erhält man dann die gesuchte IP-Adresse. Weiterhin schickt der Server noch

zusätzliche Angaben über zuständige Nameserver mit, damit diese beim nächsten Mal

direkt befragt werden können.

Den ganzen Vorgang der rekursiven Namensauflösung kann man mit tcpdump

beobachten:

19

17:13:04.223969 IP 10.0.1.4.1024 > 10.0.0.1.53: 14235 [1au] A? dns6.dept21.site2.vnuml. (52)

17:13:04.225192 IP 10.0.0.1.53 > 10.0.1.4.1024: 14235 0/1/2(87)

Als erstes sieht man hier, dass der Server dns4 den Root-Nameserver dns1 (10.0.0.1)

befragt, da er über die gesuchte Zone dept21.site2.vnuml keine Informationen besitzt. In

der Antwort teilt dns1 dem anfragenden Server dns4 dann mit, dass er selbst auch keine

Informationen zu dem gesuchten Host besitzt, aber Auskunft über die Zone site2.vnuml

geben kann. Für diese Zone ist der Server dns3 (10.0.2.1) autoritativ, demnach befragt

dns4 diesen als nächstes:


17:13:04.266820 IP 10.0.2.1.53 > 10.0.1.4.1024: 62416 0/1/2(82)

Als Antwort erhält dns4 wiederum einen Verweis auf dns6 (10.0.2.6), der für die Zone

dept21.site2.vnuml verantwortlich ist. Schließlich kann dns4 diesen befragen und erhält

die gesuchte IP-Adresse von dns6:


17:13:04.280183 IP 10.0.2.6.53 > 10.0.1.4.1024: 31208* 1/1/1 A[|domain]

Auch Reverse Lookups lassen sich mit dig durchführen:

dns4:~# dig x 10.0.1.1

Die Antwort darauf lautet:

; <<>> DiG 9.3.2 <<>> x 10.0.1.1


;; Got answer:

;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 58099

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:

;1.1.0.10.inaddr.arpa. IN PTR

;; ANSWER SECTION:

1.1.0.10.inaddr.arpa. 3600 IN PTR dns2.site1.vnuml.


1.0.10.inaddr.arpa. 3600 IN NS dns2.site1.vnuml.

20

;; ADDITIONAL SECTION:

dns2.site1.vnuml. 300 IN A 10.0.1.1

;; Query time: 45 msec

;; SERVER: 10.0.1.4#53(10.0.1.4)

;; WHEN: Thu Aug 17 17:24:06 2006

;; MSG SIZE rcvd: 99

5.5 Aufgaben

Die folgenden Aufgaben bauen auf die Lösungen aus 4.4 auf. Der neu eingerichtete

Server dns8 soll hier DNS-Aufgaben übernehmen (notfalls können die Aufgaben auch

auf dns6 oder dns7 bearbeitet werden).

a) Dns8 soll die neue Zone dept23.site2.vnuml verwalten. Dazu muss zunächst named

entsprechend konfiguriert werden (bei Verwendung von dns6 und dns7 bereits erfolgt).

Folgende Dateien können beispielsweise von dns3 übernommen werden, da sie

Standardeinstellungen beinhalten:

db.0

db.127

db.255

db.empty

db.local

db.root

named.conf

rndc.conf

rndc.key

Die Datei named.conf.options kann auch übernommen werden, jedoch muss hier

die IP-Adresse im Eintrag listenon an die entsprechende von dns8 angepasst

werden.

Erstellen Sie die Zonendatei db.dept23.site2.vnuml für die Zone

dept23.site2.vnuml mit dns8 als primary nameserver. Integrieren Sie die Zonendatei

anschließend über die zu erstellende Datei named.conf.local in die Konfiguration

von dns8. Denken Sie daran, dass dns3 auch über die neue Zone in Kenntnis gesetzt

werden muss. Starten Sie den named auf dns8 und überprüfen Sie die Funktionalität der

neuen Zone.

21

b) Tragen Sie Adresszuweisungen für zwei beliebige Hosts in dieser Zone in die

Zonendatenbank von dns8 ein (diese müssen nicht existieren). Stellen Sie Anfragen

nach diesen neuen Einträgen.

c) Dns8 soll nun als secondary nameserver für die Zone site2.vnuml dienen. Tragen Sie

dazu dns8.dept23.site2.vnuml als Nameserver für die Zone site2.vnuml in die Zonefiles

der Server dns1 und dns3 ein. Auf dns3 muss zusätzlich noch die Option notify

yes; in der Datei named.conf.options gesetzt werden, damit dieser

Aktualisierungen seiner Datenbank an Slaves mitteilt. Beim Eintrag der Zone in die

named.conf.local des Clients ist zu beachten, dass hier der type auf slave

gesetzt werden muss und mittels masters {10.0.2.1;}; und allownotify

{10.0.2.1;}; der Masterserver, von dem die Zonendateien bezogen werden,

angegeben wird. Diese vom Master bezogenen Dateien werden auf dem secondary

nameserver im Verzeichnis /var/cache/bind abgelegt, daher reicht es einen

Zonendateinamen ohne Pfad anzugeben.

Lösungen:

a) Die zu erstellende Zonendatei sollte so aussehen:

; db.dept23.site2.vnuml

$TTL 300

dept23.site2.vnuml. IN SOA dns8.dept23.site2.vnuml. root.dns8.dept23.site2.vnuml. (

1 ; serial

3600 ; refresh

1800 ; retry

604800 ; expire

3600 ; minimum

)

dept23.site2.vnuml. IN NS dns8.dept23.site2.vnuml.

dns8.dept23.site2.vnuml. IN A 10.0.2.8

Auf dns3 muss die Datei db.site.vnuml ergänzt werden:

(...)

; Delegation of zone dept23

dept23.site2.vnuml. IN NS dns8.dept23.site2.vnuml.


22

Um die Änderungen in dieser Datei zu übernehmen, gibt es zwei Möglichkeiten.

Entweder der named wird neugestartet oder man benutzt rndc:

dns3:/etc/bind# rndc c /etc/bind/rndc.conf reload

server reload successful

Zur Einbindung der Zonefiles auf dns8 wird die Datei

/etc/bind/named.conf.local angelegt:

// named.conf.local auf dns8

zone "dept23.site2.vnuml." {

type master;

file "/etc/bind/db.dept23.site2.vnuml";

};

Der Serverdaemon named kann nun gestartet werden:

dns8:/etc/bind# /etc/init.d/bind9 start

Zum Testen der neuen Zone genügt es, von einem beliebigen Rechner mit dig eine

Anfrage danach zu stellen.

dns3:/etc/bind# dig dns8.dept23.site2.vnuml

Antwort (gekürzt):

;; ANSWER SECTION:




b) In der neu erstellten Zone werden die Hosts www und mail eingetragen. Die Datei

db.dept23.site2.vnuml wird daher um

; host entries

www.dept23.site2.vnuml. IN A 10.0.2.50

mail.dept23.site2.vnuml. IN A 10.0.2.51

ergänzt. Zum Übernehmen der Änderungen, muss auch hier die Zone neu geladen

werden:



Das Testen erfolgt wiederum mit dig.

dns8:/etc/bind# dig mail.dept23.site2.vnuml

23

;; ANSWER SECTION:

mail.dept23.site2.vnuml. 300 IN A 10.0.2.51



;; ADDITIONAL SECTION:


c) Die Zonendatei db.site2.vnuml auf dns3 muss folgendermaßen ergänzt werden:

site2.vnuml. IN NS dns8.dept23.site2.vnuml.

Auf dns1 wird im Abschnitt „Delegation of site2.vnuml“ in der Datei db.vnuml der

Nameserver dns8 als secondary nameserver hinzugefügt.

site2.vnuml. IN NS dns8.dept23.site2.vnuml.


Die Adresszuweisung für dns8.dept23.site2.vnuml muss hier zusätzlich noch

stattfinden, da dns1 die IP von dns8 noch nicht bekannt ist. Auf dns3 ist dieser Eintrag

bereits vorhanden.

Auf dns3 in named.conf.options wird wie bereits erwähnt die Option notify

gesetzt:

options {

(...)

notify yes;

(...)

}

Dns8 erhält in der named.conf.local einen neuen Zoneneintrag:

zone "site2.vnuml." {

type slave;

file "db.site2.vnuml";

masters {10.0.2.1;};

allownotify {10.0.2.1;};

};

Um die Änderungen anzuwenden müssen wiederholt die Konfigurationen neu geladen

werden.



24



Überprüft man nun den Inhalt von /var/cache/bind, wird man feststellen, dass

hier die neue Datei db.site2.vnuml liegt, welche über Zonentransfer angelegt

wurde.

Demonstration des Ausfalls des primary nameservers dns3:

Solange dns3 läuft beantwortet er alle Anfragen an die Zone site2.vnuml. Führt man dig

mit der Option +trace aus, wird die Delegation der Zonen ersichtlich.

dns1:/etc/bind# dig +trace dns6.dept21.site2.vnuml

; <<>> DiG 9.3.2 <<>> +trace dns6.dept21.site2.vnuml


. 999999 IN NS dns1.vnuml.

;; Received 56 bytes from 127.0.0.1#53(127.0.0.1) in 6 ms

site2.vnuml. 300 IN NS dns3.site2.vnuml.

site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.

;; Received 118 bytes from 10.0.0.1#53(dns1.vnuml) in 1 ms


;; Received 71 bytes from 10.0.2.1#53(dns3.site2.vnuml) in 4 ms



;; Received 71 bytes from 10.0.2.6#53(dns6.dept21.site2.vnuml)

in 4 ms

Dns1 verweist hier für die Zone site2.vnuml auf die Server dns3.site2.vnuml und

dns8.dept23.site2.vnuml. Als nächstes wird dns3 befragt (siehe hervorgehobener Text),

da er an erster Stelle steht. Testweise fahren wir nun den named auf dns3 herunter.

dns3:/etc/bind# killall named

Jetzt ergibt dig:

dns1:/etc/bind# dig +trace dns6.dept21.site2.vnuml

; <<>> DiG 9.3.2 <<>> +trace dns6.dept21.site2.vnuml


. 999999 IN NS dns1.vnuml.

;; Received 56 bytes from 127.0.0.1#53(127.0.0.1) in 7 ms

site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.

25

site2.vnuml. 300 IN NS dns3.site2.vnuml.

;; Received 118 bytes from 10.0.0.1#53(dns1.vnuml) in 2 ms


;; Received 71 bytes from 10.0.2.8#53(dns8.dept23.site2.vnuml) in 4 ms



;; Received 71 bytes from 10.0.2.6#53(dns6.dept21.site2.vnuml)

in 4 ms

Hier wird dns3 zwar noch erwähnt, da er in der Datenbank von dns1 steht, jedoch ist er

nicht erreichbar, so dass dns8 alle Anfragen an die Zone site2.vnuml beantwortet.

6 Routing

6.1 Installation und Konfiguration von Zebra

Zebra ist eine Routingsoftware, die die Protokolle BGP-4, RIPv1, RIPv2 und OSPFv2

unterstützt. Zebra ist modular aufgebaut, wir benutzen hier nur RIPv2. Die benötigten

Pakete sind in unserer Debian-Distribution bereits vorinstalliert. Zur Konfiguration

dienen die Dateien /etc/zebra/zebra.conf und /etc/zebra/ripd.conf.

Für unsere Konfiguration kann die zebra.conf bei den Standardeinstellungen

belassen werden. Lediglich in der ripd.conf setzen wir mit der password-Option

das Passwort „zebra“ für den RIP-Daemon, indem wir den Kommentar aus der

entsprechenden Zeile entfernen. Jetzt muss nur noch die network-Option an unser

Netz angepasst werden:

network 10.0.0.0/8

Diese Einstellungen sind für alle drei Router gleich.

Auf den Clients muss ein erreichbarer Router als Standardgateway in der Routingtabelle

eingetragen werden, um alle physikalischen Netze zu erreichen. Für die Rechner aus

Net0 ist dies der router0, für Net1 der router1 und für Net2 der router2. Das setzen

dieser Gateways geschieht bei uns automatisch über das <exec>-Tag „config“ in dem

auf den virtuellen Maschinen der Befehl route entsprechend ausgeführt wird.

Beispiel für host0:

host0:~# route add default gw 10.0.0.10 eth1

26

Außerdem muss auf den Clients der rp_filter abgeschaltet werden. Er dient der

Überprüfung, ob ankommende Pakete aus dem gleichen Netz kommen, aus dem sie

angefordert wurden. Beim Routing kann es vorkommen, dass Antwortpakete eine

andere Route nehmen, als die Anfragepakete. Um zu verhindern, dass diese Pakete

durch den rp_filter verworfen werden, schalten wir den rp_filter für sämtliche

Netzwerkgeräte mit folgendem Befehl ab:

host0:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do \

echo 0 > $f; done

Auch dieser Befehl wird bereits automatisch über das <exec>-Tag „config“

ausgeführt.

Um den Routingdaemon zu starten, führt man zunächst zebra aus:

router0:~# zebra f /etc/zebra/zebra.conf u root d

Dann wird der RIP-Daemon gestartet:

router0:~# ripd f /etc/zebra/ripd.conf u root d

6.2 Aufbau der Routingtabellen

Als erklärendes Beispiel verwenden wir hier den Router router0. Zunächst läuft der

RIP-Daemon auf ihm noch nicht. Die Routingtabelle sieht dann folgendermaßen aus:

router0:~# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.1.176 * 255.255.255.252 U 0 0 0 eth0

10.0.0.0 * 255.255.255.0 U 0 0 0 eth1

10.0.1.0 * 255.255.255.0 U 0 0 0 eth2

Durch seine zwei Interfaces hat router0 direkte Verbindungen in die Netze Net0

(10.0.0.0) und Net1 (10.0.1.0). Dann wird der RIP-Daemon gestartet. Nach kurzer Zeit

haben die Router unter sich ihre Routinginformationen ausgetauscht, so dass auf router0

diese Routingtabelle entsteht:

router0:~# route



192.168.1.176 * 255.255.255.252 U 0 0 0 eth0

10.0.0.0 * 255.255.255.0 U 0 0 0 eth1

10.0.1.0 * 255.255.255.0 U 0 0 0 eth2

10.0.2.0 10.0.1.12 255.255.255.0 UG 2 0 0 eth2

27

Jetzt kann router0 auch Pakete in Net2 (10.0.2.0) über den Router router1 (10.0.1.12)

weiterleiten. Alternativ kann man sich Informationen über die RIP-Tabelle auch via

Telnet anzeigen lassen. Dazu loggt man sich auf dem Router auf Port 2602 mittels des

in der ripd.conf eingestellten Passworts ein.

router0:~# telnet localhost 2602

(...)

ripd> show ip rip

Codes: R RIP, C connected, S Static, O OSPF, B BGP

Subcodes:

(n) normal, (s) static, (d) default, (r) redistribute,

(i) interface

Network Next Hop Metric From Tag Time

C(i) 10.0.0.0/24 0.0.0.0 1 self 0

C(i) 10.0.1.0/24 0.0.0.0 1 self 0

R(n) 10.0.2.0/24 10.0.1.12 2 10.0.1.12 0 02:44

Über tcpdump kann man den RIP-Nachrichtenaustausch beobachten.

16:51:48.455754 IP 10.0.0.10.route > 224.0.0.9.route: RIPv2, Request, length: 24

16:51:48.484247 IP 10.0.0.20.route > 10.0.0.10.route: RIPv2, Response, length: 44

16:51:49.412548 IP 10.0.0.10.route > 224.0.0.9.route: RIPv2, Response, length: 44

16:52:12.934056 IP 10.0.0.20.route > 224.0.0.9.route: RIPv2,

Response, length: 44

Viele RIP-Pakete werden an die Adresse 224.0.0.9 geschickt. Diese Adresse gilt für RIP

als Multicastadresse, das heißt, alle Router, auf denen RIP läuft, empfangen diese

Pakete. Nach dem Request von 10.0.0.10 (router0) sendet 10.0.0.20 (router2) die ihm

bekannten Routinginformationen in einer Response an router0. Danach multicasten

diese beiden Router die ihnen bekannten Daten regelmäßig im Netzwerk.

6.3 Aufgabe

Simulieren Sie den Ausfall des Routers router1 und beobachten Sie den Vorgang

beispielsweise mit Hilfe der Routingtabellen oder tcpdump.

Lösung:

Durch den Ausfall von router1 muss router2 eine neue Route zu Net1 aufbauen. Solange

router1 aktiv ist, sieht die Routingtabelle von router2 so aus:

28

router2:~# route



192.168.1.184 * 255.255.255.252 U 0 0 0 eth0

10.0.0.0 * 255.255.255.0 U 0 0 0 eth1

10.0.1.0 10.0.2.12 255.255.255.0 UG 2 0 0 eth2

10.0.2.0 * 255.255.255.0 U 0 0 0 eth2

Um den Ausfall zu demonstrieren, beenden wir den RIP-Daemon.

router1:~# killall ripd

router1:~# killall zebra

Nach kurzer Zeit haben die Router die neue Situation untereinander ausgetauscht. Auf

router0 ändert sich dabei nichts, da er eine direkte Verbindung ins Netz Net1 besitzt.

Router2 muss jetzt jedoch Pakete an Net1 über router0 weiterleiten, so dass sich seine

Routingtabelle folgendermaßen ändert:

router2:~# route



192.168.1.184 * 255.255.255.252 U 0 0 0 eth0

10.0.0.0 * 255.255.255.0 U 0 0 0 eth1

10.0.1.0 10.0.0.10 255.255.255.0 UG 2 0 0 eth1

10.0.2.0 * 255.255.255.0 U 0 0 0 eth2

Da hier das Thema Routing nur kurz abgehandelt wurde, verweisen wir für weitere

Informationen auf [9].

29

7 Literaturverzeichnis

[1] User Mode Linux Homepage

http://user-mode-linux.sourceforge.net/shared_fs.html

http://user-mode-linux.sourceforge.net/resize.html

[2] Seminararbeit: Eigener Kernel und eigenes Dateisystem für User-Mode-Linux,

Matthias Korn

http://www.uni-koblenz.de/~vnuml/docs/vnuml/kernel_fs.pdf

[3] Manpages zu apt-get

[4] VNUML 1.5-Reference

http://jungla.dit.upm.es/~vnuml/doc/1.5/reference/index.html

[5] Manpages zu dhcpd und dhcpcd

[6] BIND 9 Administrator Reference Manual

http://www.isc.org/index.pl?/sw/bind/arm93/

[7] Seminararbeit: Domain Name System in VNUML, Rufus Linke

http://www.uni-koblenz.de/~vnuml/docs/dns/dns.pdf

[8] Zebra Documentation

http://www.zebra.org/zebra/index.html

[9] Projektpraktikum Routing-Simulation SS05: RIP-Konfiguration mittels

VNUML-Simulator, Christian Perscheid

http://www.uni-koblenz.de/~vnuml/docs/rip/RIP-Konfiguration.pdf

30

cow-dateisystem und softwareinstallation einrichtung von...

Documents