Cisco Subscriber Edge Services Manager Troubleshooting Guide 3.3
SESM Problems and Resolutions
Downloads: This chapterpdf (PDF - 346.0KB) | Feedback

SESM Problems and Resolutions

Table Of Contents

SESM Problems and Resolutions

Installation Problems and Resolutions

Logging On to SESM Web Portals Problems and Resolutions

Service Activation Problems and Resolutions

Application Startup and Performance Problems and Resolutions

General Issues with JSPs

Captive Portal Troubleshooting

Troubleshooting Approach

Some TCP Redirection Types Not Operational

Redirection Type Turned Off or Misconfigured in captiveportal.xml

Two Redirection Types Assigned to the Same Port in captiveportal.xml

Redirection Type Not Configured on the SSG

Redirections Continuously Occur

Redirected Networks Do Not Match Service Routes

User Name Not Passed in Forms of Redirection for Authenticated Users


SESM Problems and Resolutions


This chapter describes problems you might encounter, possible causes, and corrective actions. Topics are:

Installation Problems and Resolutions

Logging On to SESM Web Portals Problems and Resolutions

Service Activation Problems and Resolutions

Application Startup and Performance Problems and Resolutions

General Issues with JSPs

Captive Portal Troubleshooting

Installation Problems and Resolutions

Table 3-1 describes problems you might encounter with the SESM installation program, possible causes of the problems, and corrective actions.

Table 3-1 Installation Problems and Resolutions 

Symptom
Possible Causes
Corrective Action

The installation program starts but does not complete.

You are running the installation program in silent or console mode.

The silent mode does not work correctly on Windows.

Run the installation program in GUI mode, which is the default run mode.

You are executing the installation program directly from the production CD.

Copy the installation executable file to a local file system and execute the local copy.

You do not have appropriate permissions.

Obtain the following permissions:

Execute permission to run the installation program.

Write permission to the installation directory you specify.

On a Solaris platform, the message No X Server appears.

The Solaris system you are using does not have the X server, which is required for an installation using GUI mode.

Use the console installation mode.

or

Use the unix command: setenv DISPLAY <code> to set X GUI Capabilities on you Unix machine.

During a Linux custom installation, the installation process locks up on the feature selection page.

You make changes too soon after the feature selection page is displayed.

If the installation program locks up, use Ctrl-C on the command line to stop the program. Restart the installation program and proceed as before to the feature selection page. Wait until the window is fully updated, which is typically indicated by a brief flicker in the window. After you see the flicker, proceed with your feature selection as planned. If you do not notice a flicker, wait approximately 10 seconds before proceeding. This duration is dependent on the speed of the target server system.

File Not Found messages appear from Java for files in system level directories (for example, /var on Solaris).

You do not have correct permissions to access the files required to perform the installation.

Perform the installation as root on Solaris, or as a member of the Administrators group on Windows.

The installation is incomplete or files are installed in the incorrect directory.

You do not have the necessary permissions to perform the installation.

The SESM installation program writes to parts of the file system or Windows registry that are only accessible to a privileged user (that is, root on Solaris, or a member of the Administrators group on Windows). The SESM installation must be performed by a privileged user who has access to these resources. Otherwise, the outcome of the installation is unpredictable.

On a Solaris system, you:

1. Removed the contents of a previous SESM installation directory using the rm command instead of uninstalling SESM using the uninstall utility, and

2. Performed a subsequent installation of SESM into the same directory.

1. The preferred way to uninstall SESM is to use the uninstall utility.

2. If uninstalling is not possible, before reinstalling SESM into the same directory, delete the vpd.properties file from the home directory of the person who is performing the installation.

Note If you deploy multiple SESM installations, and you delete the vpd.properties file to recover from removing one of the installations, then you cannot use uninstall.bin to uninstall any of the other installations.

3. Reinstall SESM into a different directory.

The installation program displays errors when it tries to connect to your LDAP directory.

The LDAP directory is not installed or not running, or you have specified incorrect connection information.

Verify the following:

Make sure the LDAP directory is installed and running.

Make sure you specify the correct IP address or DNS host name for the LDAP directory server system. Try pinging the LDAP system from your installation system using the same information you specified to the installation program. If the LDAP directory server was configured with DNS host name, make sure that the name is correctly resolved from the machine you are installing on.

Make sure you specify the correct port number for the LDAP directory.

You have specified incorrect credentials.

Two sets of credentials are required by the SESM installation:

Credentials for the LDAP directory

Credentials for the SESM container on the LDAP directory

Consult your System Administrator to obtain the values that were used during the LDAP directory installation. See the Cisco Subscriber Edge Services Manager Administration and Configuration Guide for more information.

The installation program displays errors when it attempts to install RBAC and extend the directory schema.

The schema has already been extended by a previous SESM installation and the RBAC objects already exist.

No action required. Proceed with the installation.

The user names you specified on the credentials windows do not have sufficient privileges to perform these actions.

Verify the following:

The credentials you entered for access to the LDAP directory (the first set of credentials that the installation program prompts for) was for a user with the ability to modify the Directory Schema.

The credentials you entered for access to the SESM container (the second set of credentials that the installation program prompts for) was for a user with the ability to read/ write to the context you specified. (The context is ou=sesm,o=cisco by default.)

Out of memory exceptions within the application log file.

or

End users reporting authentication failures in what was otherwise a working environment.

The installed java/bin/start.sh script sets the JavaHeap to 64 MB.

Increase the default JavaHeap if you notice these symptoms of insufficient memory. For details, see the Tuning SESM for Optimal Performance chapter in Cisco Subscriber Edge Services Manager Installation Guide

Uninstalling SESM using the GUI interface fails the second time.

If you uninstall SESM the first time, the uninstall program removes everything apart from _jvm and _uninst. However, if you reinstall and then want to uninstall a second time, the _uninst program won't work for uninstalling the second installation.

Use _uninstall2 which is created by the second install if you want to uninstall a second time.


Logging On to SESM Web Portals Problems and Resolutions

Table 3-2 describes problems you might encounter while attempting to log on to a SESM portal such as NWSP, possible causes of the problems, and corrective actions. The problems and corrective actions are described using NWSP but apply to any SESM web portal including customized versions.

Table 3-2 Logging On to SESM Web Portals Problems and Resolutions 

Symptom
Possible Causes
Corrective Action

Browser returns the Unable to Locate Server error.

You are using an incorrect URL.

The URL should be in the following format:

http://server:port

where:

server is the IP address or DNS name is that of the SESM web portal host system or the value localhost

port is the port specified in the startup script (startNWSP)

NWSP was started on port 80 by a user who is not root.

If NWSP is configured to run on the default HTTP port of 80, then the NWSP application must be started by the root user, because port 80 is a reserved port. On Solaris and Linux operating systems to run any application on a reserved port (ie less than 1024), you need to run as root.

Stop NWSP, sign on as root, restart NWSP, and attempt to access the log on page.

The client system (on which the browser is running) does not have connectivity to the system on which the SESM web portal is running.

Verify connectivity by pinging the SESM web portal system from the client system.

The NWSP application is not running or application is not listening on the requested port.

Verify that the SESM application is running.

On Solaris and Linux, enter:

ps -ef |grep startNWSP
ps -ef |grep runRDP

The output shows an active process when NWSP or RDP is running and returns nothing when they are not.

Also try:

netstat -a |grep <PORTNO>

where PORTNO is the port that the application (NWSP or RDP) is configured to listen. If the above command returns nothing, then the application is either not running or not configured to listen for requests on the port specified in the command.

Another really useful command is (this also gives you the process ID):

lsof -i :<PORTNO>

On Windows, enter:

netstat -a | FIND /C "<PORTNO>"

which returns the integer 1 if the application is running, and 0 if it is not.

