Because Sun Ray Clients are stateless, they rely entirely on network services to provide the configuration data they need to complete their initialization.
Each Sun Ray Client must first acquire basic network parameters, such as a valid IP address, on the network to which it is connected.
The Sun Ray Client can also be supplied with additional
configuration information to support advanced product
features, such as the ability to update the Sun Ray Client
firmware and to report exception conditions to a
syslog
service.
The Sun Ray Client must locate and contact a Sun Ray server that can offer desktop services to the Sun Ray user.
The Sun Ray Client uses the Dynamic Host Configuration Protocol (DHCP) to obtain this information.
The Sun Ray Client 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 Sun Ray Client. The Oracle 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 Clients.
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 a number of vendor-specific options that carry information that is meaningful only to individual products. For more information, see Table 20.4, “Alternate Vendor-Specific DHCP Options”.
The Sun Ray Client 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 client configuration. If these additional configuration parameters are not supplied, the client cannot perform certain activities, the most important of which is the downloading of new Sun Ray Client firmware. Table 20.4, “Alternate Vendor-Specific DHCP Options” lists the vendor-specific options.
If an administrator chooses not to make this additional configuration information available to the Sun Ray Clients, 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 clients one-by-one when new firmware becomes available on the server, for example, through a patch or Sun Ray product upgrade.
The location of the Sun Ray server is usually conveyed to the
Sun Ray Client through one of a pair of DHCP vendor-specific
options, AuthSrvr
and
AltAuth
.
If the Sun Ray Client does not receive this information, it uses a broadcast-based discovery mechanism to find a Sun Ray server on its subnet. If the broadcast-based discovery mechanism fails, the Sun Ray Client 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 feature can simplify the DHCP configuration of LAN-deployed Sun Rays by removing the need for a DHCP vendor option to carry this information.
Table 20.3, “DHCP Service Parameters Available” provides the list of available DHCP service parameters.
Table 20.3. 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 |
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 Clients must have access to at least one DHCP
service, which provides network parameters in response to a
DHCPDISCOVER
request from the client. Sun
Ray Clients can exploit the DHCPINFORM
feature, which enables full configuration of the client, even
when an external DHCP service that is not capable of providing
complete configuration data provides the network parameters of
the Sun Ray Client.
The Sun Ray Client sends DHCP requests as broadcast packets
that propagate only on the local LAN segment or subnet. If the
Sun Ray Client resides on the same subnet as the DHCP server,
the DHCP server can see the broadcast packet and respond with
the information the Sun Ray Client needs. If the Sun Ray
Client resides on a different subnet than the DHCP server, the
client 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 might 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." DHCP is derived from an
earlier protocol called BOOTP. Some documentation uses these
names interchangeably.
In certain cases, an existing enterprise DHCP service provides the Sun Ray Client 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 client by multiple servers, and none of those servers is connected to the subnet where the client resides, the DHCP Relay Agent should be configured so that the clients 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. For more information, see Section 20.3.5.2, “Deployment on a Remote Subnet”.
You can simplify the DHCP configuration of Sun Ray Clients at remote sites by using the X Window System Display Manager option to supply a list of available Sun Ray servers. This option eliminates the need for Sun Ray vendor options as well as the need to forward DHCPINFORM requests to a Sun Ray server.
For a more complete treatment of network configuration, including DHCP and vendor-specific options, see Table 20.3, “DHCP Service Parameters Available” and Table 20.4, “Alternate Vendor-Specific DHCP Options”.
The following example is a sample DHCP configuration for a Cisco IOS-based router.
ip dhcp excluded-address 129.149.244.161 ip dhcp pool CLIENT import all network 129.149.244.160 255.255.255.248 default-router 129.149.244.161 option 26 hex 0556 option 49 ip 10.6.129.67 129.146.58.136 lease 0 2
Option 49, the X Window System Display
Manager option, lists IP addresses
10.6.129.67
and
129.146.58.136
as Sun Ray servers. The Sun
Ray Client tries to connect to those servers when it receives
a DHCP response from the router. Option 26 sets the Maximum
Transmission Unit (MTU), which defines the maximum packet size
for the Sun Ray connections, in this case, 1366 bytes rather
than the default Ethernet MTU of 1500 bytes. This setting is
necessary to provide space for the IPSec headers to implement
a virtual private network (VPN) connection.
The DHCP service, either directly from an ISP or from a home firewall, is also required to assign the router its IP address behind the firewall.
The router's WAN port either plugs directly into the DSL/Cable modem or into the home firewall or gateway. The Sun Ray Client then plugs into one of the four LAN ports on the router. A VPN router plugged directly into the DSL or cable modem can be connected only to a Sun Ray Client. If the router has been configured to supply DHCP parameters to the Sun Ray Client, it will instruct the client to try to connect to the appropriate Sun Ray server.
The router should start a VPN tunnel when it is plugged in, which it should always be on. Each router should be connected to the VPN gateway and programmed with a user name based on an user's ID and a random password. The VPN gateway should be configured to allow only Sun Ray traffic to pass, and only to a limited number of hosts, so that users cannot connect anything else to the LAN side of the router and then connect into the corporate network. However, users may connect more than one Sun Ray Client.
Whenever a VPN or other tunnel is being used, you need to take account of the IP MTU across the path between the server and the Sun Ray Client. The VPN typically packs additional control data into each packet, which reduces the available space for application data.
The latest Sun Ray firmware attempts to compensate for this reduction automatically, but this process is not always possible. Make sure that the Sun Ray Client has the latest firmware. Installing the latest patch on the server is not sufficient. You must also make sure that the client was configured to update its firmware and then check that the update occurred.
If the Sun Ray Client has the latest firmware but the problem still occurs, then the client must be set to work with a reduced MTU. You can update the client through whatever mechanism you use to give the Sun Ray its basic configuration data, such as DHCP, TFTP or, if the client is running GUI-capable firmware, local configuration on the Sun Ray Client itself.
The site should know what the effective MTU is across the VPN. If not, see any available technical archives or the ThinkThin blog on http://blogs.oracle.com/ThinkThin/. If a precise MTU is not important, then a low estimate, such as 1350 (the standard value is 1500), should be sufficient to let you verify that MTU is the cause of the problem.
After you update and restart the Sun Ray Client, the client reports the new MTU value to the server, and the server adjusts its packet-construction strategy to fit within that MTU. The client should no longer send Sun Ray traffic that is too big to be delivered in one piece through the VPN tunnel.
Local settings on the Sun Ray Client generally override
values obtained from other sources, such as
.parms
files or DHCP. Therefore, you must
provide the ability to clear a setting so that the value
from a .parms
file is not overridden and
can be used for configuration. For numeric values, include
an empty field. For switch settings, click the Clear button
when modifying a setting. The utquery
output from a client reflects the values that are defined in
the local configuration.
A set of Sun Ray Clients can be started with only standard DHCP parameters, shifting the burden of defining the server list to the Domain Name Service (DNS) and firmware management to TFTP.
If sunray-config-servers
and
sunray-servers
are defined appropriately by
the DNS serving a set of remote Sun Rays Clients, no extra
DHCP parameters are required other than basic network
information.
A DNS client incorporated in the firmware allows many values to be names rather than IP addresses. Most values can be either a name or an IP address. If a name is specified, the DNS lookup appends the configured domain name. Components are stripped successively until the lookup succeeds or only two components are left in the domain name. If none of those lookups succeed, the name is looked up by itself. If the name itself ends with a dot character ("."), the name is taken to be a rooted name, and it is looked up without domain name components appended.
DHCP option 66 (TFTP server name) is supported as an alternative to the
FWSrvr
vendor-specific option listed in
Section 20.5.6, “Vendor-specific DHCP Options”. This string value must either be a
single IP address or a DNS host name that resolves to a list of IP addresses. If it is a
list of IP addresses, one is chosen randomly.
A firmware maintenance mechanism creates
*.parms
files in
/tftpboot
(one for each model type),
which are read in lieu of using the
NewTVer
DHCP vendor option. Thus,
remote firmware upgrades are possible without DHCP access
to the NewTVer
value. The
*.parms
files contain the version,
hardware revision, and barrier levels, eliminating
unnecessary file reads in cases where the barrier would
have prevented writing the firmware to flash memory. For
details on options that can be used to configure the
.parms
files, see the
utfwadm
man page.
A default DNS name for the firmware server,
sunray-config-servers
, is used when neither option
66
nor FWSrvr
given. Defining this name in DNS
provides the firmware server address without DHCP options, just DNS servers and domain
name.
Inclusion of servers
=_server name list_
and
select
=inorder|random
in the *.parms
files enables
specification of a list of server names and specification
of whether the names should be used in order, or at
random. If a name resolves to multiple addresses, an IP
address is chosen according to the select keyword.
When neither a server list nor an
AltAuth
list is provided, the default
name
sunray-servers
is looked up in DNS and
the list of IP addresses is used in place of the
AltAuth
list.
In the event of an error in the firmware download, error messages provide additional information that can be useful in diagnosing and correcting the problem. See Chapter 16, Sun Ray Client Troubleshooting Icons.
Also, during DNS lookups, a status line in the OSD icon shows the name being looked up and, if one is found, the IP address.
Table 20.4, “Alternate Vendor-Specific DHCP Options” lists the vendor-specific DHCP options that Sun Ray defines and uses.
Table 20.4. Alternate Vendor-Specific DHCP Options
Option Code | Parameter Name | Client Class | Data Type | Required? | Granularity | Max Count | Comments |
---|---|---|---|---|---|---|---|
21 |
|
| IP | Mandatory | 1 | 1 | Single Sun Ray server IP addresses |
22 |
|
| NUMBER | Optional | 2 | 1 | Sun Ray server port |
23 |
|
| ASCII | Optional | 1 | 0 | Desired firmware version |
24 |
|
| IP | Optional | 1 | 1 | Syslog server IP address |
25 |
|
| NUMBER | Optional | 1 | 1 | Log level for kernel |
26 |
|
| NUMBER | Optional | 1 | 1 | Log level for network |
27 |
|
| NUMBER | Optional | 1 | 1 | Log level for USB |
28 |
|
| NUMBER | Optional | 1 | 1 | Log level for video |
29 |
|
| NUMBER | Optional | 1 | 1 | Log level for firmware application |
30 |
|
| NUMBER | Optional | 4 | 1 | Bandwidth cap, value is bits per second |
31 |
|
| IP | Optional | 1 | 1 | Firmware TFTP server IP address |
32 |
|
| NUMBER | Optional | 4 | 1 | Obsolete. Do not use. |
33 |
|
| ASCII | Optional | 1 | 0 | Sun Ray server interface name |
34 |
|
| NUMBER | Optional | 4 | 1 | Obsolete. Do not use. |
35 |
|
| IP | Optional | 1 | 0 | List of Sun Ray server IP addresses |
36 |
|
| NUMBER | Mandatory | 4 | 1 | Firmware Download: barrier level |
The client can perform its basic functions even if none of these options are delivered during initialization, but some advanced client features do not become active unless certain options are delivered to the client. In particular:
AltAuth
and AuthSrvr
indicate the IP addresses of Sun Ray servers. Addresses in
the AltAuth
list are tried in order
until a connection is established. Current firmware
ignores AuthSrvr
if
AltAuth
is provided, but always specify
AuthSrvr
for the benefit of old (pre
Sun Ray Server Software 1.3) firmware, which cannot handle
the AltAuth
option. If neither of these
options is supplied, the client tries to locate a Sun Ray
server by sending broadcasts on the local subnet. The
client tries to contact a Sun Ray server at the address
supplied in the option of the X Window Display Manager if
that option has been provided.
NewTVer
and FWSrvr
must both be provided in order for the client to attempt a
firmware download. NewTVer
contains the
name of the firmware version that the client should use.
If this name does not match the name of the firmware
version that the client is actually running, the client
tries to download the desired firmware from a TFTP server
at the address given by FWSrvr
.
LogHost
must be specified in order for
the client to report messages through the syslog protocol.
Reporting thresholds for major client subsystems are
controlled by the LogKern
,
LogNet
, LogUSB
,
LogVid
, and LogAppl
options.
Because the message formats, contents, and thresholds are intended for use only by service personnel, they are not documented here.
The DHCP Client Class name for all Sun Ray vendor-specific
options is SUNW.NewT.SUNW
. The client 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 client is not sent vendor options defined
for some other type of equipment and that other equipment is
not sent options that are meaningful only to the client.
For each parameter name, there is a vendor ID, an option code, an option type, and an indication as to whether the parameter is mandatory.
Vendor-specific options are delivered through encapsulated options in DHCP. Encapsulated options are somewhat more complicated, as illustrated in the following DHCPINFORM response, or DHCPACK, which shows the taxonomy of the bytes in the vendor-specific information portion.
2b 4a 17 1d 32 2e 30 .......: .+J..2.0 0140 5f 31 39 2e 63 2c 52 45 56 3d 32 30 30 32 2e 30 _19.c,RE V=2002.0 0150 39 2e 30 36 2e 31 35 2e 35 34 21 04 68 6d 65 30 9.06.15. 54!.hme0 0160 1f 04 81 92 3a 88 15 04 81 92 3a 88 1d 01 06 1c ....:... ..:..... 0170 01 06 1b 01 06 1a 01 06 19 01 06 18 04 81 92 3a ........ .......: 0180 88 16 02 1b 61
In this description, hexadecimal values are preceded by 0x
and followed by their decimal value, after an
=
sign, as in 0x2b=43
.
The first byte is the option code.
The next byte represents the encapsulated option length, that is, the number of bytes that make up the option value.
The next one or more bytes make up the multi-byte option value.
The option value is followed by another encapsulated option code, and so on.
The example begins with 0x2b=43
, the DHCP
option for vendor-specific information. It has a length of
0x4a=74
bytes, which is the total number of
bytes that follow. These bytes contain the encapsulated vendor
options.
The remainder of the example represents the value of the
vendor-specific information options. The first byte contains
the first encapsulated option, whose value is
0x17=23
, and the NewTVer
option, whose value type is ASCII. The next byte is
0x1d=29
, which is the length of the
NewTVer
string. These options are followed
by 29 bytes that represent the string itself.
The ASCII interpretation at the right of the DHCPACK, is
2.0_19.c,REV=2002.09.06.15.54
. This is the
end of the first encapsulated option. The next byte is the
beginning of the next option, Intf, represented by
0x21=33
. The next byte, the length, is
0x04=4
, and the next four bytes are the
ASCII value hme0
. That's the end of the
second encapsulated option.
The next byte is 0x1f=31
, which represents
the FWSrvr parameter, whose function is to indicate the IP
address of the firmware TFTP server. The next byte is the
length, 4
, which is always be true for an
IP address. The hexadecimal value is 0x81 0x92 0x3a
0x88
, which corresponds to the IP address
129.146.58.136
.