IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Unix - Solaris-Spezielles - Routing mit Solaris 2.6



Routing mit Solaris 2.6

Erklärt wird der Aufbau der Routingtabelle und der Bearbeitung mit route-Befehlen, Gateways, Standardrouter, VLSM und CIDR.


Autor: Jochen Berner (jberner)
Datum: 30-05-2002, 13:05:54
Referenzen: http://www.enteract.com/~lspitz/routing.html (der englische Originaltext)
Schwierigkeit: Fortgeschrittene
Ansichten: 6745x
Rating: 8 (1x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Routing mit Solaris

Dieser Artikel ist der zweite aus einer zweiteiligen Serie. Im ersten Teil (http://www.enteract.com/~lspitz/interfaces.html) habe ich erläutert, wie man Netzwerkkarten konfiguriert, verändert und auf Fehlersuche geht. Dieser Teil wird sich mit Routingeigenschaften von Systemen mit zwei oder mehr Netzwerkkarten beschäftigen. Ich werde weder gated noch irgendwelche Routingprotokolle wie RIP oder OSPF behandeln. Dieser Artikel wird sich lediglich auf die Implementierung von statischen Routingtabellen konzentrieren. Im Laufe dieses Artikels werde ich die Oktett-Notation für Subnetzmasken verwenden, nicht die modernere Variante per /. Beispiel: ich werde ein Class-C Netzwerk mit 255.255.255.0 angeben, nicht als /24. Ich habe mich dazu entschieden, die ältere Notation zu verwenden, da Solaris sie benutzt. Bei Fragen zur IP-Adressierung oder zum Subnetting empfehle ich, zuerst dies hier zu lesen http://www.ralphb.net/IPSubnet

Routing

Routing hat mich immer fasziniert. Es ist verblüffend, wie ein System weiß, wohin es ein Paket weiterleiten soll. In diesem Artikel werde ich erlären, wie Solaris genau das weiß: wohin Pakete weiterzuleiten sind. Im ersten Teil werde ich einige grundlegende statische Routen erklären und einrichten. Im zweiten Teil behandele ich dann einige fortgeschrittene Fähigkeiten von Solaris 2.6, speziell VLSM (Variable Length Subnet Masks = Subnetzmasken mit variabler Länge).

Routing nennt man den Vorgang des Weiterleitens eines Paketes von A nach B. Solaris macht das indem es eine Routingtabelle aufbaut. Wenn es ein Paket weiterleitet, schaut es in diese Tabelle um herauszufinden wohin das Paket geschickt werden muss. Der Schlüssel zum erfolgreichen routen mit Solaris ist eine korrekte Routingtabelle. Man fängt beim Aufbau mit dem eigenen ersten Netzwerkdevice an.

Nehmen wir zum Beispiel an, man hätte ein System mit einer Schnittstelle, elx0. Diesem weist man die Adresse 207.229.165.133 mit der Subnetzmaske 255.255.255.0 zu. Um die Routingtabelle zu sehen, die der Kernel erzeugt hat, verwendet man das Kommando netstat -nr

Routing Table:
Destination Gateway Flags Ref Use Interface
----------------- -------------------- ----- ----- ------ ---------
207.229.165.0 207.229.165.133 U 1 20 elx0
127.0.0.1 127.0.0.1 UH 0 94 lo0

Hier sehen wir die Routingtabelle. Die erste Spalte "Destination" sagt aus, zu welchem Netzwerk das Paket gehen möchte. Die zweite Spalte "Gateway" bezeichnet die IP-Adresse an die sich das Paket wenden muss, um zum Ziel zu gelangen (next hop). Die dritte Spalte "Flags" enthält Informationen über die Schnittstelle, wie z.B. U für UP oder G für GATEWAY. Die vierte Spalte "Ref" sagt aus, wie oft diese MAC-Adresse in der Routingtabelle referenziert wird. Die fünfte Spalte ist "Use" und sagt wie viele Pakete über diese Schnittstelle gegangen sind. Die letzte Spalte "Interface" zeigt das Device an, das ein Paket nehmen muss, wenn das Ziel das lokale Netzwerk ist.

In dem obigen Beispiel haben wir zwei Routen. Die untere, 127.0.0.1, ist die Standard-Loopback Route. Alle Systeme haben Sie, der Kernel verwendet Sie um mit sich selber zu sprechen. Der obere Eintrag ist das Ergebnis der elx0 Schnittstelle. Dieser Eintrag besagt: wenn Du zu einem Knoten im Netzwerk 207.229.165.0 möchtest, wende Dich an 207.229.165.133, der Schnittstelle dieses Systems. Der Eintrag heißt "Lokales Netzwerk" und wird standardmäßig eingetragen. Der Kernel hat angenommen, das elx0 aufgrund seiner IP-Adresse 207.229.165.133 und der Subnetzmaske 255.255.255.0 an das Netzwerk 207.229.165.0 angeschlossen ist. Somit weiß der Kernel genau, wohin Pakete weitergeleitet werden müssen, wenn man einen Knoten im 207.229.165.0 Netzwerk erreichen will.

Jedesmal wenn man eine neue Schnittstelle hinzufügt, erzeugt der Kernel einen Eintrag ähnlich zu dem obigen. Er nimmt an, dass die neue Schnittstelle mit dem lokalen Netzwerk "reden" kann. Unser System kann nun mit dem lokalen Netz 207.229.165.0 "reden". Aber wie sieht es mit anderen Netzen, wie dem Internet aus? Wenn man versucht mit irgendeinem Knoten in irgendeinem anderen Netz, wie z.B. 206.54.252.8 zu "reden", würde man folgenden Fehler bekommen:

lisa #ping 206.54.252.8
ICMP Net Unreachable from gateway lisa (207.229.165.133)
for icmp from lisa (207.229.165.133)

Das System hat keine Ahnung wie es diesen Knoten erreichen soll. Um das zu beheben müssen wir dem System eine Standardroute geben, die der Kernel benutzen soll, wenn er die Zieladresse nicht kennt. Diese Standardroute ist normalerweise die IP-Adresse eines anderen Routers. Dieser Router nimmt das Paket und macht eines von zwei Dingen mit ihm. Kennt der Router die Adresse, leitet er das Paket dorthin weiter. Falls nicht, sendet er das Paket weiter "stromaufwärts" zu einem anderen Router. Dieser Prozess wiederholt sich solange, bis das Paket sein Ziel erreicht hat.

Standardmäßig nutzt Solaris ein Routingprotokoll um die Standardroute dynamisch zu bestimmen, RIP oder Route Discovery. Während des init-Prozesses versucht /etc/rc2.d/S69inet per Route Discovery (/usr/sbin/in.rdisc) einen Router zu finden. Wenn das nach drei Versuchen fehlschlägt, startet das Skript /usr/bin/in.routed, auch bekannt als RIP. Wir werden keine von beiden Methoden verwenden. Stattdessen werden wir die Standardroute manuell setzen. Geht man so vor, so wird kein Routingprotokoll gestartet. Der Vorteil hier ist ein einfacheres und sichereres System das man zu administrieren hat.

Man definiert die Standardroute in der Datei /etc/defaultrouter. Diese Datei besteht aus einem einzigen Eintrag: der Adresse des Standardrouters. Diese Datei wird während des init-Prozesses gelesen (speziell /etc/rc2.d/S69inet) und zu der Routingtabelle hinzugefügt. Für dieses System haben wir den Standardrouter als 207.229.165.1 festgelegt. Es ist die Adresse des Routers der uns mit dem Internet verbindet. Wenn das System die Zieladresse eines Paketes nicht kennt, schickt es dieses an den Standardrouter. Mit unserer Standardroute sieht die neue Routingtabelle jetzt so aus:

Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
207.229.165.0 207.229.165.133 U 2 20 elx0
default 207.229.165.1 UG 0 20
127.0.0.1 127.0.0.1 UH 0 30 lo0

Basierend auf dieser Tabelle hat das System jetzt zwei Möglichkeiten ein Paket weiterzuleiten. Ist das Ziel im Netzwerk 207.229.165.0 wird das Paket an das lokale Netz geschickt. Ist das Ziel jedoch irgendein anderes Netz, so wird das Paket an den Standardrouter 207.229.165.1 geleitet. Beachten Sie, das der Router 207.229.165.1 im lokalen Netz liegt. Liegt die Standardroute nicht im im lokalen Netzwerk, so kann der Standardrouter vom System nicht erreicht werden.

Um die Netzmasken eines Netzwerkes zu definieren braucht man die Datei /etc/netmasks. Diese Datei wird während des Bootens gelesen und beschreibt den Aufbau des Netzwerkes. Hier ein Beispiel einer /etc/netmasks Datei:

#
# The netmasks file associates Internet Protocol (IP) address
# masks with IP network numbers.
#
# network-number netmask
#
# The term network-number refers to a number obtained from the Internet Network
# Information Center. Currently this number is restricted to being a class
# A, B, or C network number. In the future we should be able to support
# arbitrary network numbers per the Classless Internet Domain Routing
# guidelines.
#
# Both the network-number and the netmasks are specified in
# "decimal dot" notation, e.g:
#
# 128.32.0.0 255.255.255.0
#
207.229.165.133 255.255.255.0
172.16.1.0 255.255.255.0
192.168.1.0 255.255.255.240

Diese Datei definiert das Netz 207.229.165.0 als ein Standard Class-C Netz. Ebenso wird das Netz 172.16.1.0 als Class-C definiert, obwohl es eigentlich ein Class-B Netz ist. Als letztes sehen wir das 192.168.1.0 Netz das in noch kleinere 16 IP Subnetze unterteilt wird. Subnetting wird später in diesem Artikel erklärt.

IP-Weiterleitung (IP Forwarding)

Bis zu diesem Punkt haben wir über Systeme mit einer Netzwerkschnittstelle (single homed systems) gesprochen. Solche Systeme haben zwei Möglichkeiten: mit dem lokalen Netz oder dem Standardrouter zu "reden". Komplizierter wird es, wenn man eine zweite Schnittstelle hinzufügt. Das System wird dadurch multi-homed (deutsche Übersetzung?) und ein potentielles Gateway. Ein multi-homed Host ist jedes System mit zwei oder mehr Schnittstellen, normalerweise in verschiedenen Netzwerken. Ein Gateway ist jedes multi-homed System, das Pakete zwischen verschiedenen Netzwerken weiterleitet (routet).

Schauen wir uns an, was passiert wenn man eine zweite Schnittstelle hinzufügt. Wir fügen also die Schnittstelle elx1 mit der IP-Adresse 10.1.6.1 und der Subnetzmaske 255.255.255.0 hinzu.

Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
207.229.165.0 207.229.165.133 U 2 20 elx0
10.1.6.0 10.1.6.1 U 1 123 elx1
default 207.229.165.1 UG 0 20
127.0.0.1 127.0.0.1 UH 0 30 lo0

Beim Betrachten der Routingtabelle fällt nur ein Unterschied auf: die Hinzufügung der Schnittstelle elx1. Ist ein Paket für irgendeinen Knoten im Netz 10.1.6.0 bestimmt wird es durch die Schnittstelle elx1 hinausgeschickt.

Es ist aber außerdem eine andere, wesentlich Wichtigere, Änderung geschehen, die man hier nicht sieht. Die IP-Weiterleitung auf dieser Maschine wurde aktiviert. IP-Weiterleitung bedeutet erst einmal nur, dass das System Pakete zwischen Netzen weiterleitet (routet). Auf der Grundlage der obigen Tabelle wird das Gateway Pakete auf eine von zwei Weisen weiterleiten. Kennt es das Ziel nicht, wird das Paket an den Standardrouter geschickt. Liegt das Ziel in einem der beiden lokalen Netzwerke, so wird das Paket direkt an das Ziel geschickt.

IP-Weiterleitung wird während des init-Prozesses durch /etc/rc2.d/S69inet gestartet. Findet das System mehr als zwei Netzwerkschnittstellen (inklusive des Loopbacks), wird die IP-Weiterleitung standardmäßig aktiviert. Das System ist nun ein Gateway.

Man kann auch ein System mit zwei oder mehr Netzwerkschnittstellen haben, das keine Pakete weiterleitet. Das kann man auf zwei verschiedene Arten erreichen. Zum einen in dem man per touch-Befehl eine Datei /etc/notrouter erzeugt. Während des init-Prozesses sucht /etc/rc2.d/S69inet nach dieser Datei. Wird sie gefunden wird die Weiterleitung durch folgendes Kommando abgeschaltet

ndd -set /dev/ip ip_forwarding 0

Man kann die Weiterleitung auch jederzeit manuell durch dieses Komanndo abschalten (das ist die zweite Möglichkeit).

ROUTE-Befehle

Der route-Befehl erlaubt es einem, die Routingtabelle manuell zu bearbeiten. Man kann damit im laufenden Betrieb Routen anlegen, löschen und ändern. Nehmen wir mal an, die Adresse des Standardrouters hätte sich geändert, aber das System kann zur Zeit nicht neu gestartet werden. Also muß die IP-Adresse der Standardroute ohne Neustart geändert werden. Dazu braucht man den route-Befehl. Die Syntax ist einfach:

lisa #route change default 207.229.165.5 1

Dieser Befehl ändert die Standardroute von 207.229.165.1 zu .5. Die Syntax ist einfach: die Netzwerkinformationen werden so eingegeben, wie sie später in der Routingtabelle erscheinen sollen. Die letzte Zahl am Ende des Befehls ist die Metrik oder wie weit (in hops) das nächste Netzwerk entfernt ist. Jeder Knoten, inklusive Router, im eigenen Netz haben einen hop von 1. Das "route add" bzw. "route delete" Kommando erlaubt es der Routingtabelle Routen hinzuzufügen bzw. von dort zu löschen. Möchte man einen route-Befehl dauerhaft machen, fügt man ihn einfach am Ende der Datei /etc/rc.2/S69inet ein. Das init-Skript führt den Befehl dann aus und aktualisiert die Routingtabelle.

VLSM

Seit Version 2.6 unterstützt Solaris VLSM (Variable Length Subnet Mask = Subnetzmasken variabler Länge). VLSM bedeutet, das ein Netzwerk variabel in kleinere Netzwerke unterteilt werden kann, wobei jedes der kleineren Netze eine andere Subnetzmaske hat. Für Sie bedeutet das, das ihr Leben deutlich einfacher wird.

Unter Solaris 2.5.1 oder früher konnte man nur ein einziges Subnetz für ein Netzwerk definieren. Wenn man, zum Beispiel, das Netz 10.1.6.0 mit einer Subnetzmaske von 255.255.255.0 definiert hatte (wie wir es getan haben), nahmen ältere Versionen von Solaris an, das jedes Netz was mit 10 beginnt, eine Subnetzmaske von 255.255.255.0 hat. Man hatte sich also selbst eingeschlossen. Man mußte also für jedes 10.0.0.0 Netzwerk, das nicht dieses Subnetz hatte manuell eine individuelle Route eintragen. Das konnte leicht in die Hunderte gehen!

VLSM nimmt so etwas nicht an, sondern gibt Flexibilität beim Einrichten der Routingtabelle. Man kann soviele Subnetze für sein Netz haben wie man will. Betrachten wir ein Beispiel. Unsere aktuelle Routingtabelle (s.o.) ist für zwei lokale Netze und eine einzige Standardroute für alles andere konfiguriert. Dieses System soll jetzt aber das Gateway für eine große Firma werden: die Firmenfirewall. Das bedeutet, das jeder Netzwerkverkehr nach drinnen oder draußen über sie fließt.

Die Firma besteht aus einem internen 10.0.0.0 Netz, das in über 100 kleinere Subnetze unterteilt ist. Jedes dieser kleineren Subnetze hat eine andere Subnetzmaske. Zum Beispiel

10.15.146.0 255.255.254.0 (510 hosts)
10.128.112.0 255.255.248.0 (2046 hosts)
10.220.160.0 255.255.240.0 (4094 hosts)

Hier sieht man die verschiedenen unerschiedlichen Netzwerke der Firma. Wir müssen nun eine Routingtabelle erstellen, die Standardverkehr in das Internet weiterleitet und gleichzeitig alles im 10.0.0.0 Netz intern routet. Nicht vergessen: unser internes Netz besteht eigentlich aus 100 kleineren 10.0.0.0 Subnetzen, die alle in unterschiedliche Subnetzmasken haben.

Zuerst müssen wir den Standardrouter finden. In unserem Fall ist das die 10.1.6.5. Dies ist die IP-Adresse des Routers im internen Netz. Beachten Sie, das der Router im lokalen Netz der Schnittstelle elx1 steht. Da wir Solaris 2.6 nutzen, welches VLSM unterstützt, brauchen wir nur einen Befehl um alle unterschiedlichen 10.0.0.0 Netze zu routen

lisa #route add net 10.0.0.0 10.1.6.5 1

Mit diesem Befehl haben wir alle Routingfragen erledigt, etwas das nur mit VLSM geht. Schauen wir uns die Routingtabelle an und sehen nach was ich meine

Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
207.229.165.0 207.229.165.133 U 2 20 elx0
10.1.6.0 10.1.6.1 U 2 123 elx1
10.0.0.0 10.1.6.5 U 0 0
default 207.229.165.1 UG 0 20
127.0.0.1 127.0.0.1 UH 0 30 lo0

Die erste Zeile legt fest, das wenn das Ziel im 207.229.165.0 Netz liegt, die Schnittstelle elx0 benutzt wird. Liegt das Ziel im 10.1.6.0 Netz, wird die Schnittstelle elx1 verwendet (zweite Zeile). Liegt das Ziel in irgendeinem 10.0.0.0 Netz AUSSER 10.1.6.0 wird das Paket an das Gateway 10.1.6.5 geschickt (dritte Zeile). Erfüllt das Ziel keines der drei obigen Kriterien, wird das Paket an das Standardgateway 207.229.165.1 (und damit in das Internet) weitergeleitet.

Vielleicht sind Sie jetzt verwirrt darüber, woher das System weiß wohin der Verkehr auf 10.1.6.0 geleitet werden soll. In der Routingtabelle finden sich zwei Einträge die passen: einen für 10.1.6.0 und einen für 10.0.0.0. Beide treffen für 10.1.6.0 zu. Das System wählt in solchen Fällen immer den spezifischeren Eintrag zuerst.

Wenn das jetzt auf einem System ohne VLSM Unterstützung einzurichten gewesen wäre, wäre das alles VIEL hässlicher geworden. Wie zuvor gesagt ist das 10.0.0.0 in variable Subnetze unterteilt. Ohne VLSM hätte man für jedes einzelne Subnetz eine statische Route manuell anlegen müssen. Täte man das nicht, nähme der Kernel an, alle 10.0.0.0 Netze wären gleich unterteilt, was zu allen möglichen interessanten Routen führt. Wie Sie sehen, ist VLSM sehr mächtig.

CIDR (Classless Inter-Domain Routing)

Ich habe mich entschieden CIDR zu behandeln, da es leicht mit VLSM zu verwechseln ist und da beide eng verwandt sind. CIDR wurde 1993 durch die RFC1519 definiert und wird zur "routing aggregation" (vielleicht Routenansammlung oder -zusammenfassung?, Anm. d. Übers.), auch bekannt als Supernetting, verwendet. Einfach gesagt heißt das, dass man mehrere Netzwerke zu einem zusammenfasst. Der Sinn dahinter ist, die Routingtabellen zu verkleinern, die anfangen ie Backbone-Router zu überlasten. Ein Beispiel für diese Technik wäre 256 Class-C Netze zu nehmen und sie als ein Einziges zu definieren, sie also zusammenzufassen. Man kann die Netze 207.229.0.0 - 207.229.255.0 mit dem Routeneintrag 207.229.0.0, Subnetzmaske 255.255.0.0 definieren.

CIDR fasst mehrere Netzwerke zusammen um das Routing zu vereinfachen. Im Vergleich dazu VLSM, das ein Netzwerk variabel in kleinere Netzwerke unterteilt (subnettet). Verwirrt? Keine Sorge, die Hälfte des Internets auch. Um mehr darüber zu lernen, empfehle ich die Lektüre von 3Coms Whitepaper über IP-Adressierung, CIDR und VLSM. Zu finden unter http://www.3com.com/nsc/501302.html

Schlußfolgerung

Der Schlüssel zu erfolgreichem Routing sind die Routingtabellen. Setzt man sie vernünftig auf, gelangen die Pakete von A nach B. VLSM ist ein Standard, der größere Flexibilität beim Erstellen einer Routingtabelle erlaubt. Merken Sie sich: Ein glückliches Gateway ist ein glückliches Netzwerk.

Downloads

Subnetzmasken und CIDR "aggregation" kann eine ziemliche Herausforderung sein. Es gibt aber für Hirntote wie mich ein großartiges kleines Tool namens IP-Calculator von Net3 Group Inc. Dieses umsonst vertriebene Windowstool ist ein großartiger Weg, seine Subnetzprobleme zu lösen. Ich empfehle es wärmstens.

http://www.enteract.com/~lspitz/ip_calculator.zip (603 KB)

Für euch UNIX-Weicheier gibt es eine UNIX Version, zu finden unter http://www.interloper.net/~dan/software

Anm. d. Übers.

Ich bin kein professioneller Übersetzer, deswegen ist es sehr wahrscheinlich, das man vieles besser hätte formulieren können. Trotzdem hoffe ich , dass sich nirgendwo grobe Sinnentstellungen oder gar Fehler eingeschlichen haben. Wenn doch, oder auch bei sonstiger Kritik oder gar Lob, kurze e-mail reicht und dann wird korrigiert.
Der Originalartikel ist hier zu finden: http://www.enteract.com/~lspitz/routing.html



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04511
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06248
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1158
Comments: 0