Novell is now a part of Micro Focus

Dynamically Discovering Services on an IP Network with SLP

Articles and Tips: article

DAVE BEUS
Systems Architect
Novell, Inc.

EDWARD LIEBING
Senior Writer
Novell, Inc.

01 Mar 1999


With NetWare 5 and its support for Pure IP, the old Service Advertising Protocol (SAP) has been replaced by the Service Location Protocol (SLP). Here's a behind-the-scenes look at how clients and servers find each other in this brave new environment.

Introduction

Service Location Protocol (SLP) allows TCP/IP networks to dynamically discover a set of available services that are present. You can also use SLP to resolve short names of NetWare servers (such as APPSERV5) to their IP addresses. These capabilities allow SLP clients to discover and access those services (such as logging in to NetWare 5 servers) on IP networks.

This AppNote will cover the SLP infrastructure as it is currently implemented in NetWare 5. The discussion is divided into several sections:

  • Registering services using SLP

  • Requesting services using SLP

  • How clients use name service providers to find services

  • An analogy for understanding SLP Service Agents and Directory Agents

  • How to enable multicast support for SLP on routers and servers

This AppNote will use some comparisons between SAP and SLP to better explain some of the concepts used in SLP. However, the infrastructure explained here does not cover mixed IPX and IP environments, nor do we explain how to configure networks to run in a Pure IP environment.

In its Appendix, this AppNote also covers the SLP console commands and settings that are available with NetWare 5. The Appendix also covers the newer SLP console commands and settings that come with the NetWare 5 Support Pack 1.

Advertising Services Using SLP

Since the Service Location Protocol has some similarities to Novell's Service Advertising Protocol (SAP), it will be helpful to compare the two.

A SAP and SLP Primer

Most people who have been involved with NetWare networks understand how IPX communicates with other servers and clients on the network. We'll therefore build on that knowledge as the basis for understanding SLP. We'll first compare how SAP and SLP work by presenting a very basic overview of their functionalities. This is followed up with some more in-depth information on their respective functionality.

SAP. The IPX protocol designers created Service Advertising Protocol to provide dynamic discovery of services on an IPX network. SAP information is broadcast from each server to the other routers on the network. SAP stores the services types, names, and addresses in router tables (databases kept on servers and routers). The SAP information is synchronized between routers every 60 seconds in a process sometimes called the "60 second buzz." This quick synchronization means that when a server stops advertising a service, it will disappear from SAP within a minute or two.

An IPX client trying to find SAP services sends a SAP request to the router(s) on the network. Routers respond to the client with the SAP information that matches the request sent by the client.

While SAP works very efficiently in traditional local area networks, it can consume a large amount of bandwidth across WAN links. SAP also has a general scalability problem because it can only scale to the number of services that can be synchronized within the 60 second time frame. Several attempts have been made to overcome the 60 second buzz and make SAP more scalable. Perhaps the most notable of these is the NetWare Link Services Protocol or NLSP. However, few of these attempts to make SAP scalable have been widely accepted. Therefore, it is currently necessary for network administrators to use SAP filters on the routers to manage SAP services that are replicated across WAN links.

SLP. The TCP/IP protocol uses SLP (IETF RFC 2165) to provide dynamic discovery of services on a TCP/IP network. In its simplest form, SLP uses multicasts from the clients (User Agents or UAs) to find services (Service Agents or SAs) on servers. In this simple configuration, the SA does not broadcast its services by replicating information to other servers, routers, or clients. Instead, the SA waits for a multicast request from a client. If a client sends a multicast request looking for a service that is running on the SA, the SA will send a unicast message back to the client with the information about the requested service (see Figure 1).

Figure 1: In its simplest configuration SLP uses multicasts from the client and unicast responses from Service Agents.

Note: Keep in mind that SLP request from clients can be general or very specific, because SLP can store a large number of attributes about each service. By contrast, SAP can only store the service's name, type, and address.

SLP can use multicasting as its means to find services. Unlike broadcasts, which target all nodes, multicasts target a group of nodes. The main benefit of multicasting is that it will send one packet and all the members of the multicast group will receive it. Only the intended recipients will read the packets. Multicasts are not isolated to local segments. Routers will forward them to whatever subnets have a member of the multicast group.

When a multicast host comes up on a subnet, it sends out a multicast packet to the "all hosts" multicast address. That packet tells the router that it is a member of a multicast group. The router then records that it has at least one node in that multicast group on that interface.

Multicast routers notify neighboring routers of what multicast groups it has. This way all routers learn where to forward packets that are addressed to that multicast group. Routers periodically poll each interface to see if the multicast group members still exist.

SLP in its simplest form is not very scalable. SLP multicasts from clients can consume a large amount of bandwidth because every SLP request must be heard and processed by every server on the network, for as far as the SLP multicast traffic is propagated. Only servers that can satisfy the request actually answer the multicast request. In this configuration, SLP multicast support must be enabled between the client and the server or the client will be unable to find the server via SLP. Fortunately, SLP has additional components such as Directory Agents (see Figure 2) that allow SLP to scale in larger network environments.

Figure 2: With a Directory Agent, clients send a unicast to the DA and receive a unicast response.

We'll explain more about how Directory Agents work later in this AppNote.

How NetWare 5 Advertises Services Using SLP

Just as SAP provides dynamic service advertising for IPX, SLP can provide the same functionality for IP. Here is a comparison of how SAP and SLP work.

SAP Advertising. When you bind IPX to a network adapter on the server, IPX immediately begins to broadcast that this server's services are now available. It does this by broadcasting the server's name, its network address, and its SAP type (0004h) through the Service Advertising Protocol. This information is stored in router tables and is immediately propagated as far as the SAP broadcast can propagate, given the various network routing filters that may be in place.

When the server initially loads Novell Directory Services (NDS), it broadcasts packets which tell the NDS tree name, its network address, and its SAP type (0278h). This information is also propagated as far as that broadcast can propagate, given the same restrictions. This SAP information is stored and synchronized among the router tables on the network, and it can be queried by clients who may be looking for a server or a tree.

SLP Advertising. When you boot up a NetWare 5 server, SLP is automatically loaded and services on the server begin registering with the server's SLP Service Agent. In SLP, the counterpart to the IPX SAP type 0004h is the object named BINDERY.NOVELL, which provides the server name and network address. In concept, SAP type 0278h is equivalent to the object named NDAP.NOVELL, which provides NDS partition information (the tree is implied by the partition name). The Service Agent creates the object BINDERY.NOVELL and stores it in the server's memory. It also creates an NDAP.NOVELL object if registered.

Note: SLP only creates the NDAP.NOVELL object if the server has a replica of an NDS partition. SLP only creates one NDAP.NOVELL object per NDS partition.

The services on the server have now been registered, even though no packets have been sent on the network. In SAP, the server is responsible for telling the network about the new service; in SLP, the service is registered and the client (UA) is responsible for requesting the service. The SA now sits back and listens for SLP multicast requests from UAs that are looking for services that have been registered with the SA.

Typically, SLP services registered by Novell end with ".NOVELL". Some common Novell SLP services are listed in the following table:


BINDERY.NOVELL

NetWare server (The term has nothing to do with NetWare 3 bindery services.)

NDAP.NOVELL

Novell Directory Access Protocol services. This is only registered when replication services are initiated-it registers the full NDS replica.

RCONSOLE.NOVELL

The IP-based RCONSOLE program

MGW.NOVELL

Novell Migration Agent

CMD.NOVELL

Novell IPX Compatibility Mode server

SAPSRV.NOVELL

IPX SAP information stored in SLP by IPX Compatibility Mode servers

SRS.NOVELL

NDPS Service Registry Service

NetWare clients and NetWare servers supporting SLP contain both UAs and SAs. The SLP configuration can get more complex as other services, such as Directory Agents, are added. These complexities will be discussed in the analogy section later in this article.

Requesting Services Using SLP

Now that we understand how services are registered, let's look at how they are requested. In doing so, it's important to understand the role of Name Service Providers in the IP world. If a client tries to make an IP connection to a service by specifying the name of the server, there must be a name service provider to map the server name to an IP address, or the client will not be able to connect to that server via IP.

Of course, if you are also running IPX and that same server can be found by an IPX-based name service provider, the client will make an IPX connection to that server if it determines that no IP path exists. (This clarification can be useful when you are trying to diagnose why a client is connecting through IPX instead of through IP.)

Name Service Providers

Whether you are using IPX or IP, discovery of network services is performed through name service providers. Name service providers are used to resolve names to IPX or IP addresses, as well as to discover which services are available on the network. By default, Novell clients have eight IPX and IP name service providers.

