Sun Ray Server Software 4.1 Administrator’s Guide for Linux

This chapter describes the process of deploying DTUs on shared network segments. It covers the following topics:

• Sun Ray DTU Initialization Requirements
• Network Topology Options
• Network Configuration Tasks
• Network Performance Requirements
• Troubleshooting Tools
• Remote Configuration
• Firmware
• Routerless VPN Capability
• Pop-up GUI
• Remote Loading of Configuration Data
• Ports and Protocols

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 later releases, allowing 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.

---

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 (see TABLE 7-2), 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 (see TABLE 7-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 (see Configure the external DHCP service.). 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).

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

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.”^[2]

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 (see Deployment on a Remote Subnet), 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.

---

Network Topology Options

There are three basic topology options for Sun Ray deployment. DTUs can be deployed on:

• a directly-connected dedicated interconnect.
• a directly-connected shared subnet.
• a remote shared subnet.

A Sun Ray server can support any combination of these topologies, which are shown in FIGURE 7-1.

FIGURE 7-1 Network Topologies for Sun Ray DTU Deployment

Directly-Connected Dedicated Interconnect

The directly-connected dedicated interconnect--often referred to simply as an interconnect--places DTUs on subnets that are:

• directly connected to the Sun Ray server (that is, the server has a network interface connected to the subnet).
• devoted entirely to carrying Sun Ray traffic. Prior to the release of Sun Ray Server Software 2.0, this was the only officially supported Sun Ray topology.

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.

Directly-Connected Shared Subnet

Sun Ray Server Software now supports DTUs on a directly-connected shared subnet, in which:

• the Sun Ray server has a network interface connected to the subnet.
• the subnet may carry a mix of Sun Ray and non-Sun Ray traffic.
• the subnet is generally accessible to the enterprise intranet.

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.

Remote Shared Subnet

Sun Ray Server Software now also supports DTUs on a remote shared subnet. On a remote shared subnet:

• a Sun Ray server does not have a network interface connected to the subnet.
• the subnet can carry a mix of Sun Ray and non-Sun Ray traffic.
• all traffic between the server and the DTU flows through at least one router.
• the subnet is generally accessible to the enterprise intranet.

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.

---

Network Configuration Tasks

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 scenarios:

• Deployment on a Directly-Connected Dedicated Interconnect
• Deployment on a Directly-Connected Shared Subnet
• Deployment on a Remote Subnet

FIGURE 7-2 shows the overall topology and configuration tasks.^[3]

Preparing for Deployment

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.

FIGURE 7-2 Sun Ray Network Topology

Deployment on a Directly-Connected Dedicated Interconnect

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.

Directly-Connected Dedicated Interconnect: Example

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:

# /opt/SUNWut/sbin/utadm -a qfe2
### Configuring /etc/nsswitch.conf
### Configuring Service information for Sun Ray
### Disabling Routing
### configuring qfe2 interface at subnet 192.168.128.0
 Selected values for interface "qfe2"
   host address:         192.168.128.1
   net mask:             255.255.255.0
   net address:          192.168.128.0
   host name:            helios-qfe2
   net name:             SunRay-qfe2
   first unit address:   192.168.128.16
   last unit address:    192.168.128.240
   auth server list:          192.168.128.1
   firmware server:      192.168.128.1
   router:               192.168.128.1
 Accept as is? ([Y]/N): n
 new host address: [192.168.128.1] 192.168.128.3
 new netmask: [255.255.255.0] 
 new host name: [helios-qfe2] 
 Do you want to offer IP addresses for this interface? ([Y]/N):  
 new first Sun Ray address: [192.168.128.16] 
 number of Sun Ray addresses to allocate: [239] 
 new auth server list: [192.168.128.3]  
To read auth server list from file, enter file name:
Auth server IP address (enter <CR> to end list):
If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N):
 new firmware server: [192.168.128.3] 
 new router: [192.168.128.3] 
 Selected values for interface "qfe2"
  host address:           192.168.128.3
  net mask:               255.255.255.0
  net address:            192.168.128.0
  host name:              helios-qfe2
  net name:               SunRay-qfe2
  first unit address:     192.168.128.16
  last unit address:      192.168.128.254
  auth server list:       192.168.128.3
  firmware server: 1      192.168.128.3
  router:                 192.168.128.3
 Accept as is? ([Y]/N): 
### successfully set up "/etc/hostname.qfe2" file
### successfully set up "/etc/inet/hosts" file
### successfully set up "/etc/inet/netmasks" file
### successfully set up "/etc/inet/networks" file
### finished install of "qfe2" interface
### Building network tables - this will take a few minutes
### Configuring firmware version for Sun Ray
        All the units served by "helios" on the 192.168.128.0
        network interface, running firmware other than version
        "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their
        next power-on.
### Configuring Sun Ray Logging Functions
DHCP is not currently running, should I start it? ([Y]/N): 
### started DHCP daemon
#

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
A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.

Deployment on a Directly-Connected Shared Subnet

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

Directly-Connected Shared Subnet: Example 1

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

From the Sun Ray server.

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:

# /opt/SUNWut/sbin/utadm -A 130.146.59.0
  Selected values for subnetwork "130.146.59.0"
    net mask:                  255.255.255.0
    no IP addresses offered
    auth server list:          130.146.59.5
    firmware server:           130.146.59.5
    router:                    130.146.59.1   
  Accept as is? ([Y]/N): n
  netmask: 255.255.255.0 (cannot be changed - system defined netmask)
  Do you want to offer IP addresses for this subnet?  (Y/[N]): y
  new first Sun Ray address: [130.146.59.4]  130.146.59.200
  number of Sun Ray addresses to allocate: [55] 20
  new auth server list:      [130.146.59.5] 
To read auth server list from file, enter file name:
Auth server IP address (enter <CR> to end list):
If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N):
  new firmware server:       [130.146.59.5] 
  new router:                [130.146.59.1] 
  Selected values for subnetwork "130.146.59.0"
    net mask:                255.255.255.0
    first unit address:      130.146.59.200
    last unit address:       130.146.59.219
    auth server:             130.146.59.5
    firmware server:         130.146.59.5
    router:                  130.146.59.1 
    auth server list:        130.146.59.5
 Accept as is? ([Y]/N): 
### Building network tables - this will take a few minutes
### Configuring firmware version for Sun Ray
    All the units served by "helios" on the 130.146.59.0
    network interface, running firmware other than version
    "2.0_37.b,REV=2002.12.19.07.46" will be upgraded at   
    their next power-on.
### Configuring Sun Ray Logging Functions
### stopped DHCP daemon
### started DHCP daemon
#

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
A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.

Directly-Connected Shared Subnet: Example 2

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:

• If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. 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.
• An existing external DHCP service may need to have its IP address allocation for this subnet increased in order to support the new DTUs. (This applies whenever additional DHCP clients are placed on a subnet.) It might also be desirable to reduce the lease time of addresses on this subnet so that addresses become eligible for reuse quickly.

2. Configure the Sun Ray server to accept DTU connections from shared subnets.

Run 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
A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.

Deployment on a Remote Subnet

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.

Remote Shared Subnet: Example 1

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?

From the Sun Ray server.

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:

• If the external DHCP service does not have its own direct connection to this subnet, the administrator must configure a DHCP Relay Agent to deliver DHCP traffic on this subnet to the external DHCP service. 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.
• An existing external DHCP service may need to have its IP address allocation increased for this subnet to support the new DTUs. (This applies whenever additional DHCP clients are placed on a subnet.) It might also be desirable to reduce the lease time of addresses on this subnet so that addresses become eligible for re-use quickly.

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.

r22-59> interface fastethernet 4
r22-59> ip helper-address 130.146.59.5
r22-59>

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 external DHCP service (so that the DTU can obtain basic networking parameters)
• The DHCP service on the Sun Ray server (so that the DTU can obtain additional parameters)

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:

r22-59> interface fastethernet 4
r22-59> ip helper-address 130.146.59.2 130.146.59.5
r22-59>

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.

# /opt/SUNWut/sbin/utadm -A 130.146.22.0
  Selected values for subnetwork "130.146.22.0"
    net mask:              255.255.255.0
    no IP addresses offered
    auth server list:       130.146.59.5
    firmware server:       130.146.59.5
    router:                130.146.22.1
Accept as is? ([Y]/N): n
new netmask:[255.255.255.0] 
Do you want to offer IP addresses for this subnet? (Y/[N]): 
new auth server list:     [130.146.59.5] 
To read auth server list from file, enter file name:
Auth server IP address (enter <CR> to end list):
If no server in the auth server list responds, should an auth server be located by broadcasting on the network? ([Y]/N):
new firmware server:      [130.146.59.5] 
new router: [130.146.22.1] 130.146.22.6
Selected values for subnetwork "130.146.59.0"
    net mask:              255.255.255.0
    no IP addresses offered
    auth server list:       130.146.59.5    
    firmware server:       130.146.59.5
    router:                130.146.22.6
Accept as is? ([Y]/N): 
### Building network tables - this will take a few minutes
### Configuring firmware version for Sun Ray
All the units served by "helios" on the 130.146.22.0
network interface, running firmware other than version
"2.0_37.b,REV=2002.12.19.07.46" will be upgraded at their
next power-on.
### Configuring Sun Ray Logging Functions
### stopped DHCP daemon
### started DHCP daemon
#

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
A warm restart has been initiated... messages will be logged to /var/opt/SUNWut/log/messages.

Remote Shared Subnet: Example 2

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:

r22-71> interface fastethernet 3
r22-71> ip dhcp excluded-address 130.146.71.1 130.146.71.15
r22-71> ip dhcp pool CLIENT
r22-71/dhcp> import all
r22-71/dhcp> network 130.146.71.0 255.255.255.0
r22-71/dhcp> default-router 130.146.71.4
r22-71/dhcp> option 49 ip 130.146.59.5
r22-71/dhcp> lease 0 2
r22-71/dhcp> ^Z
r22-71>

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
A warm restart has been initiated... 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.

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:

• 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 it is good practice always to specify AuthSrvr for the benefit of old (pre Sun Ray Server Software 1.3) firmware, which does not understand the AltAuth option. If neither of these options is supplied, the DTU tries to locate a Sun Ray server by sending broadcasts on the local subnet. If the DTU contains firmware at Sun Ray Server Software 2.0 patch level 114880-01 or later, it resorts to trying 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 DTU to attempt a firmware download. NewTVer contains the name of the firmware version that the DTU should use. If this name does not match the name of the firmware version that the DTU is actually running, the DTU tries to download the desired firmware from a TFTP server at the address given by FWSrvr.
• LogHost must be specified in order for the DTU to report messages through the syslog protocol. Reporting thresholds for major DTU subsystems are controlled by the LogKern, LogNet, LogUSB, LogVid, and LogAppl options.

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.

---

Network Performance Requirements

This section describes the minimal network infrastructure needed to support a Sun Ray implementation.

Packet Loss

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.

Latency

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.

Out-of-Order Packets

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.

Encapsulated Options

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

---

Troubleshooting Tools

utcapture

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.

utquery

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.

OSD Icons

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 B. Recent updates to Sun Ray DTU firmware include OSD icons that are larger and easier to read than previous versions. The icon message codes and DHCP states they display, however, remain the same and are listed in “Invalid Cross-Reference Format” and “Invalid Cross-Reference Format” respectively.

---

Remote Configuration

You can simplify the DHCP configuration of Sun Ray DTUs at remote sites by using the X Window System Display Manager option to supply a list of available Sun Ray servers. This 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 7-1and TABLE 7-2.

A sample DHCP configuration for a Cisco IOS-based router is shown below:

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 DTU 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 is necessary to allow space for the IPSec headers to implement a virtual private network (VPN) connection.

DHCP service, either directly from an ISP or from a home firewall, is also required, to give the router its IP address behind the firewall.

The router’s WAN port either plugs directly into the DSL/Cable modem^[4] or into the home firewall/gateway. The Sun Ray DTU then plugs into one of the four LAN ports on the router. If the router has been configured to supply DHCP parameters to the Sun Ray DTU, it will tell the DTU to try to connect to the appropriate Sun Ray server.

The router should bring up a VPN tunnel when it is plugged in; it should always be on. Each router should be connected to the VPN gateway and programmed with a user name based on an employee’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 DTU.

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 DTU. 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 it cannot do that in all situations. Make sure that the Sun Ray DTU has the latest firmware. Simply installing the latest patch on the server is not sufficient: you must also make sure that the DTU is told to update its firmware and then check that it has been able to do so.

If the DTU has the latest firmware but the problem still occurs, then you should explicitly inform the DTU that it is going to be working with a reduced MTU. You can do this through whatever mechanism you use to give the Sun Ray its basic configuration data, such as DHCP, TFTP or, if the DTU is running GUI-capable firmware, local configuration on the Sun Ray DTU 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 blogs.sun.com. 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 do this and restart the Sun Ray DTU, the DTU reports the new MTU value to the server, and the server adjusts its packet-construction strategy to fit within that MTU. It should no longer send Sun Ray traffic that is too big to be delivered in one piece through the VPN tunnel.

---

Firmware

Local settings on the Sun Ray DTU generally override values obtained from other sources, such as .parms files or DHCP. As such, the ability to clear a setting must be provided so that the value from a .parms file is not overridden and can be used for configuration. For numeric values, enter an empty field; for switch settings, select the Clear button when modifying a setting. The utquery output from a DTU faithfully reflects the values that are defined in the local configuration.

Generic DHCP Parameters

A set of Sun Ray DTUs can now be brought up with nothing more than generic 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 DTUs, 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 is done with the configured domain name appended. Components are stripped successively until the lookup succeeds or there are only two components left in the domain name. If none of those lookup succeeds, 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 option. This can resolve to a list of IP addresses, one of which 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. For details on options that can be used to configure the .parms files, see utfwadm(8).
• A default DNS name for the firmware server, sunray-config-servers, is used when neither option 66 nor FWSrvr is given. Defining it in DNS gives a way to provide 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 allow 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, then an IP address is chosen according to the select keyword.
• When neither a server list nor an AltAuth list is given, 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, a new set of error messages provides additional information that can be useful in diagnosing and correcting the problem. See Firmware Download Diagnostics.

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.

.parms Lookup

There are four ways to specify where to find the firmware server to read both .parms files and actual firmware: the DHCP Sun Ray vendor option FWSrvr, the Firmware Server local configuration value, the generic DHCP option 66 (TFTPSrvr) value, and the default host name sunray-config-servers.

Previous versions of firmware would use these values in this order of priority:

1. Local configuration value (host name or IP address)

2. FWSrvr vendor option (IP address)

3. Option 66 (host name or IP address)

4. sunray-config-servers (default host name)

However, the old behavior was such that only the highest priority value was used, and if the lookup of .parms files failed, the attempt was aborted. The new behavior attempts each of these values in order until it finds one that succeeds. The exception is that if the local configuration value is used and fails, none of the others is attempted. This prevents the overwriting of custom-configured firmware in a situation where the controlling firmware server happens to be temporarily unresponsive.

Additional key/value pairs included in the .parms files are in <key>=<value> format, with case sensitivity and no spaces allowed. Options which take values of 0 or 1 have a default value of 0 if not specified. The following options are allowed:

For a current list of configured keyboards, see the keytable.map file in /opt/SUNWut/lib/keytables.

---

Routerless VPN Capability

Sun Ray Server Software and the most recent firmware provide a VPN solution for remote users that does not require a separate VPN router. The IPsec capability in the Sun Ray firmware allows the Sun Ray DTU to act as a standalone VPN device. The most commonly used encryption, authentication, and key exchange mechanisms are supported, along with Cisco extensions that allow a Sun Ray DTU to interoperate with Cisco gateways that support the Cisco EzVPN protocol.

Although digital certificates are not supported, the security model is identical to that of the Cisco software VPN client. Using a common group name and key for the initial (IKE phase one) authentication exchange, the DTU authenticates the user individually with the Cisco Xauth protocol, either by presenting a fixed user name and password stored in flash or by requiring the entry of a user name and one-time password generated by a token card. See Download Configuration.

---

Pop-up GUI

Sun Ray Server Software provides optional functionality, called the Pop-up Graphical User Interface (Pop-up GUI), which allows the entry of configuration parameters for a Sun Ray DTU from the attached keyboard. Most of these configuration parameters are stored in the DTU’s flash memory. Certain control key combinations are used to invoke this new facility, which provides a tree of menus that can be navigated to set and examine configuration values.

Access Control

To accommodate customers with differing requirements with respect to flexibility and security, two versions of the DTU software are provided.

The Pop-up GUI-enabled version of the firmware is installed at: /opt/SUNWut/lib/firmware_gui. To make the Pop-up GUI available, the administrator must run utfwadm to install the firmware, using the -f option.

Features and Usage

The Pop-up GUI enables several features that require the ability to set and store configuration information on the Sun Ray DTU itself, including:

• Non-DHCP network configuration for standalone operation, when it is impossible to configure local DHCP operation
• Local configuration of Sun Ray specific parameters, such as server list, firmware server, MTU, and bandwidth limits
• DNS servers and domain name for DNS bootstrapping
• IPsec configuration
• Wireless network configuration (used in Tadpole laptops)

To protect the use of stored authentication information, the VPN configuration includes a PIN entry. This enables two-factor authentication for Sun Ray at Home VPN deployments.

The key combinations used to enter this prompt model are unlikely to be used for other purposes. On a regular Sun keyboard, the key combinations are of the form Stop-<x>, where <x> is one of the keys listed in TABLE 7-4. On non-Sun (PC) keyboards, use the key combination Ctrl-Pause-<x>. For hot key values, see TABLE A-3.

FIGURE 7-3 Pop-up GUI Main Menu (Part I)

The arrow at the lower right corner indicates that the menu can be scrolled with the Up and Down arrow keys.

FIGURE 7-4 Pop-up GUI Main Menu (Part II)

The configuration tree for the Main Menu has the following components:

• Servers
• Auth list
  A list of comma-separated server names or IP addresses
• Firmware Server
  Name or IP address of firmware/config server
• Loghost
  IP address of syslog host

• TCP/IP

FIGURE 7-5 Setup TCP/IP Menu

• Type
  DHCP or Static
• DHCP
  MTU only
• Static
  IP address, netmask, router, broadcast address, MTU

• DNS
• Domain name
  One only
• DNS Server list
  List of IP addresses

• VPN/IPsec (Cisco 3000/EzVPN semantics)

FIGURE 7-6 Enable VPN Configuration Policy Toggle

• Enable/Disable switch (toggles with Return key (CR))
• Gateway peer (name or IP address)
• Group name
• Group key
• Xauth user name (if static)
• Xauth password (if static)
• Set PIN
  If the PIN has been set, the user is prompted for it before a locally stored Xauth user name and password are used.
• Diffie-Hellman group
• IKE Phase 1 lifetime
• Session timeout (idle timeout, after which VPN connection is dropped)

• Authentication (for HTTP authentication)
• Enable/Disable switch
• Port number

• Security
• Set password (lock configuration under password control)

• Status
• Version (equivalent to STOP-V)

• Advanced
• Download Configuration
• Keyboard Country Code
• Bandwidth Limit (in bits per second)
• Session Disconnect (STOP-Q)
• Force Compression
• Lossless Compression
• Disallow utload
• Force Full Duplex
• Video (set blanking timeout)

• Clear Configuration (also available with STOP-C)

FIGURE 7-7 Advanced Menu (Part I)

The Download Configuration entry on the Advanced Menu prompts for a server name and file name of a file to be downloaded from the server, in the form <server>:<filename>. The default server is the TFTP server value if defined, and the default file name is config.<MAC>, where <MAC> is the unit’s MAC address in upper-case hexadecimal. This field can be overwritten when selected. Pressing Enter causes the corresponding file to be read and the configuration values parsed and set. For configuration values, see TABLE 7-5.

On success, the user is prompted to save the values, otherwise the previous menu is displayed. No other error indications are given.

Some of the menus have an Exit entry, but the Escape key always invokes one level higher than the current menu. Escape at the top level prompts for any changes to be saved or discarded. If changes have been written to the flash, the Escape key resets the DTU.

The Keyboard Country Code value is a keyboard country code that is applied to a keyboard that returns a country code of 0, for use with non-U.S. keyboards that do not report a country code.

The Session Disconnect setting enables or disables the ability to terminate a session by entering STOP-Q from the keyboard. This is useful when it’s desired to terminate a VPN connection and leave the Sun Ray in a quiescent state. Hitting the Escape key after the session has terminated will cause a reboot of the Sun Ray DTU.

The Force Compression setting sets a tag sent from the Sun Ray DTU to the Xserver telling it to enable compression, regardless of available bandwidth.

FIGURE 7-8 Advanced Menu (Part II)

The Lossless Compression setting disables the use of lossy compression for image data.

The Disallow utload setting disables the ability to explicitly force a firmware load into a DTU. In this way, firmware can be tightly controlled using .parms files or DHCP parameters.

The Force Full Duplex setting allows the DTU to operate correctly when the network port that it is connected to does not auto-negotiate. In that case, the auto-negotiation results in the Sun Ray running at half duplex, which significantly impacts network performance. This setting allows the Sun Ray to operate with better performance in this situation.

---

Remote Loading of Configuration Data

To help avoid error-prone manual entry of configuration data for deployments where pre-configuration is required, you can use the Pop-up GUI to download a configuration to a Sun Ray DTU from a file on a server via TFTP, as indicated in FIGURE 7-7.

The following keywords correspond to configuration values that can be set from Pop-up GUI menus (see Pop-up GUI). To group items that are logically related, some of the keywords take the form <family>.<field>.

The format of the file is a set of <key>=<value> lines, each terminated by a newline character, which are parsed and the corresponding configuration items set (see the sample file below). No whitespace is permitted. Key values are case-sensitive, always lower case, as listed above. Setting a keyword to have a null value results in the configuration value being cleared in the local configuration.

FIGURE 7-9 Sample VPN Configuration File

vpn.enabled=1
vpn.peer=vpn-gateway.sun.com
vpn.group=homesunray
vpn.key=abcabcabc
vpn.user=johndoe
vpn.passwd=xyzxyzxyxzy
dns.domain=sun.com
tftpserver=config-server.sun.com
servers=sunray3,sunray4,sunray2

---

Ports and Protocols

TABLE 7-6 and TABLE 7-7 summarize Sun Ray port and protocol usage. In TABLE 7-6, a double-headed arrow in the Flow column indicates the direction of the initial packet. In most cases the DTU initiates the interaction.

The range of dynamic/UDP ports on the server is constrained to the range defined by the utservices-low and utservices-high UDP service definitions, whose default values in /etc/services are 40000 and 42000 respectively.

• Dynamic/TCP ports on the DTU are in the range 32768-65535.
• Dynamic/UDP ports on the DTU are in the range 4096-65535.
• ALP rendering traffic (ALP-RENDER) always uses a UDP port number greater than 32767 at the DTU.



TABLE 7-6 Sun Ray DTU-to-Server Ports and Protocols

DTU Port	Flow	Protocol	Flow	Server Port	Peer	Importance	Comments
66/UDP (BOOTPC/ DHCPC)	--broadcast->> --unicast->>	DHCP	<-broadcast-- <-unicast--	67/UDP (BOOTPS/DHCPS)	DHCP Service	Mandatory	Network and configuration parameter discovery
Dynamic/ UDP	--unicast->>	TFTP	<-unicast--	69/UDP (TFTP)	TFTP Service	Recommended	Firmware download (Since SRSS 3.1: configuration parameter download)
Dynamic/ UDP	--unicast->>	DNS	<-unicast--	53/UDP (domain)	DNS Service	Optional	Introduced in SRSS 3.1 for server name lookups.
514/ UDP (syslog)	--unicast->>	Syslog	(none)	514/UDP (syslog)	Syslog Service	Optional	Event reporting
Dynamic/ UDP	--broadcast->>	ALP- DISCOVERY	<-unicast--	7009/UDP (utauthd-gm)	Sun Ray Server	Optional	On-subnet Sun Ray Server discovery
Dynamic/ TCP	--unicast->>	ALP- AUTH	<-unicast--	7009/TCP (utauthd)	Sun Ray Server	Mandatory	Presence, control, status
Dynamic/ UDP with port number >= 32768	--unicast-> or --unicast->> when NAT is in use	ALP-RENDER	<<-unicast-- or <-unicast-- when NAT is in use	Dynamic/UDP constrained by utservices-low and utservices-high	Sun Ray Server	Mandatory	On-screen drawing, user input, audio
5498/UDP	--unicast->>	ALP-AUDIO-IN		Dynamic/UDP constrained by utservices-low and utservices-high	Sun Ray Server	Optional	Inbound audio
Dynamic/ TCP	-unicast->>	ALP-DEVMGR	<-unicast--	7011/TCP (utdevmgr)	Sun Ray Server	Optional	Device management
7777/ TCP	--unicast->	ALP-DEVDATA	<<-unicast--	Dynamic/TCP	Sun Ray Server	Optional	Device data transfer
7013/ UDP (utquery)	--unicast->	ALP-QUERY	<<-unicast-- <<-broadcast--	Dynamic/UDP	Any	Optional	utquery support





TABLE 7-7 Sun Ray Server-to-Server Protocols

Sun Ray Server Port	Protocol	Port	Peer	Notes
	<<-ARP->>		All on subnet	IP-to-MAC mapping
Transient	--SYSLOG/UDP unicast->>	514 (SYSLOG)	Syslog Server	Status reporting, if required
7009 (UTAUTHD)	<<-UTAUTHD-GM/UDP->> broadcast or multicast	7009 (UTAUTHD)	Sun Ray Server	Group discovery, if required
7011 (UTDEVMGRD)	<<-UTDEVMGRD/TCP->>	7011 (UTDEVMGR)	SR Group Member	Device control and status
7008 (UTRCMD)	<<-UTDEVMGRD/TCP->	Privileged	SR Group Member	Remote execution
	<<-ICMP ECHO->		Any	Admin: presence (a bug)
7010 (UTAUTH-CB)	<<-UTAUTH-CB/TCP->	Transient	Any	Admin: control and status
7012 (UTDS)	<<-UTDS/TCP->	Transient	Any	Data store, if required
7007 (UTSESSIOND)	<<-UTSESSION/TCP->	Transient	Any	Session members
7011 (UTDEVMGR)	<<-UTDEVMGR/TCP->	Transient	Any	Device clients
1660 (HTTPS)	<<-HTTPS/TCP->	Transient	Localhost	Web GUI, if configured
1660 (HTTP)	<<-HTTP/TCP->	Transient	Localhost	Web GUI, if configured
7007 (UTSESSIOND)	<<-UTSESSION/TCP->	Privileged	Localhost	Session management

^{1 (Footnote) DHCP is an Internet Engineering Task Force (IETF) protocol described in Requests for Comments (RFC) RFC 2131 and RFC 2132.}

^{2 (Footnote) DHCP is derived from an earlier protocol called BOOTP. Some documentation uses these names interchangeably.}

^{3 (Footnote) The /24 suffix in IP addresses indicates the use of Classless Inter Domain Routing (CIDR) notation, which is documented in IETF RFCs 1517, 1518, and 1519}

^{4 (Footnote) A VPN router plugged directly into the DSL or cable modem can be connected only to a Sun Ray DTU.}

Sun Ray Server Software 4.1 Administrator’s Guide for Linux

820-3769

Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved.