If you have a shared network configuration where DHCP services are not available, the Sun Ray server can be configured to provide those services. This configuration adds more complexity to the initial and ongoing Sun Ray network administration. See Chapter 2, Planning a Sun Ray Network Environment for overall information about using shared networks with available DHCP services.
You can use the utadm -A
subnet command to configure a
Sun Ray server to provide DHCP services. The Sun Ray server can be
configured to respond with network/IP information, device
configuration information, or both.
Fill out Table 19.1, “Shared Network Configuration Worksheet”, so that the information is readily available during the actual configuration process. This worksheet is for configuring a Sun Ray server in a shared network without an external DHCP service.
Values that are provided in italics are only examples and should not be used.
Values provided in normal font are defaults and can be used.
Superscripted numbers (#) refer to footnotes at the end of each section.
The blank rows in the worksheets are provided for you to add additional information about your environment if you choose to print the worksheets.
Table 19.1 Shared Network Configuration Worksheet
Aspect or Variable | Default Value, Example, or (Other) | Your Primary Server Value | Your Secondary Server Value |
|---|---|---|---|
Configuring the Sun Ray interconnect interface using utadm | (Provide the start time) | ||
| 192.168.128.0 | ||
| 192.168.128.1 | ||
| 255.255.255.0 | ||
| 192.168.128.0 | ||
|
| ||
If the Sun Ray server is used for IP address allocation: | |||
| 192.168.128.16 | ||
|
| ||
| 192.168.128.1 | ||
| 192.168.128.1 | ||
Specify additional server list? (optional) | (yes or no) | ||
|
| ||
| 192.168.128.2 |
(1) These values are different for each Sun Ray server, even if that server is part of a failover group.
(2) These values must be unique among the servers in a failover group. The following guidelines can help you determine what addresses to allocate for each Sun Ray server:
X = (Number of clients/(Number of servers - 1)) - 1.
First unit address for primary server= 192.168.128.16.
Last unit address for all servers = X + first unit address. If last unit address is greater than 240, reduce to 240.
First unit address for secondary servers = 1 + last unit address of previous server. If first unit address is greater than 239, configure for a class B network. Example: 120 clients, 4 servers. X= 39.
(3) These values are the same as the interface host address by default.
This procedure shows how to configure a Sun Ray Server to provide DHCP services to Sun Ray Clients.
Log in as the superuser of the Sun Ray server.
Configure the Sun Ray LAN subnet:
# /opt/SUNWut/sbin/utadm -A
subnet#where
subnet#The utadm script begins configuring DHCP for the Sun Ray interconnect, restarts the DHCP daemon, and configures the interface. The script then lists the default values and asks whether they are acceptable.
NoteIf the IP addresses and DHCP configuration data are not set up correctly when the interfaces are configured, the failover feature cannot work properly. In particular, configuring the Sun Ray server's subnet IP address as a duplicate of any other server's subnet IP address may cause the Sun Ray Authentication Manager to issue Out of Memory errors.
Evaluate the default values.
If you are satisfied with the default values and the server is not part of a failover group, answer y.
Otherwise, answer n and accept whatever default values are shown by pressing Return or provide the correct values from the worksheet.
The utadm script prompts for the following:
New netmask (255.255.255.0)
New first Sun Ray Client address (192.168.128.16)
Total number of Sun Ray Client addresses
New authorization server address (192.168.128.1)
New firmware server address (192.168.128.10)
New router address (192.168.128.1)
An additional server list.
If you answer yes, it requests either a file name (_filename_) or a server IP address (192.168.128.2)
The utadm script again lists the configuration values and asks whether they are acceptable.
If not, answer n and revise the answers you provided in Step 3.
If the values are correct, answer y. The utadm script configures the Sun Ray Client firmware versions and restarts the DHCP daemon.
Repeat this procedure for each of the secondary servers in your failover group.
If a router is between the Sun Ray server and the Clients, configure bootp forwarding in the routers.
The following section presents an example of a Sun Ray Client deployment on shared networks B, C, and D as shown in Figure 19.1, “Example of Alternate Shared Network Topology”.
Subnet B in
Figure 19.1, “Example of Alternate Shared Network Topology” is a
directly connected shared subnet that uses IP addresses in the
range 130.146.59.0/24. The Sun Ray server
helios is attached to the interconnect
through its hme0 network interface, which
has been assigned the IP address
130.146.59.5. The answers to the three
predeployment questions are as follows:
From which DHCP server will Clients on this subnet get their basic IP networking parameters?
In a shared subnet scenario, you must choose whether a DHCP service on the Sun Ray server or some external DHCP service will provide the client with basic network parameters. If the enterprise already has a DHCP infrastructure that covers this subnet, it probably supplies basic network parameters. If no such infrastructure exists, configure the Sun Ray server to provide basic network parameters.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
The administrator must choose whether to supply additional configuration parameters to the client and, if so, whether to use a DHCP service on the Sun Ray server or some external DHCP service for this purpose. On a directly connected shared subnet, it is possible to deploy clients without providing additional parameters at all, but this configuration is not desirable because it deprives the client of a number of features, including the ability to download new firmware.
Administrators of an already established DHCP infrastructure might be unable or unwilling to reconfigure that infrastructure to provide additional Sun Ray configuration parameters, so having the Sun Ray server provide these parameters is usually more convenient. This setup can be desirable even when the established infrastructure is capable of delivering the additional parameters. This setup enables SRSS commands to be used to manage the values of the additional configuration parameters when those values need to be changed in response to software upgrades or patch installations on the Sun Ray server.
For instance, a patch that delivers new client firmware could automatically update the firmware version string that is delivered to the client. However, if the firmware version parameter is supplied by some external DHCP service, an administrator must manually edit the firmware version parameter string in the external DHCP configuration rules to reflect the new firmware version delivered by the patch. This activity is time-consuming and error-prone, as well as unnecessary.
How will clients on this subnet locate their Sun Ray server?
Use one of the optional additional configuration parameters to report the location of the Sun Ray server to the client. If additional configuration parameters are not supplied to the client at all, the client has no indication of the location of any Sun Ray server. In these circumstances, the client attempts to discover the location of a Sun Ray server by using a broadcast-based mechanism. However, the clients broadcast packets propagate only on the local subnet so, in the case of a remote subnet, the broadcast cannot reach the Sun Ray server, and contact cannot be established.
The following examples illustrate two configurations of the directly connected shared subnet. In the first example, the Sun Ray server delivers both basic networking parameters and additional parameters. In the second example, an external DHCP service supplies basic networking parameters but no additional parameters are provided to the client, which must establish contact with the Sun Ray server through its local subnet broadcast discovery mechanism.
The most likely case, where an external DHCP service provides basic networking parameter and the Sun Ray server provides additional parameters, is illustrated by an example in Section 19.3.5.2, “Deployment on a Remote Subnet”.
In this example, the answers to the three predeployment questions are as follows:
From which DHCP server will clients on this subnet get their basic IP networking parameters?
From the Sun Ray server.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
From the Sun Ray server.
How will clients on this subnet locate their Sun Ray server?
The clients will be informed of the location of the Sun Ray server through an additional configuration parameter delivered when Sun Ray services are restarted.
Configure the Sun Ray server to provide both basic and additional parameters to the shared subnet.
DHCP service for clients on a shared subnet is configured through the utadm -A
subnetcommand. In this example, the shared subnet has network number130.146.59.0, so the appropriate command is utadm -A 130.146.59.0.# /opt/SUNWut/sbin/utadm -A 130.146.59.0 Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 no IP addresses offered auth server list: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.59.1 Accept as is? ([Y]/N): n netmask: 255.255.255.0 (cannot be changed - system defined netmask) Do you want to offer IP addresses for this subnet? (Y/[N]): y new first Sun Ray address: [130.146.59.4] 130.146.59.200 number of Sun Ray addresses to allocate: [55] 20 new auth server list: [130.146.59.5] To read auth server list from file, enter file name: Auth server IP address (enter <CR> to end list): If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N): new firmware server: [130.146.59.5] new router: [130.146.59.1] Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 first unit address: 130.146.59.200 last unit address: 130.146.59.219 auth server: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.59.1 auth server list: 130.146.59.5 Accept as is? ([Y]/N): ### Building network tables - this will take a few minutes ### Configuring firmware version for Sun Ray All the units served by "helios" on the 130.146.59.0 network interface, running firmware other than version "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their next power-on. ### Configuring Sun Ray Logging Functions ### stopped DHCP daemon ### started DHCP daemon #
The default values initially suggested by utadm were not appropriate. Specifically, this server would not have offered any IP addresses on the
130.146.59.0subnet because utadm assumes that basic networking parameters, including IP addresses, are provided by some external DHCP service when the client is located on a shared subnet. In this example, however, the Sun Ray server is required to provide IP addresses, so the administrator replied n to the first "Accept as is?" prompt and was given the opportunity to provide alternative values for the various parameters. Twenty IP addresses, starting at130.146.59.200, were made available for allocation to DHCP clients on this subnet.Restart Sun Ray services on the Sun Ray server by issuing the utstart command to fully activate Sun Ray services on the shared subnet.
# /opt/SUNWut/sbin/utstart A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.
In this example, the answers to the three predeployment questions are as follows:
From which DHCP server will clients on this subnet get their basic IP networking parameters?
From an external DHCP service.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
The clients will not be supplied with additional parameters.
How will clients on this subnet locate their Sun Ray server?
By using the local subnet broadcast discovery mechanism.
In this example, the Sun Ray server does not participate in
client initialization at all. Configuration steps are still
required on the Sun Ray server because it responds by
default only to clients located on directly connected
dedicated interconnects. It responds to clients on shared
subnets only if the utadm -L on command
has been executed. Running the utadm -A
subnet command to
activate DHCP on the Sun Ray server for a shared subnet, as
in this example, implicitly executes utadm
-L on. If utadm -A
subnet has not been
run, the administrator must run utadm -L
on manually to enable the server to offer sessions to
clients on the shared subnet.
Configure the external DHCP service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the clients on this subnet is beyond the scope of this document. Note the following guidelines:
If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. The most likely location for such a Relay Agent would be on a router in this subnet, in this case, the router named
r22-59in Figure 19.1, “Example of Alternate Shared Network Topology”. For a brief introduction to this topic, refer to Section 19.5, “Sun Ray Client Initialization Requirements Using DHCP”.An existing external DHCP service might need to have its IP address allocation for this subnet increased in order to support the new clients. This requirement applies whenever additional DHCP clients are placed on a subnet. You might also want to reduce the lease time of addresses on this subnet so that addresses become eligible for reuse quickly.
Configure the Sun Ray server to accept client connections from shared subnets by running the following command:
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utstart must be run before LAN connections will be allowed
Restart Sun Ray services on the Sun Ray server by issuing the utstart command to fully activate Sun Ray services on the shared subnet.
# /opt/SUNWut/sbin/utstart A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.
Subnets C and D in Figure 19.1, “Example of Alternate Shared Network Topology” are remote shared subnets.
Subnet C uses IP addresses in the range
130.146.22.0/24. Subnet D uses IP addresses
in the range 130.146.71.0/24. The Sun Ray server named
helios has no direct attachment to either
of these subnets. This characteristic defines them as remote.
The answers to the three predeployment questions are as
follows:
From which DHCP server will clients on this subnet get their basic IP networking parameters?
In a shared subnet scenario, the administrator must choose whether a DHCP service on the Sun Ray server or some external DHCP service will provide the client with basic network parameters.
If the enterprise already has a DHCP infrastructure that covers this subnet, it probably supplies basic network parameters. If no such infrastructure exists, configure the Sun Ray server to provide basic network parameters.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
The administrator must choose whether additional configuration parameters will be supplied to the client, and, if so, whether they will be supplied by a DHCP service on the Sun Ray server or by some external DHCP service.
Administrators of an established DHCP infrastructure might be unable or unwilling to reconfigure it to provide additional Sun Ray configuration parameters, so having the Sun Ray server provide them is usually more convenient. This setup can be desirable even when the established infrastructure is capable of delivering the additional parameters. This setup enables you to use Sun Ray Software commands to manage the values of the additional configuration parameters, when those values need to be changed in response to software upgrades or patch installations on the Sun Ray server.
For instance, a patch that delivers new client firmware could automatically update the firmware version string delivered to the client. However, if the firmware version parameter is supplied by some external DHCP service, an administrator must manually edit the firmware version parameter string in the external DHCP configuration rules to reflect the new firmware version delivered by the patch. This kind of activity is time-consuming and error-prone as well as unnecessary.
How will clients on this subnet locate their Sun Ray server?
Use one of the optional additional configuration parameters to report the location of the Sun Ray server to the client. If additional configuration parameters are not supplied to the client at all, the client cannot locate a Sun Ray server, so it tries to discover the location of a Sun Ray server by using a broadcast-based mechanism. However, the clients broadcast packets propagate only on the local subnet so they cannot reach a Sun Ray server located on a remote subnet, and cannot establish contact.
The next two examples illustrate representative remote shared subnet configurations. In the first example, an external DHCP service provides basic networking parameters, and the Sun Ray server provides additional parameters. This configuration is by far the most likely for a Sun Ray deployment in an enterprise that has an established DHCP infrastructure.
In the second example, basic networking parameters and a bare minimum of additional parameters, just enough to enable the client to contact a Sun Ray server, are supplied by an external DHCP. In this case, the DHCP service is in a Cisco router. This scenario is less than ideal.
No firmware parameters are delivered to the client, so it cannot download new firmware. The administrator must make some other arrangement to provide the client with new firmware, for instance, by rotating it off this subnet periodically onto an interconnect or onto some other shared subnet where a full set of additional configuration parameters is offered.
In this example, in which clients are deployed on subnet C in Figure 19.1, “Example of Alternate Shared Network Topology”, the answers to the three predeployment questions are as follows:
From which DHCP server will clients on this subnet get their basic IP networking parameters?
From an external DHCP service.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
From the Sun Ray server.
How will clients on this subnet locate their Sun Ray server?
The clients will be informed of the location of the Sun Ray server through an additional configuration parameter delivered once Sun Ray services are restarted. Use the utadm -A
subnetcommand as follows to configure DHCP service for clients on a shared subnet.
Configure the external DHCP service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the clients on this subnet is beyond the scope of this document. Note the following guidelines:
If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. The most likely location for such a Relay Agent would be on a router in this subnet, in this case, the router named
r22-59in Figure 19.1, “Example of Alternate Shared Network Topology”. For a brief introduction to this topic, refer to Section 19.5, “Sun Ray Client Initialization Requirements Using DHCP”.An existing external DHCP service might need to have its IP address allocation increased for this subnet to support the new clients. This requirement applies whenever additional DHCP clients are placed on a subnet. You might also want to reduce the lease time of addresses on this subnet so that addresses become eligible for re-use quickly.
Arrange to deliver DHCP traffic to the Sun Ray server.
Because the Sun Ray server does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver the subnet's DHCP traffic to the Sun Ray server. The most likely location for such a Relay Agent would be on a router in this subnet, in this case, the router named
r22-59in Figure 19.1, “Example of Alternate Shared Network Topology”. For a brief introduction to this topic, refer to Section 19.5, “Sun Ray Client Initialization Requirements Using DHCP”.If
r22-59is running the Cisco IOS, theip helper-address commandcan be used to activate its DHCP Relay Agent to relay DHCP broadcasts from its 10/100 Ethernet port number 4 to the Sun Ray server at130.146.59.5r22-59> interface fastethernet 4 r22-59> ip helper-address 130.146.59.5 r22-59>
If the external DHCP service also lacks a connection to this subnet, configure a DHCP Relay Agent to forward requests from the client to the following services:
The external DHCP service so that the client can obtain basic networking parameters
The DHCP service on the Sun Ray server so that the client can obtain additional parameters
The Cisco IOS
ip helper-addresscommand accepts multiple relay destination addresses, so if, for example, the external DHCP service could be contacted at130.146.59.2on subnet B in Figure 19.1, “Example of Alternate Shared Network Topology”, the appropriate sequence would be:r22-59> interface fastethernet 4 r22-59> ip helper-address 130.146.59.2 130.146.59.5 r22-59>
NoteDetails of the IOS interaction vary according to the specific release of IOS, the model of the router, and the hardware installed in the router.
Configure the Sun Ray server to provide additional parameters to the shared subnet.
Use the utadm -A
subnetcommand to configure DHCP service for clients on a shared subnet. In this example, the shared subnet has network number130.146.22.0, so the appropriate command is utadm -A 130.146.22.0.# /opt/SUNWut/sbin/utadm -A 130.146.22.0 Selected values for subnetwork "130.146.22.0" net mask: 255.255.255.0 no IP addresses offered auth server list: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.22.1 Accept as is? ([Y]/N): n new netmask:[255.255.255.0] Do you want to offer IP addresses for this subnet? (Y/[N]): new auth server list: [130.146.59.5] To read auth server list from file, enter file name: Auth server IP address (enter <CR> to end list): If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N): new firmware server: [130.146.59.5] new router: [130.146.22.1] 130.146.22.6 Selected values for subnetwork "130.146.59.0" net mask: 255.255.255.0 no IP addresses offered auth server list: 130.146.59.5 firmware server: 130.146.59.5 router: 130.146.22.6 Accept as is? ([Y]/N): ### Building network tables - this will take a few minutes ### Configuring firmware version for Sun Ray All the units served by "helios" on the 130.146.22.0 network interface, running firmware other than version "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their next power-on. ### Configuring Sun Ray Logging Functions ### stopped DHCP daemon ### started DHCP daemon #
In this example, the default values initially suggested by utadm were not appropriate. Specifically, the default router address to be used by clients on this subnet was not correct because utadm guesses that the address of the default router for any shared subnet will have a host part equal to 1. This was a great guess for the directly connected subnet B in Figure 19.1, “Example of Alternate Shared Network Topology”, but it is not correct for subnet C.
The appropriate router address for clients on this subnet is
130.146.22.6(port 4 of routerr22-59), so the administrator repliednto the firstAccept as is?prompt and was given the opportunity to provide alternative values for the various parameters.Restart Sun Ray services on the Sun Ray server by issuing the utstart command to fully activate Sun Ray services on the shared subnet.
# /opt/SUNWut/sbin/utstart A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.
In this example, deploying clients on subnet D in Figure 19.1, “Example of Alternate Shared Network Topology”, the answers to the three predeployment questions are as follows:
From which DHCP server will clients on this subnet get their basic IP networking parameters?
From an external DHCP service.
From which DHCP server will clients on this subnet get additional configuration parameters to support features such as firmware download?
The clients will not be supplied with the additional parameters required to support firmware download or to activate other advanced client features.
How will clients on this subnet locate their Sun Ray server?
The external DHCP service will supply a single additional parameter to inform the client of the location of a Sun Ray server.
In this example, the Sun Ray server does not participate in client initialization at all. Configuration steps are still required on the Sun Ray server because it responds by default only to clients located on directly connected dedicated interconnects. It responds to clients on shared subnets only if the utadm -L on command has been executed. Running the utadm -A
subnetcommand to activate DHCP on the Sun Ray server for a shared subnet, as in this example, implicitly executes utadm -L on. If utadm -Asubnethas not been run, the administrator must run utadm -L on manually to enable the server to offer sessions to clients on the shared subnet.
Configure the external DHCP service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the clients on this subnet is beyond the scope of this document. However, for this example, assume that DHCP service is provided by Cisco IOS-based router
r22-71in Figure 19.1, “Example of Alternate Shared Network Topology”, attached to the130.146.71.0subnet through its 10/100 Ethernet port 3. This router can be configured to provide basic networking parameters and the location of a Sun Ray server as follows:r22-71> interface fastethernet 3 r22-71> ip dhcp excluded-address 130.146.71.1 130.146.71.15 r22-71> ip dhcp pool CLIENT r22-71/dhcp> import all r22-71/dhcp> network 130.146.71.0 255.255.255.0 r22-71/dhcp> default-router 130.146.71.4 r22-71/dhcp> option 49 ip 130.146.59.5 r22-71/dhcp> lease 0 2 r22-71/dhcp> ^Z r22-71>
NoteDetails of the IOS interaction vary according to the specific release of IOS, the model of router and the hardware installed in the router.
DHCP option 49, the standard option of the X Window Display Manager, identifies
130.146.59.5as the address of a Sun Ray server. In the absence ofAltAuthandAuth-Srvrvendor-specific options, the client tries to find a Sun Ray server by broadcasting on the local subnet. If the broadcasts evoke no response, the client uses the address supplied intoption of the X Window Display Manager.NoteThis example is an unorthodox use of the option of the X Window Display Manager, but in a remote subnet deployment where vendor-specific options can not be delivered, it might be the only way of putting a client in touch with a server.
Configure the Sun Ray server to accept client connections from shared subnets by running utadm -L on.
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utstart must be run before LAN connections will be allowed #
Restart Sun Ray services on the Sun Ray server by issuing the utstart command to fully activate Sun Ray services on the shared subnet.
# /opt/SUNWut/sbin/utstart A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.