The IPX-capable name service providers are:

  • Bindery. All IPX servers have a list of the SAP services that are available on the network. Bindery is used when the client asks the server on its default connection to resolve a SAP name to an IPX address. The bindery is also used by the client to get a list of available services to fill the client server dialog.

  • SAP (Service Advertising Protocol). This is used to place a broadcast request on the network to advertise and locate services and associated IPX addresses. Clients use SAP to make their initial connection and to resolve a name to an IPX address.

  • NDS (Novell Directory Services). NDS can provide a list of services that are in the current NDS context, and resolve the short names of servers (such as APPSRV1) in the current NDS context. NDS can also resolve a fully qualified NDS server name (such as APPSRV1.PROVO.NOVELL) if the server resides in the NDS tree.

The IP-capable name service providers are:

  • NDS (Novell Directory Services). Same as above.

  • DNS (Domain Name Service). DNS can resolve any fully qualified DNS server name (such as APPSRV1.PROVO.NOVELL.COM) to an IP address. It can also resolve the short names of servers (such as APPSRV1) in the current DNS sub-domain. DNS cannot provide discovery of services on the network. Clients use DNS only if domain information is available.

  • SLP (Service Location Protocol). SLP can provide discovery of services on the network.

  • NWHOST (NetWare Host File). This can be used like any Unix host file to list names and associated IP addresses. Windows 95/98 clients use the local host file found in the C:\NOVELL\CLIENT32 directory to resolve names to addresses. This allows you to supply a name and address, which can also be an alias for a NetWare 5 server. Windows NT clients use the host file found in the \SystemRoot\system32\drivers\etc directory.

  • DHCP (Dynamic Host Configuration Protocol). As a service, DHCP automatically allocates reusable (dynamic) IP network addresses in an environment that has limited IP address resources. Windows 95/98 clients can use this service to initially establish connections and to set preferred tree and context. To do this, the clients use options 85, 86, and 87. (Windows NT clients only use option 86, as it matches the tree name specified in option 85.)

The static IP address, though not really a name service, deserves mention here because IP clients allow a connection to a server using an IP address. Legacy IPX clients never allowed clients to connect to a server by specifying the internal IPX address of the server.

Each of these name service providers can come into play at some point, depending on how the network is configured. For simplicity's sake, we'll limit our discussion to SLP and NWHOST.

How NetWare Clients Find Services on the Network

As stated earlier, IP services are not broadcast or replicated to other servers, routers, or clients. Instead, the server waits for requests from clients. This section looks at how both IPX and IP workstation clients in NetWare 5 initially request services from their respective network servers. It then looks at the differences in the approach of a Windows 95/98 client and a Windows NT client.

Note: Since SLP is easier to understand without the presence of Directory Agents, the following discussion assumes there are no Directory Agents on the network. However, most configurations will use Directory Agents, as we will explain later in this AppNote.

The Windows 95/98 IPX Client Bootup Process. When a NetWare 5 Windows 95/98 client initially boots up and loads IPX, the first thing it wants to do is find a server. With IPX, the client broadcasts a "Get Nearest Server" request to the network. All servers that receive this request reply with a "Give Nearest Server" response to the client. The client then determines which server to initially attach to (the closest) by how many hops and ticks the servers are away from it. Hops denote how many routers the client would have to pass through to get to the service or network address, and ticks denote how long takes to get there. (There are 18 ticks per second and at least one tick per hop.)

With IPX using SAP, clients query the bindery of the server they initially attach to via the "Get/Give Nearest Server" connection process. Once a service connection is created between this client and the closest server, the client asks for a list of all servers that this server knows about through SAP type 0004h broadcasts. From this list, the client hopes to find the designated or preferred server it wants to attach to.

In the NetWare Login dialog box (see Figure 3), users can view this list of known servers by clicking on the Servers button. They can also view the NDS trees that are known to the workstation IPX software by clicking on the Tree button. This tree list comes from all SAP type 0278h broadcasts received by the initial server.

Figure 3: NetWare client software can display lists of known servers and NDS trees.

The Windows 95/98 IP Client Bootup Process. When a NetWare 5 Windows 95/98 client initially boots up and loads IP, by default the client queries NWHOST for a server name. If no name is resolved in NWHOST, the client queries SLP for a server. In IPX, you have hops and ticks to determine the number of router hops and the available bandwidth between the client and the servers. However, with IP you only have subnet addresses, which makes it very difficult to calculate the "closest" server.

