Platform	Startup Scripts
Solaris and Linux	`jetty/bin/startNWSP.sh [-mode mode] jetty/bin/startWAP.sh [-mode mode] jetty/bin/startPDA.sh [-mode mode] jetty/bin/startCAPTIVEPORTAL.sh [-mode mode] jetty/bin/startMESSAGEPORTAL.sh [-mode mode]`
Windows NT	`jetty\bin\startNWSP.cmd [mode] jetty\bin\startWAP.cmd [mode] jetty\bin\startPDA.cmd [mode] jetty\bin\startCAPTIVEPORTAL.cmd [mode] jetty\bin\startMESSAGEPORTAL.cmd [mode]`

Mode Argument

The startup scripts accept an optional command-line argument for specifying the run mode of the portal application. This option provides the capability to switch easily between a fully configured deployment (RADIUS or LDAP mode) and the demonstration deployment (Demo mode).

If the mode argument is included on the command line, it overrides the default mode specified in the SESM MBean in the portal application configuration file. If you switch modes using the command line option, you must make sure that all other configuration attributes are aligned with the mode that you choose.

Valid values for mode are:

Demo—This mode uses configuration attributes in the SESMDemoMode MBean in the application configuration file.
RADIUS—This mode uses configuration attributes in the SESM, SSG, and AAA MBeans in the application configuration file.
LDAP—This mode uses configuration attributes in the SESM and SSG MBeans in the application configuration file, as well as attributes in the RDP and dess-auth configuration files.

Starting RDP

Start RDP using the following script:

Platform	Script
Solaris and Linux	`rdp/bin/runrdp.sh`
Windows NT	`rdp\bin\runrdp.cmd`

RDP is a Java 2 application that uses the Cisco ConfigAgent and JMX server. RDP does not use the J2EE HTTP server. Therefore, its startup file is not located in the Jetty server's bin directory.

Starting CDAT

Start CDAT using the following script:

Platform	Script
Solaris and Linux	`jetty/bin/startCDAT.sh`
Windows NT	`jetty\bin\startCDAT.cmd`

CDAT is a J2EE application; therefore, the startup script for CDAT is in the Jetty server's bin directory. This startup script calls the same generic startup script used by the SESM web applications.

Startup Script Explanation

When you start an SESM portal application or CDAT, you are executing two scripts:

Application-specific startup script—Sets application-specific parameters and calls the generic script
Generic startup script—Infers additional parameters and starts the Jetty server, which in turn adds the portal application to the container.

All of the scripts are located in:

jetty

bin

You should create an application-specific startup script in this same bin directory for customized SESM web applications.

Application-Specific Startup Scripts

The application-specific startup scripts set the following variables:

application name—Identifies the application name. The generic startup script derives path names for configuration files and the docroot subdirectory from the application name. If you create a customized application, provide the name that identifies your application. See the "SESM Application Names" section for information about using a new application name value.
port number—Identifies the port that the application's container (the web server) will listen on.

: The installation program updates the application startup script with the port number that you provide during the installation time. To change the port number after installation, edit the startup script. The default values displayed by the installation program are 8080 for an SESM portal application and 8081 for CDAT.
: The port number must be unique on the server machine. If multiple SESM portal applications are running simultaneously on the same server machine, make sure each one listens on a different port. This caveat applies whether you are running two instances of the same application or two different applications.

Generic Startup Script

The generic startup script derives two other port numbers from the application port number:

It derives a management console port number as follows.

application port + 100

: For example, if you are using the default application port of 8080 for NWSP, the management console port for NWSP is

It derives a secure socket listener (SSL) port as follows:

application port - 80 + 443

: Starting with the default application port value of 8080, the default SSL port is:

The generic startup script does the following:

Accepts the variables passed to it from the application startup script
Sets additional variables, based on the expected (installed) directory structure. For example, it infers the location of the configuration files.
Starts a Jetty server instance, which uses configuration attributes in the container MBean configuration file to add applications to run in the container.

Java System Properties in Startup Scripts

Table 9-1 describes the java system properties that are set by the generic startup script and how the assigned values are derived. The table describes the following lines, which are located at the end of the generic startup script:

$JAVA -Xmx64m -Xmx64m\
  -classpath $CLASSPATH \
  -Djetty.home=$JETTYDIR \
  -Dapplication.home=$APPDIR \
  -Dapplication.log=$LOGDIR \
  -Dapplication.portno=$PORTNO \
  -Dmanagement.portno=$MGMTPORTNO \

Table 9-1: Java System Properties in Startu p Scripts

System Property and Variable Name	Explanation	Installed Values in the Start Script
jetty.home=$JETTYDIR	jetty.home is the container's directory name. The startup script sets $JETTYDIR to the value `jetty` under the installation directory.	`installDir` `jetty`
application.home=$APPDIR	application.home is the application's directory name. The startup script sets $APPDIR to applicationName under the installation directory. The applicationName parameter is passed from another script. (for example, startNWSP.sh).	`installDir` `nwsp` or `installDir` `rdp` or `installDir` `cdat`
application.log=$LOGDIR	application.log is the location of all log files created for this application.	The startup script sets $LOGDIR differently according to the platform: On Solaris and Linux, $LOGDIR is the logs directory under the application directory in the install directory. For example: installDir`/nwsp/logs` On Windows NT, $LOGDIR is userTemp\application\logs where userTemp is the administrator's temporary directory. For example: `temp\nwsp\logs`
application.portno=$PORTNO	application.portno is the port that the web server listens on for HTTP requests from subscribers. The startup script sets $PORTNO to the portNo parameter passed from another script (for example, startNWSP.sh).	Specified during installation. The default is 8080 for the SESM portal applications and 8081 for CDAT.
management.portno=$MGMTPORTNO	management.portno is the console port that displays the current values for all attributes in all of the MBean configuration files.	The startup script sets $MGMTPORTNO to $PORTNO + 100.

Logging On to a SESM Portal Application

To access an SESM portal application, such as the NWSP application, follow these procedures:

Step 1 Start the SESM portal application using its startup script.

Step 2 Start a web browser on a device (such as a desktop computer, a WAP phone, or a PDA) that has network access to the server on which the SESM portal application is running.

Step 3 Make sure the web browser has Javascript enabled.

Step 4 Go to the URL of the SESM portal application:

http://  host:port

The URL consists of the host and port number that you specified during the SESM portal application installation, or whatever is currently specified in the portal application's startup script. An example portal application URL is:

http://server1:80

Default values used during an SESM installation are:

http://localhost:8080

Note If the captive portal unauthenticated user redirect feature is implemented and correctly configured and the corresponding TCP redirect features are correctly configured on the SSG, subscribers are redirected to the captive portal application without entering an URL.

Step 5 When the SESM portal application's logon page appears, log in using a valid user ID and password. A valid user ID and password is defined in user profiles as follows:

In RADIUS mode, the user profile must exist in the RADIUS server database. See "Configuring RADIUS for SESM Deployments," for more information.
In LDAP mode:

If RDP is configured in Proxy mode, the user profile must exist in the RADIUS server database that the RDP is proxying to.
If RDP is configured in normal (non-Proxy) mode, the user profile must exist in the LDAP directory in the SPE-specified format. See the Cisco Distributed Administration Toolkit Guide for more information.

Note Refer to the Subscriber Edge Services Manager Solutions Guide for instructions on demonstrating the NWSP application running in Demo mode.

Stopping Applications

This section describes how to stop SESM applications. It includes the following topics:

Stopping SESM Applications on Solaris and Linux

To stop SESM applications on Solaris and Linux, execute the stop scripts listed in Table 9-2. None of the scripts accept arguments.

Table 9-2: SESM Stop Scripts on the Solaris and Linux Platforms

Application	Stop Script Path Names (Solaris and Linux platforms only)
SESM portals and Jetty	`jetty/bin/stopNWSP.sh jetty/bin/stopWAP.sh jetty/bin/stopPDA.sh jetty/bin/stopcaptiveportal.sh jetty/bin/stopmessageportal.sh`
CDAT and Jetty	`jetty/bin/stopCDAT.sh`
RDP	`rdp/bin/stoprdp.sh`

Stopping SESM Applications on Windows NT

To stop SESM applications and their J2EE containers on Windows NT platforms, you can:

Open the Task Manager window, select the appropriate task, and click the End Task button. If you are prompted again, click the End Now button.
If you added the application as an NT service, you can use the Services window to stop the service. Open Control Panel > Services or Control Panel > Administrative Tools > Services and select the service you want to stop. Use the menu commands on the Services window to stop the selected service.

Adding and Removing Services on Windows NT

On a Windows NT platform, you can add your applications to the list of Windows NT services. When the application is a service, it appears in the Services window accessed from Control Panel > Services or Control Panel > Administrative Tools > Services You can start and stop any service from this window. Also, you can optionally configure a service to start automatically when the system reboots.

The SESM installation program provides services scripts with the NWSP, CDAT, and RDP applications. The command syntax is the same for all of the services scripts:

scriptName -i installs the application as a service so that it can be managed from the Services window
scriptName -h displays the command usage
scriptName -r removes the application from the Services window

Table 9-3 lists the names and locations of the scripts that add and remove services.

Table 9-3: Scripts for Adding and Removing Services on Windows NT

SESM Application	Services Script Location and Name	Default Service Name
RDP	`rdp\bin\rdpsvc.cmd`	`RDP Application`
CDAT	`jetty\bin\cdatsvc.cmd`	`CDAT Web Application`
SESM portals	`jetty\bin\nwspsvc.cmd jetty\bin\wapsvc.cmd jetty\bin\pdasvc.cmd jetty\bin\captiveportalsvc.cmd jetty\bin\messageportalsvc.cmd`	`NWSP Web Application WAP Web Application PDA Web Application Captive Portal Web Application Message Portal Web Application`

Memory Requirements and CPU Utilization

This section includes the following topics:

SESM Portal Application Memory Requirements

The total java virtual memory requirements for an SESM portal application depends on several factors:

Number of subscribers concurrently logged in
Number of subscribed services
Rate of new logons—The login rate affects transitory memory use.

The most important of these factors is the number of subscribers concurrently logged on. Use the following formula to determine memory requirements for your installation:

requiredJVM = reservedMem + (maxConcurrentUsers * KBPerUser)

Where:

requiredJVM is the amount of Java Virtual Memory (JVM) to reserve for use by the SESM portal application.The generic startup script (jetty/bin/start.sh) sets the JVM. The JVM is an argument to the java command, which is located at the end of the start script, as follows:

$JAVA -Xmx64m -Xmx64m

: The first -X argument is the initial JVM to reserve. The second -X argument is the maximum JVM. We recommend using the same value for both.

reservedMem is 10.4 MB, a constant value that represents the initial memory requirement for the application before subscribers begin to log on.

maxConcurrentUsers is the maximum number of concurrently logged on subscribers that you wish to support.

KBPerUser is the estimated amount of memory required to service one subscriber. This number will vary depending on factors such as how many services the typical subscriber is subscribed to. Suggested values are:

For RADIUS mode: 4.18 KB per subscriber.
For LDAP mode: 29 KB per subscriber.

: See Table 9-4 for additional guidelines in determining an appropriate kbytePerUser figure.

Symptoms of Insufficient Memory

The installed start script sets the java virtual memory to 64 MB. Consider increasing this default value if you notice these symptoms of insufficient memory:

Out of memory exceptions

Messages stating that the web server is unavailable

Verified Memory Requirements

Table 9-4 shows verified memory requirements for the NWSP portal application. We verified these memory requirements using one SESM application instance. It is possible, given more memory, to support larger numbers of users.

Table 9-4: SESM Portal Memory Requirements

SESM Mode	JVM Heap Size (MB) Specified in start script¹	Maximum Users²	KB per user
RADIUS mode	32	4550	4.73
	64	12,800	4.18
	96	20,500	4.17
	128	29,100	4.04
LDAP mode	64	1800	29.73
	96	3000	28.50
	128	5000	23.50
	256	11,000	22.32

¹Includes 10.4 MB reserved memory
²In the verification tests, all users were subscribed to three services: one passthrough, one proxy, and one tunnel

SESM Portal Application CPU Utilization

CPU utilization by an SESM portal application increases as the rate of new logons increases. Table 9-5 shows CPU utilization at specified logon rates for the NWSP portal. These rates are verified using consistent login rates, with all users subscribed to three services. The logon rates indicate successful logon and authentication of all users.

Table 9-5: SESM Portal CPU Utilization

SESM Mode	Logon Rate Sustained until Maximum Users Reached¹	Maximum Users	CPU Utilization on Sun Sparc U5-10 400-MHz server
RADIUS mode	20 logons per second	12,800	20%
	40 logons per second		40%
	60 logons per second		60%
	80 logons per second		80%
	100 logons per second		100%
LDAP mode	10 logons per second	11,000	60%

¹All users are subscribed to three services: one passthrough, one proxy, and one tunnel.

RDP Memory Requirements

The amount of memory RDP uses is roughly proportional to the number of users that are logged in within a fixed period of time. If you find that RDP is running out of memory, increase the amount of memory allocated to the program by editing the startup script.

As a rough guide, RDP requires 64 MB of memory when 5000 users are logged in within any 20 minute period. If the logon rate is likely to exceed this rate, you should increase the RDP memory allocation.

Table of Contents

Startup Script Names

Mode Argument

Symptoms of Insufficient Memory

Verified Memory Requirements