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 19.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 19.4, “Alternate Vendor-Specific DHCP Options” lists the vendor-specific options.

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 19.3, “DHCP Service Parameters Available” provides the list of available DHCP service parameters.

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 19.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 19.3, “DHCP Service Parameters Available” and Table 19.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.

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.

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, 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 19.4, “Alternate Vendor-Specific DHCP Options” lists the vendor-specific DHCP options that Sun Ray defines and uses.

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:

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

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.