SESM portals are J2EE web applications that run in a J2EE-compliant web server container. The installed startup scripts for the portal applications start the jetty server that is the container for the portal application. The SESM installation process configures the Jetty server to add the portal application to the container.
Startup Script Names
Start the portal applications using the following startup scripts:
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]
ModeArgument
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 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 located 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
To start SESM portal applications or CDAT, you execute an application-specific script, which calls a generic script:
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
For customized SESM web applications, create an application-specific startup script in this same bin directory.
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
8080 + 100 = 8180
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:
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.
Checks for a valid JVM version and issues appropriate error messages if it finds an incompatible version for the application you want to start. The SESM installation program creates and sets a JDK_HOME variable. The start script checks the version of the JVM that resides in the referenced JDK_HOME variable. If you installed a new JRE or JDK after you installed SESM, you can edit the start script to change the value of JDK_HOME. See Table 1-3 for required JVM versions for the SESM applications.
If the JVM is Version 1.3.1 or greater, starts the application as a server (using the server option).
Starts a Jetty server instance, which uses configuration attributes in the container MBean configuration file to add applications to run in the container.
SystemProperty and Property Assignments in the Start Script
The SESM generic start script assigns values to attributes that are defined with <SystemProperty> and <Property> tags in the installed configuration files. The D option to the Java command makes the assignments, as shown in the following lines from the end of the generic start script:
Table 9-1 Java System Properties in Startup 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 start 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 start script sets $APPDIR to applicationName under the installation directory. The applicationName parameter is passed from the application specific startup script (for example, startNWSP.sh).
installDir
nwsp
or
installDir
rdp
or
installDir
cdat
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 the application specific startup script (for example, startNWSP.sh).
Specified during installation. The default is 8080 for the NWSP, WPA, and PDA portal applications. The default is 8081 for CDAT.
application.ssl.portno=$SSLPORTNO
application.ssl.portno is the port that the web server listens on for secure HTTPS requests from subscribers.
The startup script sets $SSLPORTNO to $PORTNO - 80 + 443.
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 SESM Portals
To access SESM portals, 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:
To override the installed port value, change the application-specific startup script. An example portal application URL is: http://server1:80
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 the portal URL.
Step 5 When the SESM portal application's logon page appears, log in using a valid subscriber ID and password defined in a subscriber profile.
If RDP is configured in Proxy mode, the subscriber profile must exist in the RADIUS server database that the RDP is proxying to.
If RDP is configured in normal (non-Proxy) mode, the subscriber 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:
To stop SESM applications on Solaris and Linux, execute the stop scripts listed in Table 9-2. These scripts do not 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 service scripts with the NWSP, CDAT, and RDP applications. The command syntax is the same for all of the service 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
Estimating Memory and CPU Requirements for SESM Portals
This section documents SESM web portal memory and CPU use while running on Solaris servers.
Baseline System
Recommendations in this section are based upon profiling SESM Release 3.1(7) running on a Solaris 2.6 server with required patches and using Java version 1.2.2.
Factors for Sizing Memory and CPU
The following items are the three main factors for sizing memory and CPU for SESM web portals:
JSP page contents—These guidelines apply to SESM's unmodified example applications. Customization of the JSP's theoretically will not significantly change memory requirements. If changes are done to SESM's model/coding, memory utilization will likely change. Therefore we've also included explanations of SESM's internal memory model and the equations needed to calculate deployment specific memory requirements.
SPE Caching—In SPE/LDAP deployments, SESM takes advantage of the SPE directory object caching, which optimizes run time performance by speeding up the retrieval of service information. The SPE caching requires additional RAM. The cached data is the contents of service and service group profiles.
Subscriber Load—Traffic modeling and failure recovery requirements ultimately drive the design goals of the network and the SESM simultaneous active session load. For example, simultaneous active user sessions can vary from 100% of the user database to 7%.
Note Deployment sites might have additional critical factors affecting the design and development of a robust
network.
SESM Portal Application Memory Requirements
This section provides guidelines for sizing the memory requirements of SESM deployments using Sun servers. The following two tables show:
Per user RAM requirements—Table 9-4 shows the per user memory requirements for logged in sessions and the corresponding memory needs for the SPE/LDAP cached database objects.
Total RAM requirements—Table 9-5 shows thetotalmemory requirements to support 100K users simultaneously logged into SESM and the corresponding memory needs for the SPE/LDAP cached database objects.
Table 9-4 Per User Memory Requirements
Deployment Mode
Application
RAM KB per user session
RAM KB per cached user
Total RAM KB per user
RADIUS
NWSP
3K
N/A
3K
SPE/LDAP
NWSP
25K
1.3K
26.3K
SPE/LDAP
RDP
4K
1.3K
5.3K
Table 9-5 Total Memory Requirements
Deployment Mode
Application
RAM including 15MB Heap (MB per 100K users)
Additional RAM for SPE Cache (MB per 100K Users)
Total RAM (MB per 100K Users)
RADIUS
NWSP
300
N/A
300
LDAP
NWSP
2500
130
2630
LDAP
RDP
400
130
530
Calculating and Setting RAM Requirements
The following equation calculates RAM requirements for RADIUS and LDAP deployments.
JavaHeap is the amount of Java virtual memory to reserve for use by the SESM portal application. This is a predefined block of memory, reserved at application startup. The SESM generic start script (jetty/bin/start.sh) sets the JavaHeap using an argument to the JAVA command. The following line is near the end of the start script:
$JAVA -Xms64m -Xmx64m
The -Xms argument is the initial memory to reserve. The -Xmx argument is the maximum memory to reserve. We recommend using the same numeric value for both. For more information about the Java heap, see:
memRequired represents a block of memory protected within the application's Java Heap to ensure correct operation during overload scenarios. The following line in the nwsp.xml file sets the number of bytes for memRequired:
Note The default setting is 10485760 bytes. However, increasing memRequired to 15MB ensures
correct operation during times of severe stress.
maxConcurrentUsers is the maximum number of concurrently logged on users to SESM that you wish to support.
TotalKbytesPerUser is the estimated amount of memory required to service one subscriber. This number varies depending on the size of the profiles. See Table 9-4 for values.
Symptoms of Insufficient Memory
The installed java/bin/start.sh script sets the Java heap to 64 MB. Consider increasing this default value if you notice these symptoms of insufficient memory:
Out of memory exceptions within the application log file
End users reporting authentication failures in what was otherwise a working environment
Determining CPU Requirements for SESM Portals
This section provides guidelines for determining CPU requirements for servers hosting SESM applications. Consider the following points while using these guidelines:
These guidelines are based upon CPU at 100% utilization with 100% login success. Web server sizing is typically based upon CPU utilization no higher than 80%. Adjust your MHZ values accordingly.
When the MHZ requirement does not map directly to an available Sun Microsystems processor or server, we recommend that you select the next faster CPU, or use multiple processors.
SESM profiling shows that CPU loading is linear in relation to login rate per second. Therefore, we can use a simple multiplier to calculate the processing power (the MHZ) required for any given login load.
Table 9-6 shows the CPU loading multiplier for SESM RADIUS and SPE/LDAP deployments.
.
Table 9-6 CPU Loading Multiplier for SESM Deployments
Application
Deployment Mode
SPARC-II, III CPU Loading Multiplier for SESM Applications
Example
NWSP
RADIUS
5
100 NWSP logins per second:
100 * 5 = 500mhz
NWSP
SPE/LDAP
24
100 NWSP logins per second:
100 * 24 = 2400mhz
RDP
SPE/LDAP
8
100 RDP serviced logins per second:
100 * 8 = 800mhz
Captive Portal
SPE/LDAP
4
100 CP redirects per second:
100 * 4 = 400mhz
RDP Memory Requirements
RDP RAM requirements are affected by the following factors:
Number of users simultaneously logged in and logon rates
Application footprint
DESS cache size—Cache size is configurable. The "Directory MBean" section describes how to set the DESS cache size.
As a 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, increase the RDP memory allocation. Increase memory by editing the RDP startup script.