You are using DNS host name as server in the URL (http://server:port)

Make sure the client can resolve the DNS host name to IP.

Authentication fails.

The shared secrets configured for the various network components do not match.

Note In SESM SPE deployments, the RADIUS server is the SESM RDP application.

Check the following values to make the secret values for any two communicating components match.

On the SSG, enter the show run command and search for the following commands:

For SSG communication with NWSP:

ssg radius-helper key sharedSecretValue

Check the sharedSecretValue against the settings in the SSG MBean in nwsp.xml. The secret can be configured globally for all SSGs or by SSG subnets, as follows:

<Call name="setGlobalAttribute"> 
<Arg>SECRET</Arg> 
<Arg>sharedSecretValue</Arg></Call>

<Call name="setSubnetAttribute">
<Arg>IP</Arg> 
<Arg>SSGIPAddress</Arg></Call>
<Arg>SECRET</Arg> 
<Arg>sharedSecretValue</Arg></Call>

For SSG communication with the RADIUS server:

radius-server key sharedSecretValue

Check this value against the RADIUS server configuration.

For NWSP communication with the RADIUS server, check the following attribute in the AAA MBean in nwsp.xml:

<Set name="secret">sharedSecretValue</Set>

Note Incorrect configuration of this attribute will not result in an authentication failure. It will result in an empty service list.


Check this value against the RADIUS server configuration.

The secret value on RDP is set in the RDP MBean, in rdp.xml. Locate the following MBean class:

jmxname="com.cisco.sesm:name=RDP, 
RADIUSListener=RDP, 
component=RADIUSServerSocket" 

In that class, locate the following attribute:

<Set id="RDPSecret" 
name="secret">sharedSecretValue</Set>

Check this value against the value configured for SSG and NWSP.

Authentication fails (continued)

The connection information configured on various components is incorrect.

Verify the host and port values configured for each of the following items. In all cases, the host can be DNS name or IP address.

On the SSG platform, enter the show run command.

1. To verify SSG communication with NWSP, search for the following line:

ssg default-network ipAddress mask

Check that the default network configured on the SSG encompasses the system that NWSP is running on.

2. Also search for the following line:

ssg radius-helper auth-port 1812

Check that the port in the radius-helper auth-port command matches the port specified in the SSG MBean, in either the global setting or a subnet setting. An example from the nwsp.xml file follows:

<Call name="setGlobalAttribute"><Arg>PORT</Arg> 
<Arg>1812</Arg></Call>

3. To verify SSG communication with a RADIUS server, including RDP, search for the following line:

radius-server host ipAddress auth-port port

Check that the value for ipAddress is correct for the RADIUS server and the port is the configured authentication port on the RADIUS server. (In SPE deployments, this is the address and port number of the RDP.)

The SSG is not included in the client list configured on the RADIUS server.

Most RADIUS servers have a Client List, which is a list of IP addresses that are permitted to query the server for profiles. If no entry appears in the client list for a particular device (for example, an SSG), then the RADIUS server does not respond to any requests sent from that device.

Check that there is an entry in the RADIUS server's client list for the SSG and NWSP (SESM RADIUS installation). See documentation from your RADIUS server vendor for details of how to check this information.

In SESM SPE deployments, check to see if RDP is configured with a client list. However, do not use the client shared secret. The client list is optional for RDP. If one is configured, make sure an entry exists for the SSG that is sending access requests to the RDP. The RDP client list is configured in the allowedClients attribute in the RDP MBean. An example from the rdp.xml file follows:

<Set name="allowedClients">
<Array class="java.lang.String">
<Item>ssg1</Item>
<Item>ssg2</Item>
</Array>
</Set>

Subscribers unable to obtain the web portal login screen.

SESM not configured to handle subscribers with web proxy configured on their PC

Modify the configuration for Captive Portal as follows:

1. Using a suitable text editor, open the following file: <SESM>/captiveportal/config/captiveportal.xml

2. Locate the "sesmHostList" section of the file shown below:

<Set name="sesmHostList">
 <Array class="java.lang.String">
  <Item>nwsp</Item>
 </Array>
</Set> 

Where nwsp is the DNS name or IP address as provided in the install. Ensure that all public DNS names and IP addresses for all SESM web portals are included in this list.


3. Save the modified captiveportal.xml file and restart Captive Portal. Subscribers should now be able to obtain the web portal login.

Subscribers should now be able to obtain the web portal login page.

Captive Portal is typically used for proxying requests from unauthorized users. Proxy requests are allowed to the SESM web portal or to hosts in the configured white lists. Unauthorized users are TCP-redirected by SSG to the Captive Portal. This is either to port 8090 due to unauthenticated user redirection or unauthenticated permanent HTTP redirection, or to port 8101 due to authenticated permanent HTTP redirection. See captiveportal/config/ssgconfig.txt for example SSG configuration.

Similarly, the SESM Web Proxy is used for proxying requests from authorized users. By default, the SESM Web Proxy is configured to proxy all requests to the internet. Authorized users are TCP-redirected by SSG to the SESM Web Proxy on port 8102. This is due to the presence of a Service-Info="KW<servergroup> attribute in the profile for the service, which is typically an auto-logon or a prepaid service. See nwsp/config/aaa.properties for an example Internet service profile.

Subscribers unable to login.

If Captive Portal is redirecting to the web portal using HTTPS, then the web portal may not be configured to receive proxy meta-data from Captive Portal or web proxy.

Modify the Jetty-specific configuration file for the web portal application:

1. Using a suitable text editor, open the following file: <SESM>/nwsp/webapp/WEB-INF/web-jetty.xml

2. Locate the "sesmProxyList" section of the file shown below:

<Set name="sesmProxyList">
 <Array type="java.lang.String">
  <Item>captiveportal</Item>
  <Item>127.0.0.1</Item>
  <Item>localhost</Item>
 </Array>
</Set>

where captiveportal is the DNS name or IP address as provided in the install. Ensure that any public DNS names, as well as the IP addresses for the SESM Captive Portal, and the SESM Web Proxy, if different, are included in this list.

3. Save the modified web-jetty.xml file and restart the web portal. Subscribers should now be able to login.

Subscribers unable to access internet.

The Web Proxy application is not running.

Start the SESM Web Proxy using jetty/bin/startWebProxy.sh.

Authentication fails.

or

Authentication initially works, but after a few users are signed on, authentication does not work or users are asked to continuously reauthenticate.

The port bundle host key feature is misconfigured.

More specifically, the port bundle length configured for NWSP does not match the port bundle length configured on the SSG.

If the port-bundle host key feature is configured on SSG, then:

1. The feature must also be configured for NWSP.

2. The bundle length settings configured for NWSP must match the bundle length settings on the SSGs.

To check the port-bundle host key configuration on SSG:

1. From the command line on the SSG platform, enter:

show run 

2. In the resulting output, search for the following line:

ssg port-map enable 

This line, if it is present, indicates that the SSG has port-bundle host key enabled.

3. Now search for the following line:

ssg port-map length integer

If the line exists, it specifies the bundle length setting for the SSG. If the line does not exist, it means that the bundle length was not explicitly set and defaults to 4. Set the bundle length to 4 in the NWSP configuration.

To check the port-bundle host key settings for NWSP:

1. In the SSG MBean, check the BUNDLE_LENGTH attribute in the setGlobalAttribute or setSubnetAttribute calls. An example from nwsp.xml follows:

<Call name="setGlobalAttribute">
<Arg>BUNDLE_LENGTH</Arg><Arg>4</Arg></Call>

2. If bundle length is configured on the SSG, then the NWSP BUNDLE_LENGTH argument must be greater than zero and must match the setting on the SSG.

Note Use the setSubnetAttribute calls if the port-bundle host key is configured differently for different SSGs.

If port bundle host key is enabled on the SSG but the bundle length is set to 0 (a valid bundle length on SSG), then, in NWSP, set the PORT_BUNDLE_HOST_KEY_SWITCH attribute to true and set BUNDLE_LENGTH to 0.

See the Cisco Subscriber Edge Services Manager Administration and Configuration Guide for information about configuring the port-bundle host key feature on SSG.

The Server is Busy error displays in the browser.

Insufficient memory for the number of users logging in.

For memory scaling guidelines, see the Cisco Subscriber Edge Services Manager Installation Guide.

1. Usually, no corrective action required. The SESM application's internal garbage collection capability clears memory and returns to normal service.

2. If the error occurs often, consider increasing the amount of total memory available to the application. This requires a stop and restart of the application.

a. Stop the application.

b. Edit the generic start script used by the application startup script. The script is in:

jetty/bin/start

c. Search for the memory allocation in the java command. For example:

"%JAVA%" -Xms64m -Xmx64m 

d. Increase both memory attributes (initial allocation and total maximum memory) from 64M to a larger number. We recommend specifying the same memory in both attributes.

e. Restart the application.

Single sign-on (SSO) is not working. (Subscribers are required to authenticate more than one time.)

One of the single sign-on attributes is false.

Check the following:

The singleSignOn attribute in the SESM MBean used by NWSP must be true. The line from nwsp.xml follows:

<Set name="singleSignOn" type="boolean">true</Set>

In a SESM SPE installation, check the SSO enabled box on the Users window in CDAT.

For more information about the SSO feature, see the Cisco Subscriber Edge Services Manager Administration and Configuration Guide.

The SSG is not caching profiles.

In a SESM RADIUS installation, the SSG must have the following line in its configuration for SSO to work (PPP users only):

ssg profile-cache

Unable to connect to the Internet using the iPass smart client.

iPass support is disabled by default, and has not been enabled.

Enable iPass support.


Service Activation Problems and Resolutions

Table 3-3 describes problems with SESM service selection, possible causes of the problems, and corrective actions.

Table 3-3 Service Selection Problems and Resolutions 

Symptom
Possible Causes
Corrective Action

The service list is not displayed or not complete.

In a SESM RADIUS installation, communication between NWSP and the RADIUS server is not configured correctly.

In a SESM SPE installation, communication between NWSP and the SPE database is not configured correctly.

NWSP communicates directly with the RADIUS server or SPE database to obtain service profiles.

Check the attributes that specify the IP addresses, ports, and password for the service profile sources:

In a SESM RADIUS installation, check the attributes in the AAA Connection, Service Profile MBean. The same password value is used for both primary and secondary servers. Example lines from the nwsp.xml file are:

<Set name="primaryIP">127.0.0.1</Set>
<Set name="primaryPort" 
type="int">1812</Set>
<Set name="secret">cisco</Set>
<Set name="secondaryIP">127.0.0.2</Set>
<Set name="secondaryPort" 
type="int">1812</Set> 

In a SESM SPE installation, check the attributes in the SPE Connection MBean used by the NWSP application. Each SESM application has its own version of the SPE Connection MBean, located in the application's config directory. For example, nwsp/config/dessauth.xml. Example lines are:

<Set name="URL">ldap://127.0.0.1:389/</Set>
<Set name="principal">cn=admin,ou=sesm,
o=cisco</Set>
<Set name="credentials"></Set>

Note When performing a custom installation make sure that you install the SPE component along with the SESM web portal application.


Service selection or other types of service activation (for example, automatic service connection) does not result in a service connection.

Service profile passwords do not match.

On the SSG, check for the following in the output from the show run command:

ssg service-password servicecisco 

In a SESM RADIUS installation, NWSP sends a RADIUS request to the RADIUS server for the profile. The correct service password must be configured in the AAA MBean. Examples from the nwsp.xml file are:

<Set name="servicePassword">servicecisco</Set>
<Setname="serviceGroupPassword">groupcisco 
</Set>

In a SESM SPE installation, NWSP does not require a service password to retrieve service profiles from the directory.

The service profile contains errors or recent changes to profiles are not being recognized.

1. Check the information in the service profile for accuracy.

2. If changes were recently made to a service or service group profile, the cache timeout period has not yet expired. Wait till the cache timeout period has expired. See Table 3-5 for more information about cache timeouts.

Selecting a service causes the browser to display a message stating that additional quota must be added to the account, and the service is not connected.

The SSG Prepaid Services feature is enabled, and the SESM Captive Portal solution is configured to display this message. The message explains that the the service connection was denied because the time or volume-based quota in the account is used up.

1. Ensure that the subscriber has funds in their account before activating a service.

2. For details on how to check account balances and provide more quota, consult the relevant billing server documentation.

3. If the Service-Info Z subattribute is included in the Service-Info attribute in a service profile and the RADIUS server in your deployment does not support SSG prepaid, remove the Z subattribute. This makes the service a regular SSG service instead of a prepaid service.

4. For more information about configuring the Prepaid feature, see the Cisco SSG documentation.

A service requiring authentication fails to connect.

The wrong information is being provided.

1. Verify that the subscriber is entering the service username and password, and not the session log-in credentials.

2. In a SESM SPE installation, if the subscriber stored the service authentication information on the My Services page, check to make sure the stored information is correct.

Errors in the service profile.

In the case of a Proxy service, check the service profile for the correct IP address, RADIUS port and shared secret of the proxy server.

In the case of a tunnel service, check the service profile for the correct LNS address, tunnel password, tunnel identifier and tunnel type.

Client contact to the service is restricted.

Verify that there is an entry in any Proxy server or LNS client list for the network component that will be making requests of them.

Service connection denied.

The subscriber has open connections to the maximum number of services allowed.

1. To connect to another passthrough, proxy or tunnel service, the subscriber must first disconnect from one of the existing services.

2. The deployer can increase the number of service connections that SSGs allow per subscriber using the ssg max-service command.

3. The deployer can implement a mutually exclusive connection group of services in a service group profiles.

In a SESM RADIUS installation, use the TE subattribute code in a service-group profile

In a SESM SPE installation, use CDAT to enter the information in a service group profile.

When activating a service, the Web Services Gateway or any of the web portals returns an activate=true confirmation but no ServiceObjects are created on the SSG.

Communication failure with the SSG.

Make sure that you are not running SESM as a Demo installation.


Application Startup and Performance Problems and Resolutions

Table 3-4 describes application startup and performance problems, possible causes of the problems, and corrective actions.

Table 3-4 Application Startup and Performance Problems and Resolutions 

Symptom
Possible Causes
Corrective Action

Application does not start and the start script issues the following message on the console at startup:

Could not find java in 
directory 
<$JDK_HOME>/bin. Please 
make sure that you have 
a JDK_HOME 
environmental variable 
set correctly.

The JVM cannot be found.

This could be because:

During installation a wrong JVM location was specified.

An environment variable JDK_HOME was specified with the wrong location of the JVM.

The start script has been modified or a script from a previous SESM version is used that is pointing to a missing JVM.

On any of the installation platforms, you can specify the location of a pre-installed JRE or JDK by starting the installation process on a command line and specifying the javahome parameter, as follows:

installImageName -is:javahome location 

where:
installImageName is the name of the SESM downloaded image. location is the path name for the JRE or JDK.

Or

you can set the environmental JDK_HOME to point on a valid Java:

> setenv JDK_HOME <PATH_TO_JAVA>

Note We recommend that you use the bundled JVM.


If the JVM cannot be found because the start script has been modified or a script from a previous SESM version that is pointing to a missing JVM is used, then correct the start script.

Application does not start and the start script issues the following message on the console at startup:

Java version must be >= 
1.4.2. You are using 
<$JDK_HOME>/bin/java of 
version 
<$JAVA_VERSION>. Please 
make sure that you have 
a JDK_HOME 
environmental variable 
set correctly.

The JVM is of the wrong version. Note that the version check is part of the start script supplied for Unix (start.sh), but is not part of the start script for Windows (start.cmd)

You can check the version of the JVM by executing the following command:

java -version

For details on how to correct the JVM version, see the previous section (Row one of this table).

Application does not start (continued).

The configuration files were moved or the web.xml file was changed to point to the incorrect location.

The SESM installation program places the J2EE web server and SESM configuration files in the correct directories as defined in the application's web.xml file. If the configuration files are moved for any reason, then you must edit web.xml file to reflect the new location of the application's configuration files.

nwsp
webapp
WEB-INF
   web.xml

Change the following section:

<!-- The location of the application home 
directory. This should be given as an absolute 
filename. The default is a relative filename 
assuming the working directory is the install 
root -->

<init-param>
<param-name>application.home</param-name>
<param-value>nwsp</param-value>
</init-param>

<!-- The configuration files to load. These 
files are loaded from <application.home>/config 
directory -->

<init-param>
<param-name>configurations</param-name>
<param-value>dessauth.xml,nwsp.xml,rmi.xml
</param-value>
</init-param>

NWSP issues the following message on the console at startup:

JDK_HOME does not point 
to a valid JDK. JSPs 
will not be compiled.

This message is under a section in the start script that is normally commented out. The start script may issue this message only if you have uncommented the section and the JVM you are using is a JRE instead of JDK. A JRE is acceptable. A JDK is required only if you change JSPs and want to recompile them.

No action is required if you have not changed the JSPs. You can optionally edit the start script to comment out this message.

If you have made changes to the JSPs, you must do the following before those changes will appear in the running application:

Set the JDK_HOME environment variable to point to a JDK.

Recompile or precompile the JSPs. See the Cisco Subscriber Edge Services Manager Administration and Configuration Guide for procedures.

The start script issues the following message on the console at startup:

Note that your java 
home directory is set 
to "The JDK that is set 
by the env. variable" 
by your environmental 
JDK_HOME variable.

This is a standard message that the start script issues to indicate that your Java home is set according to the JDK_HOME environmental variable and not according to the Java home that was set during SESM installation.

This is a proper behavior that does not require any corrections.You can unset the JDK_HOME environmental variable by running:

> unsetenv JDK_HOME

In such cases the SESM application falls back to use the Java that is set in your start script.

Session logs out unexpectedly or subscribers receive Server is busy error.

The application was started with insufficient memory for the number of users logging on.

For memory scaling guidelines, see the Cisco Subscriber Edge Services Manager Installation Guide.

1. Free memory in the currently running application. Freeing memory does not affect current user sessions. To free memory:

a. Access the Application Manager in a browser.

b. Choose the following options in the Application Manager: Configuration >
Deployment > Application Memory

c. Choose the application that returned the error.

d. Click the Free Memory button.

2. If the symptoms occur often, consider increasing the amount of total memory available to the application. This requires a stop and restart of the application.

a. Stop the application.

b. Edit the generic start script used by the application startup script. The script is in:

jetty/bin/start

c. Search for the memory allocation in the java command. For example:

"%JAVA%" -Xms64m -Xmx64m 

d. Increase both memory attributes (initial allocation and total maximum memory) from 64M to a larger number. We recommend specifying the same memory in both attributes.

e. Restart the application.

Performance issues on an AAA server.

AAA is overloaded with interim accounting updates from the SSGs.

Some configuration options that can produce a delay between messages are:

Use interface policing and shaping on the SSG platform. Configure the interface going to the AAA server using values that correspond to the number of requests your AAA server can handle.

Use the SESM RDP application as a proxy RADIUS server. RDP can throttle the number of packets to go to the actual AAA server. Do the following:

a. On the SSG, configure RDP as the RADIUS server.

b. Configure the SESM portal to use the actual RADIUS server.

c. Configure RDP to proxy to the actual RADIUS server. Also configure throttle number.

Slow reaction to requests for web pages or `LOW ON THREADS'/`OUT OF THREADS' warnings in the Jetty logs.

SESM is overloaded.

If these warnings appear all the time, then SESM is not configured properly for the normal load that is applied to it.

If these warnings only appear from time to time, then SESM is not able to handle the bursts of activity that the deployment is receiving.

In both these cases, raise the total number of threads available to the web portals. To do this, open the following file:

<SESM>/jetty/config/nwsp.jetty.xml

Refer to the following section:

<Configure 
jmxname="org.mortbay.jetty:name=Jetty,Server=0,
SESMSocketListener=0">
<Set name="port" type="int"><SystemProperty 
name="application.portno" 
default="8080"/></Set>
<Set name="minThreads" type="int">50</Set>
<Set name="maxThreads" type="int">255</Set>
<Set name="maxIdleTimeMs" 
type="int">60000</Set>
</Configure>

To increase the minimum number of threads to 100, and the maximum number to 500:

<Configure 
jmxname="org.mortbay.jetty:name=Jetty,Server=0,
SESMSocketListener=0">
<Set name="port" type="int"><SystemProperty 
name="application.portno" 
default="8080"/></Set>
<Set name="minThreads" type="int">100</Set>
<Set name="maxThreads" type="int">500</Set>
<Set name="maxIdleTimeMs" 
type="int">60000</Set>
</Configure>

This change does not take effect until the applications are restarted.

It is recommended that the minimum threads should always be 20% of the maximum. Note that raising the threads results in more HEAP being used. It is therefore recommended that you also raise the HEAP allocated to the portal.
Jetty runs low on threads when:
maxThread - used threads + idle threads < minThread
where:

minThreads - Minumum threads waiting to service requests.

maxThread - Maximum thread that will service requests.

*maxIdleTimeMs - Time for an idle thread to wait for a request or read.

lowResourcePersistTimeMs - time in ms that connections will persist if listener is low on resources.

Slow reaction to requests for web pages or `LOW ON THREADS'/`OUT OF THREADS' warnings in the Jetty logs. (continued)

 

These parameters are set in the Jetty configuration file, eg in jetty/config/nwsp.jetty.xml.

For memory scaling guidelines, see theCisco Subscriber Edge Services Manager Installation Guide.

Another possible corrective action is to reduce the idle thread timeout from 60 seconds to around 30 seconds.

Web application is very slow when making an HTTPS request for web pages.

This is because JCE tries to resolve the client name but fails because the DNS server (not the proxy) is down and there is a delay in the size of timeout and retry.

In order to resolve this issue, retry and timeout needs to be configured (done at the OS level, see Solaris, Linux and Windows User Guides).

DNS proxy responds slowly.

If dump is set to true and the std error is printed to remote terminal the DNS proxy may slow down due to the time it takes to print to the remote terminal.

Set dump to false.


Note This can happen in RDP or any other ERP based application.



General Issues with JSPs

Table 3-5 describes problems you might encounter while altering the look and feel of the JSPs, possible causes of the problems, and corrective actions.

Table 3-5 General JSP Problems and Resolutions 

Symptom
Possible Causes
Corrective Action

Changes you make to the JSP look and feel are not reflected in the running application.

The installed web.xml file points to precompiled versions of the JSPs. It does not reference the JSPs in /nwsp/webapp. Thus, changing the JSPs in webapp has no effect if you use the installed web.xml file.

If you do not see changes that you make to a JSP, do either of the following:

Recompile the page when you run the application—See the Cisco Subscriber Edge Services Manager Web Developer Guide for procedures.

Precompile the page before running the application—Run the precompile script in tools/bin.

An international language or font does not display properly on NWSP pages.

Your browser does not have the required font.

To support localization, SESM uses Unicode Transformation Format Version 8 (UTF-8) character representations. UTF-8 supports both 1-byte and double-byte character sets. If your browser does not display the characters for the language that you have chosen on the NWSP Settings page, the characters may not be available in the default setup of the browser. You need to download the character set from the browser vendor's Internet site. For example, to download the Japanese character set, go to one of the following websites:

For the Microsoft Internet Explorer browser, go to the Microsoft website.

For the Netscape browser, go to the Netscape website.

Resource bundles for the language do not exist or are not located in the correct directory.

For instructions on localizing SESM portals, including how to construct translated resource bundles and images for buttons, see the Cisco Subscriber Edge Services Manager Web Developer Guide.

Changes to profiles do not appear to take effect.

Profiles are cached.

No action required. Wait for the duration of the combined timeout time. If the timeouts are too lengthy, adjust the appropriate attributes.

SSG caches subscriber profiles when the following command is enabled:

ssg profile-cache 

(The SSG cache is required when SESM SSO is turned on).

NWSP caches service profiles and sessions:

service and service group profiles —The profileCachePeriodattribute in the SESM MBean configures timeouts for service information. The default setting is 30 seconds (1/2 minute).

sessions—SESM sessions correspond to SSG edge sessions. A session references an account, which represents a subscriber profile. Subscriber profiles are not cached directly in SESM code, however, they are cached in effect due to this reference.

The sessionCachePeriod attribute in the SESM MBean configures timeouts for sessions. The default setting is 120 seconds (2 minutes).


Captive Portal Troubleshooting

This section describes some symptoms, possible causes, and corrective actions for Captive Portal installation and configuration problems. The chapter contains the following topics:

Troubleshooting Approach

Some TCP Redirection Types Not Operational

Redirections Continuously Occur

User Name Not Passed in Forms of Redirection for Authenticated Users

Troubleshooting Approach

The following approach is recommended to configure and troubleshoot a Captive Portal solution:

1. Start with the example configuration in the ssgconfig.txt file. Get this configuration working before proceeding.

2. After the example is working, you can begin to make changes in the configuration. Make changes in the following order:

a. IP addresses

b. Port numbers

c. Server names

Some TCP Redirection Types Not Operational

If some TCP redirections do not seem to be occurring, check whether any of the following configuration problems exist:

Redirection Type Turned Off or Misconfigured in captiveportal.xml

Check the parameters in the captiveportal.xml file:

Make sure that the redirection type is turned on (true). Check these attributes:

UserRedirectOn

InitialCaptivateOn

AdvertisingCaptivateOn

ServiceRedirectOn

Make sure that URL attribute for the redirection type contains valid URL values.

Make sure that the default value for the redirection type contains valid values.

Two Redirection Types Assigned to the Same Port in captiveportal.xml

If you use the same port number for more than one type of redirection in the captiveportal.xml file, only one of the redirections per port is operational. This might happen if, during Captive Portal installation, you change the default port numbers suggested by the installation program, and erroneously reuse the same port number.

The order of precedence that determines which type of redirect is operational on a port is:

1. Unauthenticated user redirections

2. Initial logon redirections

3. Advertising redirections

4. Service redirections

Redirection Type Not Configured on the SSG

Check the SSG configuration to make sure that:

The redirection type is associated with a server group that uses the SESM Captive Portal application (and not the web portal or Message Portal application).

The redirection type is associated with the same port that you specify in the captiveportal.xml file for that redirection type.

The following command associates a specific type of redirection to a server group:

ssg tcp-redirect redirect redirection-type to group-name 

The following command assigns a specific application (using the application's IP address and port) to a server group:

ssg tcp-redirect server-group group-name server ip-address port

For the SESM example solution to work, you must assign the IP address and port of the SESM Captive Portal application to all of your server groups. Do this by using the following values in the above command:

The IP address of the Captive Portal application.

The port that you configured in the captiveportal.xml file for the specific type of redirection. The installation program initially sets these ports. Table 7-1 on page 7-2 shows the port values that are configured at installation time if you accepted all of the default values during installation.

Redirections Continuously Occur

If the browser is continuously redirected to the same page, investigate the following topics:

Redirected Networks Do Not Match Service Routes

The service route for a service, which is defined in the service profile, must exactly match the destination network that you configure in a service redirection for that service.

For example, suppose you want to establish service redirections for a service on network 10.1.1.1. If you define the incoming destination network that is eligible for redirections as follows:

ssg tcp-redirect 
network-list serviceNetwork1
network 10.1.1.0 255.255.255.0

You must then define the service route for the service using the same IP address and mask (10.1.1.0 and 255.255.255.0).

If you define the service route differently (for example, you use 10.1.1.1 and 255.255.255.255), then the service redirection occurs repeatedly. After the first and required service redirection, any subsequent requests are subject to the service redirection, even though the service is connected.

The symptom of this misconfiguration is the continuous redisplay of the redirect URL. For example, in the sample SESM solution, the NWSP service logon page appears each time you click the OK button, even though the service is already connected.

User Name Not Passed in Forms of Redirection for Authenticated Users

If the Captive Portal application is not passing the subscriber name (CPSUBSCRIBER) in the HTTP redirection for username not passed in forms of redirection for authenticated users:

Ensure that the SSG is configured as described in the "Defining Captive Portal Groups and Port Lists" section on page 7-2.

Check the following two attributes in captiveportal.xml. If they are empty, the Captive Portal application does not attempt to retrieve or pass the subscriber name.

messageRedirectSubscriberParam for initial or advertising captivation

serviceRedirectSubscriberParam for unauthorized service redirection


Note When these two attributes are empty, the user name feature is turned off. This might be desirable, for example, for performance reasons.