With the growing popularity of the Sun Ray thin client computing model and its increasing acceptance in business and research settings, there has been considerable demand for a more detailed description of best practices for deployment on varied existing network topologies. This article describes several common topologies and provides deployment hints and instructions not yet covered in the product documentation. This article is ideal for advanced network administrators.

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 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.

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).

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.