SLP - Service Location Protocol

SLP - Service Location Protocol
http://www.computerworld.ch/domino/...6617654125686a0046d145?OpenDocument
SLP - Service Location Protocol
Der Internetstandard SLP hilft in reinen IP-Umgebungen unter Netware 5, NCP-Dienste zu
lokalisieren.
Erscheinungsdatum: 03.01.2000
Rubrik:
Hintergrund
Autor:
Silvia Hagen*
Vorlieb nehmen. Zwar hat IPX den Vorteil, dass es nicht konfiguriert werden muss. Dafür belastet es mit vielen
Broadcasts das Netzwerk. Schliesslich führte Novell vor einigen Jahren Netware/IP ein. Dabei wurde der
IPX-Header einfach im IP-Paket eingebettet. Das war jedoch nicht das, was die Anwender wollten, sie verlangten
vielmehr eine reine IP-Umgebung. Mit Netware 5 kam Novell diesem Wunsch entgegen: Wenn man sich ein
Netware 5 Packet im Protokoll Analyzer ansieht, findet man endlich den NCP-Header (Netware Core Protocol)
direkt über dem TCP- (Transport Control Protocol) oder UDP-Header (User Datagram Protocol) - Pure IP!
Möglich wird dies unter anderem dank dem in Netware 5 implementierten Service Location Protocol (SLP), einem
Protokoll, das für das Lokalisieren von Diensten in einer TCP/IP Umgebung benützt werden kann. SLP ist keine
Erfindung von Novell, sondern ein Internet Standard. SLP Version 1 wurde im Juni 1997 standardisiert (Request
for Comment, RFC 2165). Netware 5 ist eine der ersten und zur Zeit wahrscheinlich die gängigste Implementation
dieses noch relativ jungen Protokolls. Im Juni 1999 wurde SLP Version 2 standardisiert (RFC 2608). Das Protokoll
wurde skalierbarer gestaltet, damit es den Anforderungen grosser Netzwerke gerecht wird. Wer heute Netware 5
und den neusten Novell Client installiert, arbeitet mit SLP Version 1. Novell wird allerdings SLPv2 so bald wie
möglich implementieren.
Mitspieler
Dieser Artikel soll erklären, wie SLP (Service Location Protocol) funktioniert und wie es in Netware 5 implementiert
ist. Um zu verstehen, wann und wie Netware Clients und -Applikationen SLP benützen, sollen hier erst ein Paar in
diesem Zusammenhang gebräuchliche Begriffe erklärt werden.
· User Agents:Ein User Agent (UA) ist ein Agent, der für eine Applikation einen SLP-Request macht, um einen
Dienst zu finden. Wenn der Netware 5 Client mit TCP/IP auf Windows installiert wird, so wird ein SLP UA
mitinstalliert. Dessen Aufgabe ist es nun, für den Client einen Login-Server zu finden, damit sich der Benutzer im
Netzwerk anmelden kann. Bei einer Standardinstallation des Clients ist der UA aktiv und wird während des
Bootprozesses initialisiert. In einer reinen IP-Umgebung unter Netware 5 ist SLP die einfachste Methode, einen
Login-Server zu finden. Eine andere Variante wäre zum Beispiel, dies über die Konfiguration durch einen DHCP
(Dynamic Host Configuration Protocol) Server zu machen.
· Service Agents: Ein Service Agent (SA) agiert, wie es sein Name schon sagt, für einen Dienst. Er antwortet direkt
auf SLP Service Requests von UAs. Gibt es jedoch im Netzwerk einen oder mehrere Directory-Agents (siehe
unten), so wird der SA seine Dienste bei diesem Directory Agent eintragen. Jeder Netware 5 Server, der mit
TCP/IP konfiguriert ist, hat einen SA.
· Directory Agents: Ein Directory Agent (DA) führt ein Verzeichnis von Diensten. Er beantwortet die Anfragen von
UA nur dann, wenn er Information über den gesuchten Dienst hat. Um in einem Netware-5-Netzwerk einen
Directory Agent aufzusetzen, wird auf dem Server ein spezielles Zusatzmodul (Netware Loadable Module, NLM)
geladen (slpda.nlm). Nicht jeder Netware-5-Server braucht ein DA zu sein. Üblicherweise wird pro Lokation
lediglich ein Server als DA aufgesetzt, und alle anderen Server registrieren ihre Services bei diesem DA. Wenn ein
User Agent bootet, sucht er einen DA, der sich mit einer sogenannten DAAdvert Message meldet. Nun kann der
Anwender seine SLP-Requests an diesen DA senden, der alle Service Agents im Netz kennt. Zusätzlich kann im
NWADMIN, dem Administrationsprogramm von Netware) SLP konfiguriert werden.
· Scopes: Verschiedene Dienste lassen sich durch die Konfiguration von sogenannten Scopes in administrative
Gruppen zusammenfassen. Die Scopes können frei gewählt werden. Eine gängige Art, Scopes zu definieren ist
nach geografischen Merkmalen. Also zum Beispiel ein Scope pro Lokation. Eine andere Variante wäre, Scopes
nach Diensten zu gruppieren. Also beispielsweise ein Scope für die Printer, ein Scope für die Server und so
1 of 4
6/23/00 4:34 PM
SLP - Service Location Protocol
http://www.computerworld.ch/domino/...6617654125686a0046d145?OpenDocument
weiter. In der Praxis hat sich der geografische Ansatz bewährt.
SLP-Netzwerk-Design
Wie ein SLP Netzwerk aufgebaut wird, hängt von der Grösse des Netzwerkes und den Anforderungen ab. In
einem kleinen Netzwerk etwa braucht man keinen Directory Agent. Die User Agents senden ihre SLP-Anfragen via
Multicast ins Segment und die vorhandenen Service Agents beantworten diese Anfragen direkt (siehe Abbildung
1). Dieses Netzwerkdesign lässt sich sehr einfach aufsetzen, es entspricht den client- und serverseitigen
Grundeinstellungen von Netware 5. Das ist sozusagen die «Plug-and-play»-Variante von SLP.
In grösseren Installationen mit vielen Service Agents kann dieser Netzwerkaufbau ungünstig sein. Denn wenn
Hunderte von Service Agents die User-Anfragen beantworten, gibt das ziemlich viel unkontrollierten
Netzwerkverkehr. In diesem Fall wird ein Server als Directory Agent aufgesetzt. Die Service Agents registrieren
nun ihre Dienste bei diesem DA, der seinerseits mittels Unicast (direkte TCP/IP-Kommunikation zwischen zwei
Rechnern) die Anfragen der UAs beantwortet.
Abbildung 2 zeigt das Netzwerk einer Firma, die eine Geschäftsstelle in Zürich und eine in Paris hat. Die beiden
Niederlassungen sind mit einem WAN-Link verbunden. An beiden Orten wird ein Server als Directory Agent
konfiguriert. Alle drei Agenten (UA, SA und DA) erhalten einen administrativen Scope für das jeweilige Netzwerk.
Also Scope «Paris» für alle Pariser Benutzer, die Pariser Server und den DA und Scope «Zürich» für alle Zürcher
Benutzer, den dortigen Server und den Zürcher DA.
Die Service Agents registrieren ihre Dienste beim lokalen Directory Agent. Dieser beantwortet die SLP-Requests
der Anwender (Clients). Der DA in Zürich führt nun eine Dienst-Datenbank für alle Dienste in der Lokation Zürich,
während der DA in Paris ein Verzeichnis aller Pariser Dienste hat. Dadurch, dass auf beiden Seiten des
WAN-Links ein Directory Agent vorhanden ist, verhindert man, dass SLP-Requests über das WAN gehen. Die
Anfragen für lokale Dienste können vom lokalen DA beantwortet werden. Diese Konfiguration erweist sich dann
als proble-matisch, wenn Benutzer in Zürich auf Dienste in Paris (und umgekehrt) zugreifen wollen.
Der SLP-Standard definiert kein Protokoll für die Kommunikation zwischen Directory Agents. Die beiden DAs
können also so ihre Service-Datenbanken nicht abgleichen. Damit der Zugriff auf Dienste in der anderen
Zweigstelle möglich sind, gibt es verschiedene Varianten.
· Man kann die User Agents so konfigurieren, dass sie beide Directory Agents kennen. Damit geht jedoch unter
Umständen ein Teil des SLP-Verkehrs über den WAN-Link - was vertretbar ist, wenn es nur einzelne Anwender
betrifft.
· Service Agents lassen sich auch so konfigurieren, dass sie sich bei beiden Directory Agents registrieren. Damit
verfügen beide DAs über ein Verzeichnis aller Dienste von beiden Niederlassungen. SLP-Anfragen von Usern
können in jedem Fall vom lokalen DA beantwortet werden. Der Nachteil ist, dass jeder Service Agent sich zweimal
registrieren muss, einmal beim lokalen DAs und einmal übers WAN beim DAs der anderen Geschäftsstelle. Dazu
muss man auch wissen, dass die Registrierungen für Dienste dynamisch behandelt werden. Das heisst, sie haben
eine Lebensdauer (Lifetime) und müssen regelmässig erneuert werden, damit das Verzeichnis auf dem Directory
Agent möglichst aktuell ist.
· Einen äusserst eleganten Ersatz für die fehlende DA-DA Kommunikation bieten die NDS (Novell Directory
Services). Novell liefert mit Netware 5 ein SLPDA.NLM mit. Dieses lädt man auf diejenigen Servern, auf denen
man einen Directory Agent wünscht. In der NDS gibt es für jeden DAs ein entsprechendes Objekt. Im obigen
Szenario können die beiden DA-Objekte in der NDS so konfiguriert werden, dass sie beide die Scopes von beiden
Niederlassungen kennen. Nun können die beiden DAs ihre Dienstetabellen austauschen. Dies geschieht über
NDS-Replikation.
Wann braucht es einen DA?
Wie schon gesagt, ist es in einem kleinen Netzwerk durchaus vertretbar, die «Plug-and-play»-Variante ohne DA
zu benützen. Folgende Gründe sprechen aber dafür, einen oder mehrere DA zu konfigurieren.
· Sobald User Agents und Service Agents in verschiedenen Netzwerksegmenten implementiert sind, und auf den
Routern Multicast ausgeschaltet ist, funktioniert SLP nur mit einem DA. Sowohl beim UA als auch beim Service
Agent kann die IP-Adresse des DA statisch konfiguriert werden. Dann funktioniert SLP auch ohne Multicast.
2 of 4
6/23/00 4:34 PM
SLP - Service Location Protocol
http://www.computerworld.ch/domino/...6617654125686a0046d145?OpenDocument
· Wenn beide SLP-Versionen eingesetzt werden und Interoperabilität gebraucht wird, funktioniert dies nur mit
einem Directory Agent. In diesem Falle setzt man einen SLPv2 Directory Agent auf. Er beherrscht beide
Protokollversionen und kann somit Anfragen beider Versionen beantworten.
· Schliesslich ist es auch ratsam, einen Directory Agent aufzusetzen, sobald die Zahl der Dienste hoch ist. Wo
diese Grenze liegt, lässt sich nicht allgemein festlegen. Es hängt vom Netzwerk, der allgemeinen Netzlast, der
eingesetzten Hardware und weiteren Komponenten ab. Viele Dokumentationen zum Thema geben 30 Server
innerhalb eines Multicast Radius als Grenzwert an. Diese Zahl ist jedoch als sehr generelle Richtlinie mit viel
Vorsicht zu geniessen.
SLP-Kommunikation
SLP kann sowohl via UDP als auch über TCP kommunizieren. In beiden Fällen wird Port 427 benützt. Meistens
kommt UDP zum Einsatz. TCP wird höchstens für den Austausch von grösseren Datenmengen eingesetzt.
Während des Boot-Vorgangs sendet ein SLP Device - das kann ein UA oder ein SA sein - ein sogenanntes
Directory Agent Discovery Packet aus. Dieses geht an die Multicast Adresse 224.0.1.35. Das ist die offiziell
registrierte Multicast-Adresse für Directory Agents. Jeder DA, der ein solches Paket sieht, antwortet dem
SLP-Device mit einem sogenannten DA-Advert-Packet. Darin gibt er dem SLP-Device seine IP-Adresse und seine
Scope-Information bekannt. Somit hat der SLP-Device nun eine Liste aller verfügbaren DAs.
Ist der SLP-Device ein User Agent, so wird er nun seine SLP-Requests nicht mehr an eine Multicast-Adresse
senden, sondern direkt via Unicast an den DA. Ist der SLP-Device ein Service Agent, so registriert und
deregistriert er seine Dienste direkt beim DA.
Wenn es keinen Directory Agent gibt, so schickt der User Agent seinen SLP Service Request an die General
Service Location Multicast Adress 224.0.1.22. Jeder Service Agent hört auf diese Multicast-Adresse und wenn er
die vom User Agent gewünschten Dienste kennt, antwortet er direkt auf diese Anfrage.
Multicasting
Broadcasts werden nur im lokalen Segment (Netzwerk) verbreitet. Denn Router, deren Aufgabe es ist,
verschiedene Netzwerksegmente miteinander zu verbinden, geben keine Broadcasts weiter. SLP kann zwar so
konfiguriert werden, dass es statt Multicast Broadcast verwendet, doch ist dies keine wünschenswerte
Konfiguration. Vor allem in Netzwerken mit modernen Switches bringt das einige Nachteile. Vorzuziehen wäre die
Einschränkung des Multicast-Radius auf 1. Das limitiert Multicast auf das lokale Netzwerksegment, wobei es
trotzdem von Switches optimal weitergeleitet wird .
Im Unterschied zu Broadcast kann Multicast geroutet werden. Jeder SLP-Device schickt beim Boot-Vorgang ein
sogenanntes IGMP (Internet Group Management) Membership Packet ins Netz. Wenn Router solche Pakete
sehen, merken sie sich, auf welcher Schnittstelle welche IGMP-Gruppen vorhanden sind. So können sie bei
Multicast-Paketen entscheiden, ob sie diese an andere Netzwerksegmente weitergeben müssen. IP-Router geben
Multicast-Pakete nur an die Netzwerksegmente weiter, in denen andere Devices derselben Multicast-Gruppe
vorhanden sind.
In vielen grösseren Netzwerken wird Multicast auf den Routern ausgeschaltet. In diesem Falle können alle
SLP-Devices auch statisch oder mit DHCP (Dynamic Host Configuration Protocol) konfiguriert werden.
SLP Service Types
Services werden in SLP als URL (Uniform Resource Locator) angegeben. Diese sind im RFC 1738 beschrieben.
Häufig vorkommende Diensttypen sind bei IANA (Internet Assigned Numbers Authority, http://www.iana.org)
registriert.
Service Types werden von Service Agents gebraucht, um ihre Dienste bei DA zu registrieren und deregistrieren.
Sie werden ebenso von DA und SA gebraucht, um Dienste an User Agents weiterzugeben. Wenn URL registriert
werden, haben sie als Attribute unter anderem eine Lifetime (Lebensdauer) und ein Längenfeld.
Wer in einem Netware-5-Umfeld SLP Service Types anschaut, wird voraussichtlich folgende Dienste finden:
· MGW.NOVELL (Compatibility
3 of 4
6/23/00 4:34 PM
SLP - Service Location Protocol
http://www.computerworld.ch/domino/...6617654125686a0046d145?OpenDocument
Mode Gateway / Migration Agent)
· NDAP.NOVELL (NDS) - vergleichbar mit SAP Type 0x0278
· BINDERY.NOVELL (Netware Server) vergleichbar mit SAP Type 0x0004
· SAPSRV.NOVELL (Netware 5
Server mit IPX CMD
· RMS.NOVELL (Resource Management
Service von NDPS)
· SRS.NOVELL (NDPS Broker)
· RCONSOLE.NOVELL (Java Rconsole)
· DIRECTORY.AGENT
Lerne Dein Protokoll kennen
Es gibt unterschiedliche Möglichkeiten, sich näher mit SLP zu befassen. Die schnellste Art, ein Protokoll
kennenzulernen, ist der Gebrauch eines Netzwerkanalyzers. Es gibt verschiedene Werkzeuge in diesem Bereich,
angefangen bei Snoop, das alle Unix-Benutzer kennen, bis hin zu Tools wie Novells Lanalyzer für Windows,
Etherpeek/Tokenpeek von der AG Group, Surveyor von Shomiti oder High-end-Analyzern wie Network Associates
Sniffer Pro und Hewlett-Packards Internet Advisor.
Wenn man sich die Kommunikation eines Protokolls in einem Analyzer-Tracefile anschaut, versteht man schnell,
wie und welche Informationen ausgetauscht werden. Weiss man erst einmal, wie eine normale Kommunikation
aussehen muss, wird man im Ernstfall auch effizient Troubleshooten können.
* Die Autorin arbeitet als Beraterin und Instruktorin für Netzwerke. Ihre Firma Sunny Connection ist unter
http://www.sunny.ch erreichbar.
Weitere Literatur zu SLP
Wer sich lesenderweise mit SLP befassen möchte, dem stehen unter anderem folgende Quellen zur Verfügung:
· Novells Support-Site (http://support.novell.com) hält ein paar gut geschriebene Dokumente zum Thema bereit.
Sie sind über die Suchmaschine der Knowledgebase leicht aufzufinden (SLP als Suchbegriff eingeben).
· Bücher gibt es erst sehr wenige. Empfehlenswert ist etwa «Service Location Protocols for Enterprise Networks»
von James Kempf und Pete St. Pierre, erschienen im Wiley Verlag. Ebenfalls sehr hilfreich ist «Novell's Guide to
Troubleshooting TCP/IP» von Silvia Hagen und Stephanie Lewis, erschienen bei Novell Press. Es behandelt SLP
und Novells Implementation von SLP.
· Im Internet gibt es die Service Location Protocol Homepage. Ohne viel Schnickschnack, aber äusserst
informativ. Sie ist unter http://www.svrloc.org zu finden.
· Last but not least: Lesen Sie die entsprechenden RFC! RFC 2165 für SLPv1 und RFC 2608 für SLPv2. RFC
finden Sie unter verschiedenen Webadressen, so unter: http://www.faqs.org/rfcs/rfcsearch.html.
[Copyright Computerworld (CH), International Data Group Inc.]
...........................
4 of 4
6/23/00 4:34 PM