Im Katalog suchen

Linux - Wegweiser für Netzwerker

Online-Version

Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.


vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel



IPX-Router konfigurieren

Sie erinnern sich sicher daran, als wir kurz über die Protolle in IPX-Umgebungen sprachen, daß IPX ein “routbares” Protokoll ist und für die Propagierung der Routing-Informationen das Routing Information Protocol (RIP) verwendet wird. Die IPX-Version von RIP ist der von IP ziemlich ähnlich. Sie arbeiten im wesentlichen auf dieselbe Weise; Router verbreiten die Inhalte ihrer Routing-Tabellen in regelmäßigen Abständen, und die anderen Router “lernen” hinzu, indem sie diese Informationen abhören und in sich aufsaugen. Die Hosts brauchen nur zu wissen, wo sich ihr lokales Netzwerk befindet, und können dann über ihren lokalen Router Datagramme an beliebige Zieladressen senden. Die Verantwortung zur Übertragung und Weiterleitung dieser Datagramme bis zur nächsten Etappe liegt dann beim Router.

In einer IPX-Umgebung ist noch eine zweite Klasse von Netzwerkinformationen im Umlauf. Das Service Advertisement Protocol (SAP) überträgt Informationen, die Auskunft über die Dienste geben, die jeder Host im Netzwerk anbietet. SAP ermöglicht beispielsweise Benutzern, Listen von Datei- oder Druckerservern im Netzwerk zu erhalten. Das SAP funktioniert mittels Hosts, die Dienste anbieten, die in regelmäßigen Abständen eine Liste ihrer verfügbaren Dienste verbreiten. Die IPX-Netzwerk-Router sammeln diese Informationen und machen sie zusammen mit den Routing-Informationen im Netz bekannt. Für einen IPX-fähigen Routermüssen Sie beide Informationsarten, also RIP und SAP, propagieren.

Wie IP stellt auch IPX in Linux einen Routing-Dämon zur Verfügung, der als ipxd bezeichnet wird und für die Aufgaben zuständig ist, die mit der Verwaltung des Routings zu tun haben. Wie bei IP ist es auch hier eigentlich der Kernel, der den Transport der Datagramme zwischen IPX-Netzwerkschnittstellen übernimmt, wobei er sich dabei an eine Menge von Regeln hält, die als IPX-Routing-Tabelle bezeichnet werden. Der ipxd-Dämon hält diese Regeln immer auf dem neuesten Stand, indem er alle aktiven Netzwerkschnittstellen abhört und analysiert, wann ein Routing-Wechsel notwendig ist. ipxd antwortet aber auch auf Anfragen von Hosts in einem direkt verbundenen Netzwerk, die nach Routing-Informationen verlangen.

In manchen Distributionen liegt ipxd bereits fertig ausführbar vor. Den Quellcode erhalten Sie über anonymous FTP von http://metalab.unc.edu/ in der Datei /pub/Linux/system/filesystems/ncpfs/ipxripd-x.xx.tgz.

Für den ipxd-Dämon ist keine Konfiguration erforderlich. Sobald er gestartet wird, verwaltet er das Routing für die konfigurierten IPX-Schnittstellen automatisch. Entscheidend ist, daß Sie vorher Ihre IPX-Schnittstellen mit ipx_interface korrekt konfiguriert haben. Die automatische Erkennung mag zwar funktionieren, dennoch empfiehlt es sich für Routing, besser den Zufall aus dem Spiel zu lassen und die Schnittstellen manuell zu konfigurieren. Sie sparen sich viel Ärger, den die sonst möglicherweise auftretenden Routing-Probleme machen könnten. Alle 30 Sekunden überprüft ipxd alle lokal angebundenen IPX-Netzwerke und verwaltet sie automatisch. Dadurch können auch solche Schnittstellen verwaltet werden, die nicht immer aktiv sind, zum Beispiel PPP-Schnittstellen.

ipxd wird normalerweise beim Systemstart aus einem rc-Skript heraus gestartet:

# /usr/sbin/ipxd
Hier ist kein &-Zeichen notwendig, da ipxd automatisch als Hintergrundprozeß läuft. Der ipxd-Dämon macht sich am nützlichsten auf Maschinen, die als IPX-Router fungieren, allerdings auch auf Hosts in Segmenten, in denen viele Router präsent sind. Wenn Sie das Argument –p angeben, arbeitet ipxd passiv; er achtet auf Routing-Informationen aus dem Segment und aktualisiert die Routing-Tabellen, überträgt jedoch selbst keinerlei Routing-Informationen. Auf diese Weise kann ein Host seine Routing-Tabellen immer aktuell halten, ohne ständig nach der Route fragen zu müssen, wenn er mal einen Remote-Host kontaktieren will.

Statisches IPX-Routing mit dem ipx_route-Befehl

Es mag Situationen geben, in denen wir eine IPX-Route hart codieren möchten. Wie bei IP ist dies auch bei IPX möglich. Der Befehl ipx_route schreibt eine Route in die IPX-Routing-Tabelle hinein, so daß der ipxd-Routing-Dämon sie nicht extra zu “lernen” braucht. Die Routing-Syntax ist sehr einfach gehalten (da IPX ja keine Subnetze kennt) und sieht etwa so aus:

# ipx_route add 203a41bc 31a10103 00002a02b102
Diese Anweisung fügt eine Route zum fernen IPX-Netzwerk 203a41bc über den Router unseres lokalen Netzwerks 31a10103 mit der Knotenadresse 00002a02b102 hinzu.

Die Knotenadresse eines Routers können Sie herausfinden, indem Sie den tcpdump-Befehl mit der Option –e benutzen, um sich die Link-Level-Header und den Datenverkehr durch den Router ausgeben zu lassen. Ist der Router eine Linux-Maschine, können Sie das einfacher haben, indem Sie ifconfig benutzen.

Zum Löschen einer Route nehmen Sie ipx_route:

# ipx_route del 203a41bc

Eine Liste der aktiven Routen im Kernel können Sie der Datei /proc/net/ipx_route entnehmen. Unsere Routing-Tabelle sieht bisher so aus:

# cat ipx_route 
Network    Router_Net   Router_Node 
203A41BC   31A10103     00002a02b102 
31A10103   Directly     Connected
Die Route zum Netzwerk 31A10103 wurde bei der Konfiguration der IPX-Schnittstelle automatisch erzeugt. Jedes unserer lokalen Netzwerke wird durch einen solchen Eintrag in der Datei /proc/net/ipx_route repräsentiert. Wenn unsere Maschine als Router arbeiten soll, braucht sie normalerweise mindestens noch eine weitere Schnittstelle.

Interne IPX-Netzwerke und Routing

IPX-Hosts mit mehr als einem IPX-Interface haben für jede ihrer Schnittstellen eine einheitliche Netzwerk/Knoten-Adressenkombination. Um zu solch einem Host eine Verbindung aufzubauen, können Sie jede dieser Adressenkombinationen benutzen. Wenn SAP Dienste bekanntgibt, liefert es in den Informationen über die Dienste auch immer die Adressenkombinationen mit. Für Hosts mit mehreren Schnittstellen bedeutet es, daß eine davon zur Propagierung ausgewählt werden muß; das ist die Funktion des Primary Interface Flags, worüber wir schon gesprochen haben. Das bringt aber ein Problem mit sich: Die Route zu dieser Schnittstelle muß nicht immer die optimale sein, und wenn ein Netzwerkfehler auftritt, der das Netzwerk vom Rest des Netzwerks isoliert, wird der Host unerreichbar, obwohl es noch andere mögliche Routen zu den anderen Schnittstellen gibt. Diese Routen sind allerdings auf den anderen Hosts nicht bekannt, da sie nie propagiert wurden, und der Kernel kann auch nicht wissen, daß er eigentlich nur ein anderes primäres Interface wählen bräuchte. Um solch ein Problem zu vermeiden, wurde ein spezielles Device entwickelt, das es einem IPX-Host ermöglicht, sich durch eine einzelne Routen-unabhängige Netzwerk/Knoten-Adresse zum Zweck der SAP-Propagierung bekannt zu machen. Das löst unser Problem, da diese neue Netzwerk/Knoten-Adresse über alle Host-Interfaces erreichbar und die vom SAP propagierte Adresse ist.

