Teil I Netzwerkdienste - Themen
2. Verwalten von Webcache-Servern
Teil II Zugriff auf Netzwerkdateisysteme - Themen
4. Verwalten von Netzwerkdateisystemen (Übersicht)
5. Verwaltung des Netzwerkdateisystems (Aufgaben)
6. Zugreifen auf Netzwerkdateisysteme (Referenz)
Teil III SLP (Service Location Protocol) - Themen
8. Planen und Aktivieren von SLP (Aufgaben)
9. Verwalten von SLP (Aufgaben)
Konfigurieren von SLP-Eigenschaften
Grundelemente der SLP-Konfigurationsdatei
Kommentarzeilen und Notationen
So ändern Sie Ihre SLP-Konfiguration
Modifizieren der Häufigkeit von DA-Advertisements und -Erkennungen
Beschränken von UAs und SAs auf statisch konfigurierte DAs
So beschränken Sie UAs und SAs auf statisch konfigurierte DAs
Konfigurieren der DA-Erkennung für DFÜ-Netzwerke
So konfigurieren Sie die DA-Erkennung für DFÜ-Netzwerke
Konfigurieren des DA-Takts für häufige Partitionen
So konfigurieren Sie den DA-Takt für häufige Partitionen
Verwenden verschiedener Netzwerkmedien, Topologien oder Konfigurationen
Verringern von SA-Neuregistrierungen
So reduzieren Sie SA-Neuregistrierungen
Konfigurieren der Multicast-Lebensdauereigenschaft
So konfigurieren Sie die Multicast-Lebensdauereigenschaft
So konfigurieren Sie die Paketgröße
Konfigurieren des Nur-Broadcast-Routing
So konfigurieren Sie Nur-Broadcast-Routing
Modifizieren von Zeitüberschreitungseinstellungen bei SLP-Suchanforderungen
Ändern der standardmäßigen Zeitüberschreitungseinstellungen
So ändern Sie standardmäßige Zeitüberschreitungseinstellungen
Konfigurieren der Zufallswartezeit
So konfigurieren Sie die Zufallswartezeit
Wann Bereiche zu konfigurieren sind
Überlegungen zum Konfigurieren von Bereichen
Welchem Zweck dient die Bereitstellung eines SLP-DA?
Bereitstellen von mehreren DAs für den Lastausgleich
Multihoming-Konfiguration für SLP
Wann mehrere nicht gesteuerte Netzwerkschnittstellen zu konfigurieren sind
Konfigurieren mehrerer nicht gesteuerter Netzwerkschnittstellen (Übersicht der Schritte)
Konfigurieren der net.slp.interfaces-Eigenschaft
So konfigurieren Sie die net.slp.interfaces -Eigenschaft
Proxy-Advertisement auf Multihomed-Hosts
DA-Bereitstellung und Zuweisung von Bereichsnamen
Überlegungen zum Konfigurieren von mehreren nicht gesteuerten Netzwerkschnittstellen
10. Integrieren von veralteten Services
Teil V Serielle Vernetzung - Themen
15. Solaris PPP 4.0 (Überblick)
16. PLanen einer PPP-Verbindung (Aufgaben)
17. Einrichten einer PPP-Einwahlverbindung (Aufgaben)
18. Einrichten einer PPP-Standleitungsverbindung (Aufgaben)
19. Einrichten der PPP-Authentifizierung (Aufgaben)
20. Einrichten eines PPPoE-Tunnels (Aufgaben)
21. Beheben von allgemeinen PPP-Problemen (Aufgaben)
22. Solaris PPP 4.0 (Referenz)
23. Migrieren von Asynchronous Solaris PPP zu Solaris PPP 4.0 (Aufgaben)
25. Verwalten von UUCP (Aufgaben)
Teil VI Arbeiten mit Remote-Systemen - Themen
27. Arbeiten mit Remote-Systemen (Übersicht)
28. Verwalten des FTP-Servers (Aufgaben)
29. Zugriff auf Remote-Systeme (Aufgaben)
Teil VII Überwachen von Netzwerkdiensten - Themen
Ein Multihomed-Server fungiert als Host in mehreren Teilnetzen. Der Server kann mehrere Netzwerkschnittstellenkarten haben und als Router fungieren. IP-Pakete, zu denen auch Multicast-Pakete zählen, werden über Schnittstellen weitergeleitet. In manchen Fällen wird das Routing zwischen Schnittstellen deaktiviert. In den folgenden Abschnitten wird beschrieben, wie SLP in solchen Fällen konfiguriert wird.
Wenn keine Konfiguration durchgeführt wurde, überwacht slpd die Multicast- und UDP/TCP-Unicast-Sendungen an der standardmäßigen Netzwerkschnittstelle. Wenn Unicast- und Multicast-Routing zwischen den Schnittstellen eines Multihomed-Rechners aktiviert ist, ist keine zusätzliche Konfiguration erforderlich. Dies ist darauf zurückzuführen, dass Multicast-Pakete, die an einer anderen Schnittstelle ankommen, ordnungsgemäß zum standardmäßigen Ziel weitergeleitet werden. Aus diesem Grund treffen Multicast-Anforderungen, bei denen es sich um den DA oder andere Service-Advertisements handelt, bei slpd ein. Wenn das Routing aus irgendeinem Grund nicht aktiviert ist, wird eine Konfiguration angefordert.
Wenn einer der folgenden Fälle auftritt, müssen Sie eventuell Multihomed-Rechner konfigurieren.
Das Unicast-Routing zwischen den Schnittstellen ist aktiviert und das Multicast-Routing ist deaktiviert.
Sowohl das Unicast-Routing als auch das Multicast-Routing sind zwischen den Schnittstellen deaktiviert.
Wenn das Multicast-Routing zwischen den Schnittstellen deaktiviert ist, ist dies normalerweise darauf zurückzuführen, dass Multicast nicht im Netzwerk bereitgestellt wurde. In diesem Fall wird Broadcast normalerweise für die nicht DA-basierte Serviceerkennung und für die DA-Erkennung in einzelnen Teilnetzen verwendet. Broadcast wird konfiguriert, indem die net.slp.isBroadcastOnly -Eigenschaft auf True gesetzt wird.
Tabelle 9-5 Konfigurieren mehrerer nicht gesteuerter Netzwerkschnittstellen
|
Wenn die net.slp.interfaces -Eigenschaft definiert ist, überwacht slpd die Unicast- und Multicast-/Broadcast-SLP-Anforderungen an den in der Eigenschaft angegebenen Schnittstellen, nicht aber an der standardmäßigen Schnittstelle.
Normalerweise definieren Sie die net.slp.interfaces -Eigenschaft in Verbindung mit der Aktivierung von Broadcast, indem Sie die net.slp.isBroadcastOnly-Eigenschaft festlegen, weil Multicast nicht im Netzwerk bereitgestellt wurde. Falls Multicast zwar bereitgestellt, aber nicht auf dem betreffenden Multihomed-Host gesteuert wird, kann eine Multicast-Anforderung von mehreren Schnittstellen bei slpd ankommen. Dies geschieht, wenn das Routing der Pakete von einem anderen Multihomed-Host oder Router durchgeführt wird, der die Teilnetze verbindet, die von den Schnittstellen bedient werden.
In einer solchen Situation erhält der SA-Server oder der UA, der die Anforderung sendet, zwei Antworten von slpd auf dem Multihomed-Host. Die Antworten werden dann von den Clientbibliotheken gefiltert und sind für den Client nicht sichtbar. Die Antworten sind jedoch in der snoop-Ablaufverfolgung sichtbar.
Hinweis -
Wenn das Unicast-Routing deaktiviert ist, sind die Services, die von den SA-Clients auf den Multihomed-Hosts bekannt gegeben werden, möglicherweise nicht von allen Teilnetzen aus erreichbar. Wenn Services nicht erreichbar sind, können die SA-Clients folgende Schritte ausführen:
Eine Service-URL für jedes Teilnetz bekannt geben
Sicherstellen, dass Anforderungen aus einem bestimmten Teilnetz mit einer erreichbaren URL beantwortet werden
Die SA-Clientbibliothek unternimmt keine Schritte, um sicherzustellen, dass erreichbare URLs bekannt gegeben werden. Das Serviceprogramm, das einen Multihomed-Host ohne Routing verarbeiten oder auch nicht verarbeiten kann, muss dann gewährleisten, dass erreichbare URLs bekannt gegeben werden.
Bevor Sie einen Service auf einem Multihomed-Host mit deaktiviertem Unicast-Routing bereitstellen, verwenden Sie snoop um festzustellen, ob der Service die Anforderungen von mehreren Teilnetzen richtig verarbeitet. Wenn Sie vorhaben, einen DA auf einem Multihomed-Host bereitzustellen, informieren Sie sich unter DA-Bereitstellung und Zuweisung von Bereichsnamen.
Wenden Sie das folgende Verfahren an, um die net.slp.interfaces-Eigenschaft in der slp.conf-Datei zu ändern.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Konfigurieren von RBAC (Übersicht der Schritte) in Systemverwaltungshandbuch: Sicherheitsservices.
# svcadm disable network/slp
net.slp.interfaces=value
Liste von IPv4-Adressen oder Hostnamen der Netzwerkschnittstellenkarten, die vom DA oder SA auf Multicast-, Unicast-UDP- und TCP-Meldungen an Port 427 überwacht werden sollen
Ein deaktivierter Server mit drei Netzwerkkarten und Multicast-Routing ist beispielsweise mit drei Teilnetzen verbunden. Die IP-Adressen der drei Netzwerkschnittstellen sind 192.147.142.42, 192.147.143.42 und 192.147.144.42. Die Teilnetzmaske ist 255.255.255.0 . Die folgenden Eigenschaftseinstellungen bewirken, dass slpd an allen drei Schnittstellen Unicast- und Multicast-/Broadcast-Nachrichten überwacht:
net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42
# svcadm enable network/slp
Wenn ein Host mit mehreren Schnittstellen Services mithilfe von slpd und der Proxyregistrierung bekannt gibt, müssen die Service-URLs, die von slpd bekannt gegeben werden, erreichbare Hostnamen oder Adressen enthalten. Wenn das Unicast-Routing zwischen den Schnittstellen aktiviert ist, können die Hosts in allen Teilnetzen die Hosts in anderen Teilnetzen erreichen. Proxyregistrierungen können auch für einen Service in einem Teilnetz durchgeführt werden. Wenn das Unicast-Routing jedoch deaktiviert ist, können die Serviceclients in einem Teilnetz nicht über den Multihomed-Host die Services in einem anderen Teilnetz erreichen. Diese Clients können jedoch die Services über einen anderen Router erreichen.
Ein Host mit dem standardmäßigen Hostnamen bigguy hat beispielsweise drei Schnittstellenkarten in drei verschiedenen nicht gesteuerten Teilnetzen. Die Hostnamen in diesen Teilnetzen sindbigguy, mit der IP-Adresse 192.147.142.42 , bigguy1, mit der IP-Adresse 192.147.143.42 und bigguy2, mit der IP-Adresse 192.147.144.42. Ein alter Drucker, oldprinter, ist beispielsweise mit dem Teilnetz 143 verbunden und die URL service:printing:lpr://oldprinter/queue1 ist mit net.slp.interfaces konfiguriert, wodurch alle Schnittstellen überwacht werden. Die oldprinter-URL wird vom Proxy an allen Schnittstellen bekannt gegeben. Die Rechner in den Teilnetzen 142 und 144 erhalten die URL als Antwort auf Serviceanforderungen, können aber nicht auf den oldprinter-Service zugreifen.
Die Lösung dieses Problems besteht darin, das Proxy-Advertisement mit slpd durchzuführen, der auf dem Rechner ausgeführt wird, der nur mit dem Teilnetz 143 verbunden ist, wodurch der Multihomed-Host nicht verwendet wird. Nur die Hosts im Teilnetz 143 können das Advertisement als Antwort auf eine Serviceanforderung erhalten.
Die Bereitstellung von DAs und die Zuweisung von Bereichsnamen in einem Netzwerk mit einem Multihomed-Host muss mit Bedacht durchgeführt werden, um sicherzustellen, dass Clients die verfügbaren Services abrufen können. Seien Sie besonders vorsichtig, wenn das Routing deaktiviert und die net.slp.interfaces-Eigenschaft konfiguriert ist. Es sei nochmals darauf hingewiesen, dass keine zusätzliche DA- und Bereichskonfiguration erforderlich ist, wenn Unicast-Routing zwischen den Schnittstellen eines Multihomed-Rechners aktiviert ist. Die Advertisements werden zusammen mit den DA-Erkennungsservices zwischengespeichert, auf die über jedes Teilnetz zugegriffen werden kann. Wenn das Unicast-Routing jedoch deaktiviert ist, kann eine unzureichende Bereitstellung von DAs zu Problemen führen.
Um sich eine Vorstellung von den Problemen zu machen, die aus der Konstellation des vorangegangenen Beispiels resultieren können, sollten Sie sich vor Augen führen, was geschehen würde, wenn bigguy einen DA ausführt und die Clients in allen Teilnetzen dieselben Bereiche haben. SAs im Teilnetz 143 registrieren ihre Service-Advertisements mit dem DA. UAs im Teilnetz 144 können diese Service-Advertisements abrufen, obwohl die Hosts im Teilnetz 143 nicht erreichbar sind.
Eine Lösung für dieses Problem besteht darin, einen DA in jedem Teilnetz und nicht auf dem Multihomed-Host auszuführen. In diesem Fall sollte die net.slp.interfaces-Eigenschaft auf den Multihomed-Hosts mit einem einzelnen Schnittstellen-Hostnamen oder einer einzelnen Schnittstellenadresse konfiguriert werden oder nicht konfiguriert belassen werden, wodurch die Verwendung der standardmäßigen Schnittstelle erzwungen wird. Der Nachteil dieser Lösung besteht darin, dass Multihomed-Hosts oft größere Rechner sind, die sich besser zur Bewältigung der Rechenlast eines DA eignen.
Eine weitere Lösung besteht darin, einen DA auf dem Multihomed-Host auszuführen, aber Bereiche zu konfigurieren, wodurch die SAs und UAs in jedem Teilnetz einen anderen Bereich haben. Im vorangegangenen Beispiel können die UAs und SAs im Teilnetz 142 einen Bereich namens scope142 haben. Die UAs und SAs im Teilnetz 143 können einen anderen Bereich namens scope143 haben und die UAs und SAs im Teilnetz 144 können einen dritten Bereich namens scope144 haben. Sie können die net.slp.interfaces-Eigenschaft auf bigguy mit den drei Schnittstellen konfigurieren, sodass der DA drei Bereiche in drei Teilnetzen bedient.
Durch das Konfigurieren der net.slp.interfaces -Eigenschaft wird einem DA auf dem Multihomed-Host ermöglicht, Service-Advertisements zwischen Teilnetzen zu übermitteln. Eine solche Konfiguration ist sinnvoll, wenn das Multicast-Routing im Netzwerk deaktiviert ist, während das Unicast-Routing zwischen den Schnittstellen auf einem Multihomed-Host aktiviert ist. Da Unicast zwischen den Schnittstellen gesteuert wird, können die Hosts, die sich nicht im gleichen Teilnetz wie der Service befinden, den Service kontaktieren, sobald sie die Service-URL erhalten. Ohne den DA erhalten die zu einem Teilnetz gehörenden SA-Server nur die Broadcast-Sendungen aus demselben Teilnetz, wodurch sie keine Services lokalisieren können, die sich außerhalb ihres Teilnetzes befinden.
Der häufigste Grund, warum die net.slp.interfaces -Eigenschaft nicht konfiguriert werden muss, ist, dass Multicast nicht bereitgestellt ist und stattdessen Broadcast verwendet wird. In anderen Fällen gilt es, umfassende Vorüberlegungen anzustellen und sorgfältig zu planen, um unnötige doppelte Antworten oder die Nichterreichbarkeit von Services zu vermeiden.