|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Administration: Network Services Oracle Solaris 11 Information Library|
A multihomed server acts as a host on multiple IP subnets. The server can sometimes have more than one network interface card and can act as a router. IP packets, including multicast packets, are routed between the interfaces. In some situations, routing between interfaces is disabled. The following sections describe how to configure SLP for such situations.
Without configuration, slpd listens for multicast and for UDP/TCP unicast on the default network interface. If unicast and multicast routing is enabled between interfaces on a multihomed machine, no additional configuration is needed. This is because multicast packets that arrive at another interface are properly routed to the default. As a result, multicast requests for DA or other service advertisements arrive at slpd. If routing is not turned on for some reason, configuration is required.
If one of the following conditions exist, you might need to configure multihomed machines.
Unicast routing is enabled between the interfaces and multicast routing is disabled.
Unicast routing and multicast routing are both disabled between the interfaces.
When multicast routing is disabled between interfaces, it is usually because multicast has not been deployed in the network. In that situation, broadcast is normally used for service discovery that is not DA-based and for DA discovery on the individual subnets. Broadcast is configured by setting the net.slp.isBroadcastOnly property to True.
Table 9-5 Configuring Nonrouted, Multiple Network Interfaces
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, a multicast request can arrive at slpd from more than one interface. This situation can occur when the routing of packets is handled by another multihomed host or router that connects the subnets that are served by the interfaces.
When such a situation occurs, the SA server or the UA that is sending the request receives two responses from slpd on the multihomed host. The responses are then filtered by the client libraries and the client does not see them. The responses are, however, visible in the snoop trace.
If unicast routing is turned off, services that are advertised by SA clients on multihomed hosts might not be reachable from all the subnets. If services are unreachable, SA clients can do the following:
Advertise one service URL for each individual subnet.
Assure that requests from a particular subnet are answered with a reachable URL.
The SA client library makes no effort to assure that reachable URLs are advertised. The service program, which might or might not handle a multihomed host with no routing, is then responsible for assuring that reachable URLs are advertised.
Before you deploy a service on a multihomed host with unicast routing disabled, use snoop to determine whether the service handles requests from multiple subnets correctly. Furthermore, if you plan to deploy a DA on the multihomed host, see DA Placement and Scope Name Assignment.
Use the following procedure to change the net.slp.interfaces property in the slp.conf file.
For more information, see How to Obtain Administrative Rights in Oracle Solaris Administration: Security Services.
# svcadm disable network/slp
List of IPv4 addresses or host names of the network interface cards on which the DA or SA should listen for multicast, unicast UDP, and TCP messages on port 427
For example, a server with three network cards and multicast routing that is turned off is connected to three subnets. The IP addresses of the three network interfaces are 22.214.171.124, 126.96.36.199, and 188.8.131.52. 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:
# svcadm enable network/slp
If a host with multiple interfaces advertises services by using slpd and proxy registration, the service URLs that are advertised by slpd must contain reachable host names or addresses. If unicast routing is enabled between the interfaces, hosts on all subnets can reach hosts on other subnets. Proxy registrations can also be made for a service on any subnet. If, however, unicast routing is disabled, service clients on one subnet cannot reach services on another subnet through the multihomed host. However, those clients might be able to reach the services 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 184.108.40.206, bigguy1, with IP address 220.127.116.11, and bigguy2, with IP address 18.104.22.168. Now suppose that a legacy printer, oldprinter, is connected to the 143 subnet and that the URL service:printing:lpr://oldprinter/queue1 is configured with the net.slp.interfaces to listen on all interfaces. The oldprinter URL is proxy-advertised on all interfaces. The machines on the 142 and 144 subnets receive the URL in response to service requests, but are unable to access the oldprinter service.
The solution to this problem is to perform the proxy advertisement with slpd running on a machine that is connected to the 143 subnet only, rather than on the multihomed host. Only hosts on the 143 subnet can obtain the advertisement in response to a service request.
The placement of DAs and assignment of scope names on a network with a multihomed host must be done carefully to assure that clients obtain accessible services. Be particularly cautious when routing is disabled and the net.slp.interfaces property is configured. Again, if unicast routing is enabled between the interfaces on a multihomed machine, no special DA and scope configuration is necessary. The advertisements are 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 problems can result 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 situation, 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 disadvantage 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 so that the SAs and UAs on each subnet have a different scope. For example, in the previous situation, UAs and SAs on the 142 subnet might have a scope that is called scope142. UAs and SAs on the 143 subnet might have another scope that is called scope143 and UAs and SAs on the 144 subnet could have third scope that is called 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.
Configuring the net.slp.interfaces property enables a DA on the multihomed host to bridge service advertisements between the subnets. Such configuration is useful if multicast routing is turned off in the network, but unicast routing between interfaces on a multihomed host is enabled. Because unicast is routed between the interfaces, hosts on a subnet different from the subnet on which the service is located can contact the service when they receive the service URL. Without the DA, SA servers on a particular subnet receive only broadcasts that were made on the same subnet, so they cannot locate services off of their subnet.
The most common situation that necessitates configuration of the net.slp.interfaces property occurs when multicast is not deployed on the network and broadcast is used instead. Other situations require careful thought and planning to avoid unnecessary duplicate responses or unreachable services.