Because of this, the client queries SLP for all of the BINDERY.NOVELL services. The User Agent multicasts to find all BINDERY.NOVELL services. Each Service Agent that has a BINDERY.NOVELL service gives a unicast response. The client's User Agent chooses some of these to multicast an attribute request to receive the IP address in an attribute reply.

The multicast delivery method is propagation—requests don't need a default route to get to the next hop. User Agents put the packet out on the wire and the routers propagate the request as far as SLP multicasts have been configured to propagate. On the other hand, the Service Agent's unicast delivery method requires a TCP/IP route back to the User Agent.

Windows 95/98 follows the legacy login process where the client must first find an initial server to attach to before the actual login takes place. To do this, the NetWare client software makes an SLP service request asking for all available BINDERY.NOVELL services. Each SA responds with its service information, and the client searches through the list of services looking for a server to connect to using the following prioritized procedure:

  1. Find a server that resides on the same IP subnet as the client.

  2. Find a server that resides on the same IP network as the client.

  3. Find any server.

Once the initial server attachment is made, the login dialog box is displayed to allow the user to log in. If a Preferred Server or Preferred Tree is specified in the client properties, or if the user enters a server or tree name in the login dialog box, the client looks for the specified server in the list of services it received. If that server is found, the client checks to see if the server is in the specified tree. If so, the client connects to the server and the user is logged in.

To obtain a list of known NDS trees, the client requests all of the NDAP.NOVELL services that the UA can find. The NDAP.NOVELL service registers by partition, and not by tree, but the partition name is truncated to just the tree name before being placed in the list.

Differences Between Windows 95 and Windows NT Clients

Windows 95/98 Client. The Windows 95/88 client works serially, giving a prioritized order in which the client uses the Name Service Providers to look for services. The client tries one Name Service Provider after the other on the list. If one of the services fails, the client tries the next one, and so on. For example, if the workstation has both IP and IPX name service providers configured and you have IP as the default, the client will use NWHOST to resolve service names. If IPX is the second choice in the Protocol Order box, the client will attempt the IPX name services that support IPX addresses.

If you Alt+click on the Network Neighborhood icon and select the Novell NetWare Client Properties page, you can select the Protocol Preferences tab. There you can order how you want to initially connect to either IP or IPX services (see Figure 4).

Figure 4: Select the Protocol Preferences tab in the NetWare Client Properties window.

The order in which the protocols are listed is the order in which they are used. If IP is the preferred protocol, the client will try the IP-based Name Service Providers first, and then try the IPX-based Name Service Providers. The default order of IP service providers is NWHOST, NDS, SLP, DNS, then DHCP.

You can use the Up/Down buttons to prioritize the order in which both the protocols and the Name Service Provides will be used. For example, if you have IP loaded first with NWHOST as the first service selected in the Name Resolution Order list, NWHOST services will be tried first. If that fails, the next selection will be tried. If IP services fail, the client will move on to the IPX side, and so on until it finds one that is successful.

Windows NT Client. In the Windows NT client, the user can't determine the protocol order. Instead, the Windows NT client checks all the Name Service Providers simultaneously. All configured name service providers are first queried with a cache flag that allows the NSPs who maintain a cache to resolve the name. If no NSP resolves the name, the providers are queried without the cache flag.

You can add and remove services, but you can't change their priority because there is no priority. The NT client simply sends out service requests to all services simultaneously then waits a certain time period to see what comes back. The default time to wait for responses from the Name Service Providers is 10 seconds. (This Name Resolution Timeout value can be adjusted from the Advanced Settings tab on the client properties page.) If the client can't find anything via IP, then it will use one of the IPX name service providers.

Another difference between Windows 95/98 and Windows NT clients is that the NT client does not use Preferred Server or Preferred Tree information to establish an initial network connection. The user must press Ctrl+Alt+Del to bring up the NetWare Login dialog box on an NT workstation.

An SLP Analogy: The "Dance"

To better understand how SLP works and what role the Directory Agent plays, we'll use the analogy of a dance. As with most analogies, some of the details may not correspond exactly between the real world and the analogy. However, this analogy has helped many users get the overall picture of what Directory Agents are all about.

You can think of SLP Service Agents as a bunch of people going to a big dance where everyone will be looking for one another. As the guests enter the dance hall, however, they are all blindfolded and given a cellular phone. The guests want to obtain one another's addresses so they can meet later on, so they start yelling. "I'm Sandy Jones and I'm looking for a cute blonde guy with a Vespa scooter. If someone here meets that criteria, call me on my cell phone at 555-1234." Each person yells the same type of request to everyone in the room.

Suppose there is a blonde guy who's looking for a nice girl, and he happens to own a Vespa Scooter. He takes his cell phone and gives Sandy a call. If there is another cute blonde guy at the dance who owns a Vespa scooter, he would get no answer when he tries to call her. But since the second young man really wants to talk to Sandy, he waits a random amount of time before calling back. This process continues until all eligible bachelors who fit Sandy's criteria have called and given her their names and addresses. Once Sandy has gotten all the calls from the eligible young men at the dance, she is free to do what she wants with the information.

This is basically what you have with a multicast. Everyone is yelling as loud as they can, looking for what they want and then waiting for responses to their requests. At the same time, each person is listening for other individuals who are making requests from the criteria that they match as well. As more and more people show up at the dance, things can get very chatty with this approach. Moreover, in a multicast situation the requester usually has to time out before he can assume he has received all the responses. Fortunately, SLP has some additional components that allow it to scale for a larger environment. These are known as Directory Agents or DAs.

Directory Agents

Directory Agents serve as a repository for SLP service information that the Server Agents register and that the User Agents query. (In NetWare 5, the DA resides on a NetWare server in the form of a NetWare Loadable Module named SLPDA.NLM.) Directory Agents reduce the consumption of bandwidth from SLP multicast traffic. In a Directory Agent configuration, each server's SA registers its services via unicasts with the DA. Additionally, the clients unicast their requests to the DA instead of multicasting their requests to all the servers on the network. For each client request, the DA searches through its list of registered SLP services and responds back to the client via a unicast reply.

Going back to our dance analogy, it is like having everyone pick up a phone and call the DA and ask for the phone number of the person they are looking for. After the DA gives them the number, they call the person on the telephone.

The solution for replicating SLP information between sites is only hinted at a in the IETF specification for SLP (RFC 2165). The RFC states that DAs could use a replicated database to store and replicate SLP information between sites, but it doesn't specify how. Novell is the first company to implement a mechanism for synchronizing DAs by using a replicated database. For obvious reasons, Novell chose to use NDS as their storage and replication mechanism for SLP. The DA creates an NDS object for each registered service. The SLP objects are created in NDS and replicated using NDS partitioning and replication. Therefore, at Novell we use Directory Agents at each site to minimize the chatter of SLP multicast traffic.

Now let's look at our analogy with Directory Agents in place. Instead of having everyone who comes in simply start yelling out names, guests first stop at the DA's desk and register specific information about themselves, such as their name, address, phone number, color of hair, mode of transportation, hobbies, and so on. Now when Sandy wants to find a blonde guy with a Vespa scooter, she simply goes to the front desk to query the DA for this information. The DA looks through his list and replies, "Yes, we have several blonde guys who drive a Vespa Scooter. Here are their names and cell numbers."

With a Directory Agent in place, the Service Agents are obligated to use the DA if they receive the advertisement of its availability. If a server comes up and a DA is running, the server registers its BINDERY.NOVELL server and NDAP.NOVELL tree services with the DA. The DA has to advertise itself periodically, just in case new UAs and SAs have attached to the network and missed its initial advertisement.

Once you place a DA on the network segment, chatter immediately lessens. Unfortunately, there's always someone who didn't hear the bell, so they come back into the room screaming as loud as they can. Everyone is looking at him a little annoyed, but they respond anyway. Such is an example of how you get cases where there is more network traffic than is necessary because SAs didn't know the DA was present. For instance, if the network connection is down when the DA is coming up and then the network connection is reestablished, the SAs and clients on the network will only know that the DA is available through multicasting.

How does an SA know a DA is available? One way is to multicast to see if a DA is available. Or the SA can query DHCP, which acts like a little informant that wanders the dance door. Or the system administrator can also statically configure the SA to go directly to the DA so it doesn't need to multicast. When a client receives a Directory Agent advertisement, the client waits a random amount of time before requesting services from the DA. This is done so as not to overload the DA with initial requests.

DAs and Time To Live

Suppose the dance goes on for six hours and people are keeling over with exhaustion. Somehow the DA needs to know who is still on their feet and available. Each service contains a "Time To Live" (TTL) attribute for which the default is one hour. If the SA doesn't re-register its services before the TTL period expires, the DA removes it from the list of available services. Every Service Agent has a TTL for each of its services. If a service is still active within an hour, the Service Agent sends a request back to the Directory Agent asking for that service to be extended another hour. This process continues for the life of the service.

Directory Agents and Scopes

Another SLP concept is called scoping. SLP scopes allow network administrators to organize SLP services into groups. The Service Agent on each server determines into which groupings the services on that server will be registered. By default, all SLP services are registered in the "unscoped" scope. When clients send SLP requests to a Directory Agent, they can specify a scope for the DA to use in order to find the service they are looking for. If no scope is specified by the client, the DA will look in the "unscoped" table to find the service requested.

Using our dance analogy, scopes would be like a chaperone directing people with similar information to a certain area on the dance floor. There they would mingle among themselves until the front desk directs someone over to that area who is looking for a member in the group that has the needed information. Unscoped SLP services would be like an unchaperoned dance, where everyone is allowed to mingle as they like.

It is also helpful to know that a given DA can service multiple scopes, and an SA can register services in multiple scopes. The registered services can be replicated between sites using NDS.

Enabling Multicast Support for SLP on Cisco Routers and NetWare Servers

In order for multicasts to work outside of the local subnet, routers must be configured to support IGMP (Internet Group Management Protocol).

General Multicast uses the following addresses:

  • Ethernet address: 01 00 5E xx xx xx

  • IP address: 224.x.x.x to 239.x.x.x

Note: IP multicast address maps into Ethernet MAC address in hexadecimal.

SLP uses the following Multicast Addresses:

  • 224.0.1.35 in IP and 01005E000123 in Ethernet for SLP DA advertisements.

  • 224.0.1.22 in IP and 01005E000116 in Ethernet for general SLP requests and registrations.

For UDP and TCP requests, one or both of the source and destination port addresses must be 427.

SLP multicast requires Protocol Independent Multicasting (PIM) which is a multicast routing protocol. There are two flavors of PIM: PIM Dense Mode, which is used for densely populated groups, and PIM Sparse Mode, which is used for sparsely populated groups. PIM is independent of the underlying unicast routing protocol. PIM Dense Mode uses the Reverse Path Forwarding algorithm and is data driven.

Configuring PIM on Cisco Routers

The following Cisco router configuration enables multicast for SLP multicast as well as for streaming audio/video applications like real audio/video. This configuration also shows how to block SLP multicast on a specific interface.

To enable Multicast for the router, use the following command:

ip multicast-routing

The following line will be added by default by the router:

ip dvmrp route-limit 7000

To enable Multicast for each interface, use the following command:

ip pim dense-mode

To block SLP multicast and let other multicast to go through, perform the following:

ip multicast boundary 20 (The  boundary 20  points to access list 20) access-list 20 deny 224.0.1.35 (Blocks SLP DA advertise multicast packets) access-list 20 deny 224.0.1.22 (Blocks SLP general multicast packets) access-list 20 permit any (Permits all other multicast to propagate)

When you are done, your router configuration might look like this (note that interface Hssi1 is not filtering SLP multicast, but Hssi2 is):

ip multicast-routing ip dvmrp route-limit 7000 ! ! interface Hssi1/0 ip address 127.99.9.2 255.255.255.252 ip pim dense-mode interface Hssi8/0.100 point-to-point ip address 128.99.9.2 255.255.255.252 ip pim dense-mode ip multicast boundary 20 ! access-list 20 deny 224.0.1.35 access-list 20 deny 224.0.1.22 access-list 20 permit any

Configuring PIM on NetWare Routing Servers

PIM.NLM is an implementation of Protocol Independent Multicasting - Dense Mode for NetWare servers. Once the Sparse Mode specification is finalized, Novell intends to supplement this NLM with a Sparse Mode implementation of PIM.

PIM.NLM needs very little configuration. After loading the TCPIP.NLM and binding the IP addresses, the server is ready to route. PIM.NLM is simply loaded by typing LOAD PIM at the server console. When PIM.NLM loads, it figures out the current IP bindings on the server and makes all the interfaces PIM enabled (capable of routing multicast packets using PIM Dense Mode protocol).

Console and Debugging of PIM.NLM

There is no user interface for configuring PIM.NLM because there is not much to configure. However, there is a user interface for the console to monitor the activity of the PIM routing on a node. When PIM.NLM loads, it creates a screen with a menu which is self destructive. PIM control packets (Hellos, Grafts, Graft-Acks, Asserts, Join/Prunes), Multicast Data Packets, IGMP activity, debug information, and so on are available.

By setting the following variables, you can get the information associated with the packets to be displayed to a separate debug screen.

set pim join prune debug = 1 set pim hello debug = 1 set pim graft debug = 1 set pim assert debug = 1 set pim all debug = 1

(this displays all packets associated with PIM.NLM to the debug screen)

Tunneling

Currently, multicast routing is not mandatory for IP routing on the Internet. Therefore, not all the nodes on the Internet are multicast routing enabled. As a result, on the Internet today we see some multicast "islands" or groups of nodes capable of multicast routing separated by an ocean of other nodes which are not capable of routing multicast packets. In order for the multicast routing to work in these scenarios, NetWare 5 configures tunnels between these groups of nodes which are then able to route multicast packets.

Tunnels have two ends, or destinations, and each end is associated with an IP address. The first end is bound to an IP address of a node in the group that is multicast-enabled. Then within that group, you have another multicast enabled interface that communicates to a second multicast island. Thus the two islands can communicate with one another using the Internet's unicast routers.

Before the packet is put on the tunnel, it is encapsulated using IP-IP encapsulation (protocol 4). The multicast packet travels as data of an IP packet with source address as the originating end of the tunnel, destination address as the other end of the tunnel. Once the packet reaches the destination node, the packet is passed to the PIM module by the IP layer and the PIM module strips off the header and finds the multicast packet which has traveled as data. This multicast packet is in turn routed to other interfaces.

Tunnels should typically be configured between the "borders" of islands so that the packet can proliferate into the next island transparently.

Configuration of Tunnels

You configure tunnels with PIM.NLM by specifying the source and the destination of the tunnels in the SYS:ETC\PIMTUN.CFG file. In order for the tunnel to function properly, the source and destination addresses should be bound addresses at either end of the tunnel.

For example, in the test setup shown below, the server with an IP address of 2.1.1.1 has a tunnel to a server with an IP address of 4.2.2.2. The configuration information in the SYS:ETC\PIMTUN.CFG file on the 2.1.1.1 server should have the following line:

2.1.1.1 4.2.2.2

and the 4.2.2.2 server should have the following line:

4.2.2.2 2.1.1.1

When the PIM.NLM loads, the tunnel will come up as a virtual interface and PIM will recognize the IP addresses of 2.1.1.1 and 4.2.2.2 as neighbors.

Conclusion

Up to this point, we have just discussed the SLP infrastructure as it has been implemented by Novell in NetWare 5. We also used some comparisons between SAP and SLP to better explain some of the concepts used in SLP.

The Appendix discusses the SLP console commands and settings that come with NetWare 5. It also covers those SLP console commands and settings that were added to the NetWare 5 Support Pack 1.

Appendix: SLP Console Commands and Settings

The following are SLP debug and query commands that come with NetWare 5:


SLP OPEN <filename.log<

SLP trace file is created in the root of the SYS volume.

SLP CLOSE

This command closes the SLP trace file.

DISPLAY SLP SERVICES

Common Novell SLP service types include the following:

MGW.NOVELL (compatibility mode gateway/migration agents)CMD.NOVELL (compatibility mode server/relay agents)NDAP.NOVELL (NDS)BINDERY.NOVELL (NetWare servers)SAPSRV.NOVELL (NetWare 5 servers with IPX CMD loaded)RMS.NOVELL (Resource Management Service of NDPS)RCONSOLE.NOVELL (Java rconsole)SRS.NOVELL (NDPS broker)DIRECTORY-AGENT (sends an SLP multicast packet to rediscover the DA on the network)

SLP restriction are as follows:

<slp attribute<==<value<Other operators available are <=, <=

Examples of using the Display SLP Services command include the following:

DISPLAY SLP SERVICES (Displays all known SLP services)DISPLAY SLP SERVICES BINDERY.NOVELL (Displays all bindery.novell services)DISPLAY SLP SERVICES BINDERY.NOVELL//(SVCNAME-WS==ABC*)/ (Displays bindery.novell services with names that begin with 'abc')DISPLAY SLP SERVICES BINDERY.NOVELL/PROVO/(SVCNAME-WS==ABC*)/ (Displays bindery.novell services with names that begin with 'abc' in scope 'provo')DISPLAY SLP SERVICES MBW.NOVELL//(CMD NETWORK==ABC12345)/(Displays all the Migration Agents servicing the CMD network number ABC12345)

DISPLAY SLP ATTRIBUTES (<slp url<)

An example of using the Display SLP attributes command include the following:

DISPLAY SLP ATTRIBUTES SERVICE:BINDERY.NOVELL:///SERVER1(Displays all SLP attributes and values for the SERVER1 bindery.novell object.)

DISPLAY SLP DA

(Displays the list of SLP Directory Agents and their current status.)

The SLP SET Commands


SET SLP DA Discovery Options = <value<

where <value< = 0 to 8 (Default = 3)0x01 = Use multicast DA advertisements0x02 = Use DHCP discovery0x04 = Use static file SYS:ETC\SLP.CFG0x08 = Scopes Required

SET SLP TCP = <value<

where <value< = ON/OFF (Default = OFF)This sets SLP to use TCP packets instead of UDP packets when possible.

SET SLP DEBUG = <value<

where <value< = 0 to 4294967255 (Default = 0)0x01 = COMM0x02 = TRAN0x04 = API0x08 = DA0x010 = ERR0x020 = SAThese bits can be AND'd or OR'd together for multiple values. An example of COMM and API would be 0x05.

SET SLP Multicast Radius = <value<

where <value< = 0 to 32 (Default = 32)This parameter specifies an integer describing the multicast radius.

SET SLP Broadcast = <value<

where <value< = ON/OFF (Default = OFF)This parameter sets the use broadcast packets instead of multicast packets.

SET SLP MTU size= <value<

where <value< = 0 to 4294967255 (Default = 1472)This parameter specifies an integer describing the maximum transfer unit size.

SET SLP Rediscover Inactive Directory Agents = <value<

where <value< = 0 to 4294967255 (Default = 60)This parameter specifies the minimum time period in seconds that SLP will wait to issue service requests to rediscover inactive directory agents.

SET SLP Retry Count = <value<

where <value< = 0 to 128 (Default = 3)This parameter specifies an integer value describing the maximum number of retries.

SET SLP Scope List = <value<

where the maximum length of <value< is 1023 (Default = 1023)This parameter specifies a comma-delimited scope policy list.

SET SLP SA Default Lifetime = <value<

where <value< = 0 to 4294967255 (Default = 900)This parameter specifies an integer value describing the default lifetime in seconds of service registers.

SET SLP Event Timeout = <value<

where <value< = 0 to 4294967255 (Default = 53)This parameter specifies an integer value describing the number of seconds to wait before timing out multicast packet requests.

SET SLP DA Heart Beat Time = <value<

where <value< = 0 to 4294967255 (Default = 10800)This parameter specifies an integer value describing the number of seconds before sending the next Directory Agent heartbeat packet.

SET SLP Close Idle TCP Connections Time = <value<

where <value< = 0 to 4294967255 (Default = 300)This parameter specifies an integer value describing the number of seconds before idle TCP connections should be terminated.

SET SLP DA Event Timeout = <value<

where <value< = 0 to 429 (Default = 5)This parameter specifies an integer value describing the number of seconds to wait before timing out Directory Agent packet requests.

New or Modified SLP SET Commands that are Found in NetWare 5 Support Pak 1


SET SLP Maximum WTD = <value<

where <value< = 1 to 64 (Default = 10)This parameter specifies the maximum number of work to do threads that SLP can allocate.

SET SLP Reset = <value<

where <value< = ON/OFF (Resets to OFF each time it is set to ON)This parameter forces the SA to send new service registers and forces the SA to send DA Advertise packets.

SET SLP Debug = <value<

where <value< = 0 to 65535 (Default = 88)0x01 = COMM0x02 = TRAN0x04 = API0x08 = SA_DA0x010 = ERR0x020 = SA0x040 = UA_DAThese bits can be AND'd or OR'd together for multiple values. An example of COMM and API would be 0x05.

* 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.

© Copyright Micro Focus or one of its affiliates