Sun Ray Deployment On Shared Networks
- Sun Ray DTU Initialization Requirements
- Network Topology Options
- Network Configuration Tasks
- Network Performance Requirements
- Troubleshooting Tools
- About the Authors
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article is intended to help network administrators and deployment specialists maximize utilization of existing network infrastructures when they install and configure Sun Ray implementations.
When first introduced, Sun RayTM desktop units (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.
Sun Ray Server Software 2.0 removes this constraint and allows network administrators to deploy Sun Ray DTUs nearly anywhere on an enterprise intranet. The most important advantages of intranet deployment are:
Sun Ray can be deployed on any existing network infrastructure that meets Sun Ray Quality of Service (QoS) requirements.
Sun Ray DTUs can be deployed at a greater distance from their Sun Ray server than is possible with an unrouted Ethernet interconnect.
This article describes the process of deploying DTUs on shared network segments and covers the following topics:
"Sun Ray DTU Initialization Requirements" on page 2
"Network Topology Options" on page 4
"Network Configuration Tasks" on page 7
"Network Performance Requirements" on page 24
Sun Ray DTU Initialization Requirements
Because Sun Ray DTUs are stateless, they rely entirely on network services to provide the configuration data they need to complete their initialization.
Each DTU must first acquire basic network parameters, such as a valid IP address, on the network to which it is connected.
The DTU can also be supplied with additional configuration information to support advanced product features, such as the ability to update the DTU firmware and to report exception conditions to a syslog service.
The DTU must locate and contact a Sun Ray server that can offer desktop services to the Sun Ray user.
The Sun Ray DTU uses the Dynamic Host Configuration Protocol (DHCP) to obtain this information.1
DHCP Basics
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 2 lists the vendor-specific options.
NOTE
If an administrator chooses not to make this additional configuration information available to the Sun Ray DTUs, a procedure must be established to deliver firmware updates to them. One solution would be a small, dedicated interconnect on one Sun Ray server. Then, the administrator can transfer the DTUs one-by-one when new firmware becomes available on the server, for instance, through a patch or Sun Ray product upgrade.
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 first released with patch 114880-01 for Sun Ray Server Software 2.0 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 1).
TABLE 1 DHCP Service Parameters Available
|
Parameters |
Sun Ray Server DHCP Service |
External DHCP service with vendor-specific options |
External DHCP service without vendor-specific options |
No DHCP service |
|
Basic network parameters |
Yes |
Yes |
Yes |
No |
|
Additional parameters (for firmware download, etc.) |
Yes |
Yes |
No |
No |
|
Sun Ray server location |
Yes |
Yes |
Yes, through broadcast discovery or the X Display Manager standard option |
Yes, through broadcast discovery |
DHCPINFORM
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 appliances 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 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. Such DTUs must be upgraded with Sun Ray Server Software 2.0 firmware before being deployed on a shared subnet, if the deployment strategy requires a two-step DHCP interaction.
DHCP Relay Agent
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.