| Sun Ray Server Software 3 Administrator's Guide for the Solaris Operating System |    
|
| Sun Ray Server Software 3 Administrator's Guide for the Solaris Operating System |
|
| C H A P T E R 7 |
|
Deployment on Shared Networks |
This chapter describes the process of deploying DTUs on shared network segments. It covers the following topics:
When first introduced, Sun Ray DTUs could be deployed only on dedicated, directly-connected interconnect subnets. Although dedicated interconnects provide reliable service and are easy to configure, they require the full-time commitment of networking equipment, cabling, and host interfaces. This constraint has been removed from SRSS 2.0 and 3, allowing network administrators to deploy Sun Ray DTUs nearly anywhere on an enterprise intranet. The most important advantages of intranet deployment are:
Because Sun Ray DTUs are stateless, they rely entirely on network services to provide the configuration data they need to complete their initialization.
The Sun Ray DTU uses the Dynamic Host Configuration Protocol (DHCP) to obtain this information.[1]
The DTU is a DHCP client that solicits configuration information by broadcasting DHCP packets on the network. The requested information is supplied by one or more DHCP servers in response to the client's solicitations. DHCP service may be provided by a DHCP server process executing on a Sun Ray server, by DHCP server processes executing on other systems, or by some combination of the two. Any conforming implementation of a DHCP service can be used to satisfy the DHCP requirements of the DTU. Sun's Solaris DHCP service is one such implementation. Third-party implementations executing on non-Sun platforms can also be configured to deliver information to Sun Ray DTUs.
The DHCP protocol defines a number of standard options that can be used to inform the client of a variety of common network capabilities. DHCP also allows for a number of vendor-specific options, which carry information that is meaningful only to individual products.
The Sun Ray DTU depends on a small number of standard options to establish its basic network parameters. It depends on several standard and vendor-specific options to provide the additional information that constitutes a complete DTU configuration. If these additional configuration parameters are not supplied, the DTU cannot perform certain activities, the most important of which is the downloading of new DTU firmware. TABLE 7-2 lists the vendor-specific options.
The location of the Sun Ray server is usually conveyed to the DTU through one of a pair of DHCP vendor-specific options, AuthSrvr and AltAuth.[2]
If the DTU does not receive this information, it uses a broadcast-based discovery mechanism to find a Sun Ray server on its subnet. The DTU firmware now goes one step further. If the broadcast-based discovery mechanism fails, the DTU interprets the DHCP standard option (option 49) of the X Window Display Manager as a list of Sun Ray server addresses where it attempts to contact Sun Ray services. This can simplify the DHCP configuration of LAN-deployed Sun Rays by removing the need for a DHCP vendor option to carry this information (see TABLE 7-1).
|
Yes, through broadcast discovery or the X Display Manager standard option |
DHCP enables two stages of parameter discovery. The initial DHCPDISCOVER stage discovers basic network parameters. This stage may be followed by a DHCPINFORM, which finds additional information that was not provided during DHCPDISCOVER.
All Sun Ray DTUs must have access to at least one DHCP service, which provides network parameters in response to a DHCPDISCOVER request from the DTU. DTUs containing firmware delivered with Sun Ray Server Software 2.0 or later can exploit the DHCPINFORM feature. They enable full configuration of the DTU, even when an external DHCP service that is not capable of providing complete configuration data provides the network parameters of the DTU.
DTUs that contain pre-2.0 firmware require all of their configuration information in the initial DHCPDISCOVER phase. They do not attempt a DHCPINFORM step. If the deployment strategy requires a two-step DHCP interaction, such DTUs must be upgraded with Sun Ray Server Software firmware version 2.0 or later before being deployed on a shared subnet.
The DTU sends DHCP requests as broadcast packets that propagate only on the local LAN segment or subnet. If the DTU resides on the same subnet as the DHCP server, the DHCP server can see the broadcast packet and respond with the information the DTU needs. If the DTU resides on a different subnet than the DHCP server, the DTU must depend on a local DHCP Relay Agent to collect the broadcast packet and forward it to the DHCP server. Depending on the physical network topology and DHCP server strategy, the administrator may need to configure a DHCP Relay Agent on each subnetwork to which Sun Ray clients are connected. Many IP routers provide DHCP Relay Agent capability. If a deployment plan requires the use of a DHCP Relay Agent, and the administrator decides to activate this capability on a router, the appropriate instructions can be found in the router documentation, usually under the heading of "DHCP Relay" or "BOOTP forwarding."[3]
In certain cases, an existing enterprise DHCP service provides the DTU with its IP address while a Sun Ray server provides it with firmware version details and Sun Ray server location. If a deployment plan calls for DHCP parameters to be provided to the DTU by multiple servers, and none of those servers is connected to the subnet where the DTU resides, the DHCP Relay Agent should be configured so that the DTUs subnet can deliver broadcasts to all the DHCP servers. For example, in routers controlled by a Cisco IOS Executive, the ip helper-address command activates a DHCP Relay Agent. Specifying multiple arguments to the ip helper-address command enables relaying to multiple DHCP servers.
There are three basic topology options for Sun Ray deployment. DTUs can be deployed on:
A Sun Ray server can support any combination of these topologies, which are shown in FIGURE 7-1.
|
Note - Sun Ray traffic on shared networks is potentially more exposed to an eavesdropper than traffic on a dedicated Sun Ray interconnect. Modern switched network infrastructures are far less susceptible to snooping activity than earlier shared technologies, but to obtain additional security the administrator may choose to activate Sun Ray's encryption and authentication features. These capabilities are discussed in Encryption and Authentication. |
The directly-connected dedicated interconnect--often referred to simply as an interconnect--places DTUs on subnets that are:
The Sun Ray server, which guarantees the delivery of the full set of DTU configuration parameters, is always used to provide DHCP service for a dedicated interconnect.
Sun Ray Server Software now supports DTUs on a directly-connected shared subnet, in which:
On a directly-connected shared subnet, DHCP service can be provided by the Sun Ray server, or some external server, or both. Since the Sun Ray server can see broadcast DHCP traffic from the DTU, it can participate in DTU initialization without requiring a DHCP Relay Agent.
Sun Ray Server Software now also supports DTUs on a remote shared subnet. On a remote shared subnet:
On a remote shared subnet, DHCP service can be provided by the Sun Ray server, by some external server, or by both. For DHCP service on the Sun Ray server to participate in DTU initialization, a DHCP Relay Agent must be configured on the remote subnet, where it collects DHCP broadcast traffic and forwards it to the Sun Ray server.
The addition of directly-connected and remote shared subnet support allows DTUs to be deployed virtually anywhere on the enterprise intranet, subject only to the provision of DHCP service and a sufficient quality of service between the DTU and the Sun Ray server.
The following sections explain how to configure a network to support these deployment scenarios:
FIGURE 7-2 shows the overall topology and configuration tasks.[4]
Before deploying a DTU onto any subnet, the administrator must answer three questions:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
3. How will DTUs on this subnet locate their Sun Ray server?
The answers to these questions determine what configuration steps will let DTUs placed on this subnet initialize themselves and offer Sun Ray sessions to users.
The following sections present examples of DTU deployment on the directly-connected dedicated interconnect A, the directly-connected shared subnet B, and the remote shared subnets C and D shown in FIGURE 7-2.
Subnet A in FIGURE 7-2 is a directly-connected dedicated interconnect. Its subnet will use IP addresses in the range 192.168.128.0/24. The Sun Ray server named helios is attached to the interconnect through its qfe2 network interface, which will be assigned the IP address 192.168.128.3.
In an interconnect scenario, the DHCP service on the Sun Ray server always provides both basic networking parameters and additional configuration parameters to the DTU. The answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
On a directly-connected dedicated interconnect, basic networking parameters are always supplied by the DHCP service on the Sun Ray server.
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
On a directly-connected dedicated interconnect, additional configuration parameters are always supplied by the DHCP service on the Sun Ray server.
3. How will DTUs on this subnet locate their Sun Ray server?
On a directly-connected dedicated interconnect, the DTU is always notified of the location of the Sun Ray server through an additional configuration parameter supplied in Step 2.
This is an example of DHCP service for the directly-connected dedicated interconnect A shown in FIGURE 7-2.
1. Configure the Sun Ray server to provide both basic and additional parameters to the interconnect.
Use the utadm -a ifname command to configure DHCP service for DTUs on an interconnect. In this example, the interconnect is attached through interface qfe2, so the appropriate command is:
In this example, the default values initially suggested by utadm were not appropriate. (Specifically, the suggested value for the server's IP address on the interconnect was not the desired value.) The administrator replied n to the first Accept as is? prompt and was given the opportunity to provide alternative values for the various parameters.
2. Restart Sun Ray services on the Sun Ray server.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the newly-defined interconnect:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages. |
Subnet B in FIGURE 7-2 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 pre-deployment questions are:
1. From which DHCP server will DTUs 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 DTU 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.
2. From which DHCP server will DTUs 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 DTU 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 DTUs without providing additional parameters at all, but since this deprives the DTU of a number of features, including the ability to download new firmware, it is generally undesirable.
Administrators of an already established DHCP infrastructure may be unable or unwilling to reconfigure that infrastructure to provide additional Sun Ray configuration parameters, so it is usually more convenient to have the Sun Ray server provide these parameters. Even when the established infrastructure is capable of delivering the additional parameters, it may be desirable to have the Sun Ray server provide them. This 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 DTU firmware could automatically update the firmware version string that is delivered to the DTU. 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.
3. How will DTUs 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 DTU. If additional configuration parameters are not supplied to the DTU at all, the DTU has no indication of the location of any Sun Ray server. In these circumstances, the DTU attempts to discover the location of a Sun Ray server by using a broadcast-based mechanism. However, the DTUs 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, and no additional parameters are provided to the DTU, 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 "Deployment on a Remote Subnet."
In this example, the answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
3. How will DTUs on this subnet locate their Sun Ray server?
The DTUs will be informed of the location of the Sun Ray server through an additional configuration parameter delivered in Step 2.
1. Configure the Sun Ray server to provide both basic and additional parameters to the shared subnet.
DHCP service for DTUs on a shared subnet is configured through the
utadm -A subnet command. In this example, the shared subnet has network number 130.146.59.0, so the appropriate command is
utadm -A 130.146.59.0:
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.0 subnet because utadm assumes that basic networking parameters, including IP addresses, are provided by some external DHCP service when the DTU 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 at 130.146.59.200, were made available for allocation to DHCP clients on this subnet.
2. Restart Sun Ray services on the Sun Ray server.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages. |
In this example, the answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From an external DHCP service.
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
The DTUs will not be supplied with additional parameters.
3. How will DTUs 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 DTU initialization at all. Why, then, are configuration steps required on the Sun Ray server? The Sun Ray server responds by default only to DTUs located on directly connected dedicated interconnects. It responds to DTUs 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 allow the server to offer sessions to DTUs on the shared subnet.
1. Configure the external DHCP service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs on this subnet is beyond the scope of this document. Bear in mind:
2. Configure the Sun Ray server to accept DTU connections from shared subnets.
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utrestart must be run before LAN connections will be allowed |
3. Restart Sun Ray services on the Sun Ray server.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet::
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages. |
Subnets C and D in FIGURE 7-2 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; it is this characteristic that defines them as remote. The answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs 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 DTU 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.
2. From which DHCP server will DTUs 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 DTU, 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 may be unable or unwilling to reconfigure it to provide additional Sun Ray configuration parameters, so it is usually more convenient to have the Sun Ray server provide them.
Even when the established infrastructure is capable of delivering the additional parameters, it may be desirable to have the Sun Ray server provide them. This enables you to use Sun Ray Server 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 DTU firmware could automatically update the firmware version string delivered to the DTU. 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.
3. How will DTUs 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 DTU. If additional configuration parameters are not supplied to the DTU at all, the DTU 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 DTUs broadcast packets propagate only on the local subnet; 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 is by far the most likely configuration 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 DTU to contact a Sun Ray server--are supplied by an external DHCP. In this case, it is the DHCP service in a Cisco router. This scenario is less than ideal.
No firmware parameters are delivered to the DTU, so it cannot download new firmware. The administrator must make some other arrangement to provide the DTU 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.
|
Note - For examples of shared subnet deployments in which both basic networking parameters and additional parameters are delivered by the Sun Ray server and basic networking parameters are supplied by an external DHCP service (with no additional DTU parameters provided), see Directly-Connected Shared Subnet. |
In this example, in which DTUs are deployed on subnet C in FIGURE 7-2, the answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From an external DHCP service.
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
3. How will DTUs on this subnet locate their Sun Ray server?
The DTUs will be informed of the location of the Sun Ray server through an additional configuration parameter delivered in Step 2.
Use the utadm -A subnet command as follows to configure DHCP service for DTUs on a shared subnet.
1. Configure the External DHCP Service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs on this subnet is beyond the scope of this document. Bear in mind:
2. 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-59 in FIGURE 7-2. For a brief introduction to this topic refer to DHCP Relay Agent.
If r22-59 is running the Cisco IOS, the ip helper-address command can 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 at 130.146.59.5.
If the external DHCP service also lacks a connection to this subnet, configure a DHCP Relay Agent to forward requests from the DTU to:
The Cisco IOS ip helper-address command accepts multiple relay destination addresses, so if, for instance, the external DHCP service could be contacted at 130.146.59.2 on subnet B in FIGURE 7-2, the appropriate sequence would be:
|
Note - Details of the IOS interaction vary according to the specific release of IOS, the model of the router, and the hardware installed in the router. |
3. Configure the Sun Ray server to provide additional parameters to the shared subnet.
Use the utadm -A subnet command to configure DHCP service for DTUs on a shared subnet. In this example, the shared subnet has network number 130.146.22.0, so the appropriate command is utadm -A 130.146.22.0.
In this example, the default values initially suggested by utadm were not appropriate. Specifically, the default router address to be used by DTUs 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 7-2, but it is not correct for subnet C.
The appropriate router address for DTUs on this subnet is 130.146.22.6 (port 4 of router r22-59), 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.
4. Restart Sun Ray services on the Sun Ray server.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/messages. |
In this example, deploying DTUs on subnet D in FIGURE 7-2, the answers to the three pre-deployment questions are:
1. From which DHCP server will DTUs on this subnet get their basic IP networking parameters?
From an external DHCP service.
2. From which DHCP server will DTUs on this subnet get additional configuration parameters to support features such as firmware download?
The DTUs will not be supplied with the additional parameters required to support firmware download or to activate other advanced DTU features.
3. How will DTUs on this subnet locate their Sun Ray server?
The external DHCP service will supply a single additional parameter to inform the DTU of the location of a Sun Ray server.
In this example, the Sun Ray server does not participate in DTU initialization at all. Why, then, are configuration steps required on the Sun Ray server? The Sun Ray server responds by default only to DTUs located on directly connected dedicated interconnects. It responds to DTUs 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 allow the server to offer sessions to DTUs on the shared subnet.
1. Configure the External DHCP Service.
Determining how to configure the external DHCP infrastructure to provide basic networking parameters to the DTUs 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-71 in FIGURE 7-2, attached to the 130.146.71.0 subnet 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:
|
Note - Details 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.5 as the address of a Sun Ray server. In the absence of AltAuth and Auth-Srvr vendor-specific options, the DTU tries to find a Sun Ray server by broadcasting on the local subnet. If the broadcasts evoke no response, the DTU uses the address supplied in t option of the X Window Display Manager--provided that the DTU contains firmware at Sun Ray Server Software 2.0 patch level 114880-01 or later.
2. Configure the Sun Ray server to accept DTU connections from shared subnets by running utadm -L on.
# /opt/SUNWut/sbin/utadm -L on ### Turning on Sun Ray LAN connection NOTE: utrestart must be run before LAN connections will be allowed # |
3. Restart Sun Ray services on the Sun Ray server.
Once the utadm command has completed, issue a utrestart command to fully activate Sun Ray services on the shared subnet:
# /opt/SUNWut/sbin/utrestart Resetting servers... messages will be logged to /var/opt/SUNWut/log/ messages. # |
TABLE 7-2 lists the vendor-specific DHCP options that Sun Ray defines and uses.
|
List of Sun Ray server IP addresses Single Sun Ray server IP addresses Firmware TFTP server IP address |
The DTU can perform its basic functions even if none of these options are delivered during initialization, but some advanced DTU features do not become active unless certain options are delivered to the DTU. In particular:
|
Note - The message formats, contents, and thresholds are intended for use only by service personnel and are not documented intentionally. |
The DHCP Client Class name for all Sun Ray vendor-specific options is SUNW.NewT.SUNW. The DTU cites this name in DHCP requests so that the server can respond with the appropriate set of vendor-specific options. This mechanism guarantees that the DTU is not given vendor options defined for some other type of equipment and that other equipment is not given options that are meaningful only to the DTU.
This section describes the minimal network infrastructure needed to support a Sun Ray implementation.
Before version 2.0, Sun Ray Server Software was intolerant of packet losses, so it was recommended that packet loss not exceed 0.1 percent over any extended period. However, because this is often an impractical requirement in local area (LAN) and wide area (WAN) network Sun Ray deployments, the Sun Ray Server Software has been made much more robust in the face of packet loss. The first version of this improved software was released with the first 2.0 patch, with additional improvements in releases supporting low-bandwidth WAN Sun Ray deployments.
In earlier versions, the server tried to avoid packet loss by severely limiting its use of available bandwidth whenever it encountered packet loss. Because random losses are inevitable in a non-dedicated LAN or WAN network environment, this approach put unnecessary limits on performance.
Sun Ray Server Software has always had the capability to detect and recover quickly from such losses, so avoiding them was a matter of policy more than necessity. The new software is less timid and avoids operating at bandwidth levels that create packet losses. Instead, it tries to send data at the highest possible rate that it can without incurring large losses. By design, it sometimes sends data at a rate that is too great for the capacity of the connection between the server and the client, and thus discovers what that capacity is. With very high demand, sustained packet losses of up to 10 percent may sometimes be seen, but the software continues to operate and update the contents of the screen correctly nevertheless.
Network latency between any Sun Ray client and its server is an important determinant of the quality of the user experience. The lower the latency, the better; latencies under 50 milliseconds for round trip delay are preferred. However, like familiar network protocols such as TCP, the Sun Ray DTU does tolerate higher latencies, but with degraded performance. Latencies up to 150 milliseconds provide usable, if somewhat sluggish, performance.
DTUs that contain Sun Ray Server Software 2.0 firmware or later can tolerate small occurrences of out-of-order packet delivery, such as might be experienced on an Internet or wide-area intranet connection. Current Sun Ray firmware maintains a reordering queue that restores the correct order to packets when they are received out of order. In releases prior to Sun Ray Server Software 2.0, out-of-order packets were simply discarded.
The utcapture utility connects to the Sun Ray Authentication Manager and reports packet loss statistics and round-trip latency timings for each DTU connected to this server. See the utcapture man page to learn more about this command.
The utquery command interrogates a DTU and displays the DTUs initialization parameters along with the IP addresses of the DHCP services that supplied those parameters. It can be helpful in determining whether a DTU was able to obtain the parameters that were expected in a particular deployment and in determining specific DHCP servers that contributed to the DTUs initialization. See the utquery man page to learn more about this command.
Sun Ray DTU on-screen display (OSD) icons contain information that can help the administrator understand and debug network configuration problems. The amount of information encoded into the icons has been significantly expanded in the firmware delivered with Sun Ray Server Software. The icon structure and progression are described in detail in Appendix .
| Sun Ray Server Software 3 Administrator's Guide for the Solaris Operating System | 817-6806 |
|
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.