test

Service Location Protocol Administration Guide

How to Configure for Nonrouted, Multiple Network Interfaces

The most likely configuration steps that might be required on multihomed machines with routing disabled are:

Configuring the net.slp.interfaces Property

If the net.slp.interfaces property is set, slpd listens for unicast and multicast/broadcast SLP requests on the interfaces listed in the property, rather than on the default interface. For example, suppose a server with three network cards and multicast routing turned off is connected to three subnets. And suppose the three network interfaces have IP addresses 192.147.142.42, 192.147.143.42, and 192.147.144.42 and that the subnet mask is 255.255.255.0. The following property setting causes slpd to listen on all three interfaces for unicast and multicast/broadcast messaging:


net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42

You can set the net.slp.interfaces property to either IP addresses in dotted decimal form, as above, or to resolvable host names.

Usually, you set the net.slp.interfaces property in conjunction with enabling broadcast by setting the net.slp.isBroadcastOnly property, because multicast has not been deployed in the network. However, if multicast has been deployed, but is not being routed on this particular multihomed host, it is possible for a multicast request to arrive at slpd from more than one interface. This can happen because another multihomed host or router connecting the subnets served by the interfaces routes the packets.

When this happens, the SA server or UA sending the request gets two responses from slpd on the multihomed host. These responses are filtered out by the client libraries, so the client should not see them. They are visible on the snoop trace, however.

Be careful when configuring the net.slp.interfaces property if unicast routing is turned off. Without unicast routing, any services advertised by SA clients on the multihomed host might not be reachable from all the subnets, unless the SA clients do the following:

The SA client library makes no effort to assure that reachable URLs are advertised. Therefore, it is up to the service program, which might or might not handle a multihomed host with no routing, to assure that reachable URLs are advertised.

Before deploying a service on a multihomed host with unicast routing disabled, you should use snoop to determine whether the service handles requests from multiple subnets correctly. Furthermore, if you are planning on deploying a DA on the multihomed host, see "DA Placement and Scope Name Assignment".

Proxy Advertising on Multihomed Hosts

If a host with multiple interfaces advertises services using slpd and proxy registration, the service URLs advertised by slpd must contain reachable host names or addresses. If unicast routing is enabled between the interfaces, then hosts on all subnets are able to reach hosts on the others, and proxy registrations can be made for a service on any subnet. If, however, unicast routing is disabled, then service clients on one subnet cannot reach services on another through the multihomed host (although they might be able to reach them through another router).

For example, suppose the host with default host name bigguy has three interface cards on three different unrouted subnets. The host names on these subnets are bigguy, with IP address 192.147.142.42, bigguy1, with IP address 192.147.143.42, and bigguy2, with IP address 192.147.144.42. Now suppose that a legacy printer, oldprinter, is connected to the 143 subnet. If the URL:


service:printing:lpr://oldprinter/queue1

is proxy-advertised on all interfaces by configuring net.slp.interfaces to listen on all interfaces, machines on the 142 and 144 subnets will receive the URL in response to service requests, though they will be unable to access the service.

The solution to this problem is to perform the proxy advertisement with slpd running on a machine connected the 143 subnet only, rather than on the multihomed host. Only hosts on the 143 subnet are able to obtain the advertisement in response to a service request.

DA Placement and Scope Name Assignment

The placement of DAs and assignment of scope names in a network with a multihomed host, in which routing is disabled but the net.slp.interfaces property is configured, must be done carefully to assure that clients obtain accessible services. Again, if unicast routing is enabled between the interfaces on a multihomed machine, no special DA and scope configuration is necessary, because advertisements cached with the DA identify services that are accessible from any of the subnets. However, if unicast routing is disabled, poor placement of DAs can result in problems.

To see what can go wrong in the previous example, consider what would happen if bigguy runs a DA, and clients on all subnets have the same scopes. SAs on the 143 subnet register their service advertisements with the DA. UAs on the 144 subnet can obtain those service advertisements, even though hosts on the 143 subnet are unreachable.

One solution to this problem is to run a DA on each subnet and not on the multihomed host. In this case, the net.slp.interfaces property on the multihomed hosts should be configured with a single interface host name or address, or it should be left unconfigured, forcing the default interface to be used. A drawback of this solution is that multihomed hosts are often large machines that could better handle the computational load of a DA.

Another solution is to run a DA on the multihomed host, but configure scopes such that the SAs and UAs on each subnet have a different scope. For example, in the above case, scopes could be configured so that UAs and SAs on the 142 net have scope scope142, UAs and SAs on the 143 net have scope scope143, and UAs and SAs on the 144 net have scope scope144. You can configure the net.slp.interfaces property on bigguy with the three interfaces, so that the DA serves three scopes on the three subnets.