Das Problem und seine Lösung veranschaulicht Abbildung 15.1 anhand eines Servers, der an zwei IPX-Netzwerke angeschlossen ist. Das erste Netzwerk hat im Gegensatz zum zweiten kein internes Netzwerk. Der Host im Diagramm Abbildung 15.1 wählt eine seiner Schnittstellen als sein primäres Interface, beispielsweise 0000001a:0800000010aa. Diese Adresse wird als Dienstzugriffspunkt propagiert. Das funktioniert gut für Hosts im 0000001a-Netzwerk, aber bedeutet, daß Benutzer im 0000002c-Netzwerk durch das Netzwerk routen, um zu diesem Port zu gelangen, obwohl der Server bereits einen Port in diesem Netzwerk hat, wenn sie den Server über die SAP-Broadcasts entdeckt hätten.

Abbildung 15.1: Interne IPX-Netzwerke

Das Problem läßt sich mit einer rein softwarebasierten Lösung, die solchen Hosts mit einem virtuellen Netzwerk mit virtuellen Hostadressen ausstattet, aus der Welt schaffen. Ein solches virtuelles Netzwerk stellt man sich am besten so vor, als ob es sich innerhalb des IPX-Hosts befände. Die SAP-Information braucht dann nur noch für diese virtuelle Netzwerk/Knoten-Adressenkombination propagiert zu werden. Dieses virtuelle Netzwerk ist als ein internes Netzwerk bekannt. Wie bekommen aber die anderen Hosts mit, wie sie dieses interne Netzwerk erreichen? Remote-Hosts routen ins interne Netzwerk über die direkt am Host angeschlossenen Netzwerke. Das heißt, Sie sehen Routing-Einträge, die sich auf das interne Netzwerk von Hosts beziehen, die multiple IPX-Schnittstellen unterstützen. Diese Routen sollten immer die gerade optimale Route wählen, und sollte eine davon fehlschlagen, wird das Routing automatisch für die nächstbeste Schnittstelle und Route aktualisiert. In Abbildung 15.1 konfigurierten wir ein internes IPX-Netzwerk mit der Adresse 0x10000010 und benutzten die Hostadresse 00:00:00: 00:00:01. Diese Adresse wird unser primäres Interface und mittels SAP bekanntgegeben. Unser Routing spiegelt dieses Netzwerk so wider, als ob es über alle unsere realen Netzwerk-Ports erreichbar wäre. Die Hosts werden daher immer die beste Netzwerkroute für die Verbindungen zu unserem Server benutzen.

Um dieses interne Netzwerk zu erzeugen, benutzen Sie das Programm ipx_internal_net aus dem IPX-Tools-Paket von Greg Page. Dessen Anwendung demonstrieren wir wiederum anhand eines kleinen Beispiels:

# ipx_internal_net add 10000010 000000000001
Diese Anweisung erzeugt ein IPX-internes Netzwerk mit der Adresse 10000010 und der Knotenadresse 000000000001. Die Netzwerkadresse muß wie jede andere IPX-Netzwerkadresse in Ihrem Netzwerk eindeutig sein. Die Knotenadresse ist beliebig wählbar, da normalerweise nur ein Knoten im Netzwerk existiert. Jeder Host darf nur ein IPX-internes Netzwerk haben, und falls konfiguriert, ist das interne Netzwerk immer das primäre Netzwerk.

Um ein IPX-internes Netzwerk zu entfernen, verwenden Sie:

# ipx_internal_net del

Ein internes IPX-Netzwerk macht für Sie nur dann Sinn, wenn Ihr Host einen Dienst anbietet und mehrere IPX-Schnittstellen aktiviert hat.





vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel


Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center


O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen
Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag