If the mode option is included on the command line, it overrides the default mode specified in the SSD MBean in the nwsp.xml file. If you switch modes using this option, you must make sure that all other configuration parameters are aligned with the mode that you choose. The mode option provides the capability to switch easily between a fully configured deployment (RADIUS or DESS mode) and the demonstration deployment (Demo mode).

Starting RDP

RDP is a Java 2 application that uses the Cisco ConfigAgent and JMX server. It does not use the J2EE HTTP server, and therefore does not have startup files in the Jetty server's bin directory.

Start RDP with the following script:

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

Starting CDAT

CDAT is a J2EE application. 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.

Start CDAT with the following script:

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

Explanation of the NWSP and CDAT Startup Scripts

When you start the NWSP 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 SESM web application and the Jetty server.

Both 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 are startNWSP and startCDAT. These scripts set the following variables:

application name—Identifies the application, either NWSP or CDAT. 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 NWSP and 8081 for CDAT.
: The port number must be unique on the server machine. If multiple SESM applications are running simultaneously on the same server machine, make sure each one listens on a different pertussis 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.

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

8080 + 100 = 8180

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

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

8080 - 80 + 433 = 8443

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 the SESM web application.

Java System Properties in Startup Scripts

Table 5-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 \
  -classpath $CLASSPATH \
  -Djetty.home=$JETTYDIR \
  -Dapplication.home=$APPDIR \
  -Dapplication.log=$LOGDIR \
  -Dapplication.portno=$PORTNO \
  -Dmanagement.portno=$MGMTPORTNO \

Table 5-1: Java System Properties in the Startup Script

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 a subdirectory named jetty under the installation directory.	`installDir` `jetty`
application.home=$APPDIR	application.home is the application's directory name. The startup script sets $APPDIR to a subdirectory named applicationName under the installation directory. The startup script infers the installation directory from the location of the start script itself. The applicationName parameter is passed from another script. (startNWSP.sh, for example).	`installDir` `nwsp`
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, $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`	`installDir` `nwsp` `logs`
application.portno=$PORTNO	application.portno is the port that the SESM web application (or CDAT) listens on for HTTP requests from subscribers. The startup script sets $PORTNO to the portNo parameter passed from another script (startNWSP.sh, for example).	Specified during installation. The default is 8080 for NWSP 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.

Stopping Applications

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

Stopping SESM Applications on Solaris

To stop SESM web applications and their J2EE containers on Solaris, execute the installed stop scripts. None of the scripts take arguments. Table 5-2 lists the script names and locations.

Table 5-2: SESM Stop Scripts on the Solaris Platform

Application	Stop Script Location and Name on Solaris Platforms
NWSP and Jetty	jetty/bin/stopNWSP.sh
CDAT and Jetty	jetty/bin/stopCDAT.sh
RDP	rdp/bin/stoprdp.sh

Stopping SESM Applications on Windows NT

To stop SESM web 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 usage 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 5-3 lists the names and locations of the scripts that add and remove services.

Table 5-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
NWSP	jettybin\nwspsvc.cmd	NWSP Web Application

Memory Requirements for the NWSP Application

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

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

Table 5-4 shows SESM memory requirements in various scenarios. The table includes two memory columns for each scenario.

The Memory Required for Logins is the total memory required for the successful login and authentication of all users, at the indicated login rates.
The Memory Used After Logins is the actual memory used to support the SESM session with connections to the indicated services after logins are completed.

For SESM Release 3.1(1), Cisco supports a maximum of 10,000 concurrently logged in subscribers in RADIUS mode, and 5,000 concurrently logged in subscribers in DESS mode. We have verified the memory requirements in Table 5-4 for one SESM application instance. It is possible, given more memory, to support larger numbers of users.

Table 5-4: SESM Memory Requirements

	RADIUS Mode				DESS Mode
	Three Services: 1 Passthrough 1 Proxy 1 Tunnel		3 Services: 1 Passthrough (Auto) 1 Proxy 1 Tunnel		3 Services 1 Passthrough 1 Proxy 1 Tunnel		3 Services: 1 Passthrough (Auto 1 Proxy 1 Tunnel
Number of Subscribers Logged On¹	Memory Required for Logins (MB)	Memory Used After Logins (MB)	Memory Required for Logins (MB)	Memory Used After Logins (MB)	Memory Required for Logins (MB)	Memory Used After Logins (MB)	Memory Required for Logins (MB)	Memory Used After Logins (MB)
2000	32	15.3	32	17.7	64	48	64	51
4000	48	28.6	64	30	112	100	112	97
6000	80	42.6	96	40	192	145	208	139
8000	96	52.2	112	57.3
10000	128	67.4	144	62
¹The information in this table was obtained using the following login rates: RADIUS mode—20 subscribers per second DESS Mode—10 subscribers per second

The generic startup script sets the amount of Java virtual memory reserved for use by the SESM web application (NWSP). The virtual memory setting is an argument to the java command, which is located at the end of the script, as follows:

$JAVA -Xmx64m

The installed start script sets the java virtual memory to 64MB. Consider changing the default value in the following circumstances:

If you are running the Demo exclusively on a machine running other applications, you might want to decrease the memory size.

Increase the memory if the number of users simultaneously logged on increases. Symptoms of insufficient memory are:

Out of memory exceptions

Messages stating that the web server is unavailable

Table of Contents