Tree-to-Tree SLP
Articles and Tips: qna
01 Nov 2002
Q.
I've been doing some reading on SLP with NetWare 6 and I have not found how Tree- to-Tree communication can take place, or if it will. I have found references to what information gets passed if it is authenticated, which leaves me to believe that there are items that will not get passed to other trees on the same network.
If you know of an article or TID that would further explain how two or more trees share SLP information (if they can) in a NetWare v6 environment, please send it my way.
SLP Slurpy with Sandy
A.
Dear SLP Slurpy: I suspect a little different form of presenting the SLP material might be easier to remember, so here's a try at it. Where do SLP Directory Agents acquire information? From their storage database, which is a memory cache and in eDirectory (speaking for Novell's implementation).
The eDirectory portion is a Scope-specific SLP container, and by default it is in the server's context. Directory Agents (DAs) also acquire information from Server Agents (SAs) who register with the DA.
How do SAs locate DAs? Either by hearing DA multicast/broadcasts, which are of a very limited range, or by being told to contact a specific IP addresses (through static routing). The file etc\cfg.slp holds such static addresses, and it is used by the SAs, not the DAs.
DAs have no DA-to-DA communications ability. They are totally ignorant of siblings. SAs are likewise ignorant of other SAs and the same applies to User Agents (UAs). A User Agent queries a DA for information, and the DA replies from its data storage. Unless we take steps manually, that storage represents only very local information that is within a multicast/broadcast range. UAs may query for SAs without bothering a DA, and they use multi/broadcast for this.
Thus to broaden the base of information available to a DA, and hence via query/responses to UAs, we need to share data collected by DAs located across the network.
There are two ways of sharing. The conventional and bad way is to instruct every SA to contact each DA, using slp.cfg to go beyond radar range. If we draw a graph of this, we find a totally meshed network, a large collection of each source talking to every destination. The reason is DAs don't pool information by default, and maintenance of this method is painful.
The second way is for DAs to be configured to pool their information in eDirectory. We use ConsoleOne, etc., to configure Directory Agents. Use one NDS SLP container, one Scope name, and all collections will be deposited there. To ensure maximum coverage, we load a DA on every server and point it to the common storage.
Think of cell/mobile phones and world-wide connectivity. If we pool DA information, do we need to manually configure SAs? No, we don't touch SA configurations. By default the existence of a DA on a server compels its own SAs to register with that DA. It is a forced static route, independent of information stored in the file etc\slp.cfg. We now see that an SA talking to its own DA results in passing that information to all DAs through its NDS exchanges.
The graph of a pooled environment becomes one of no SLP traffic on the wire except for UA requests to individual servers. You also get the inevitable periodic DA adverts, plus infrequent DA to SLP re-registration heartbeat exchanges. All "normal" SLP traffic is buried within normal NDS exchanges. SAs talk only to their DA, and for NetWare servers, that's all internal to the server.
With SLP v2, we can kill DA advertisements if we wish (Monitor | Server Config | SLP | SLP Enable DA General Multicast = off). We have converted the fully meshed network to one of single connections between servers, with all configuration being performed by pointing DAs to the same NDS container. This means there is no long lists of servers in the slp.cfg file; we ignore that file except for contacting other NDS trees.
The last piece of the configuration puzzle is UAs finding DAs. Again we have multicasting/broadcasting plus static configuration available. Static parameters can be distributed by hand or by DHCP (which is a neat use for a DHCP on each server, doing nothing more than handing out NDS information without dealing with IP address allocations). Foreign clients, which means laptops of visitors, can use multicast while mobile locals can still use static routes (plural).
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.