Cisco CNS Subscriber Edge Services Manager Troubleshooting Guide, 3.1.9
SESM Problems and Resolutions
Downloads: This chapterpdf (PDF - 274.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


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 console mode does not work correctly on Linux or Windows platforms. (The console mode works on Solaris platforms.)

The silent mode does not work correctly on any platform.

See CSCuk32633 in the Release Notes for the Cisco Subscriber Edge Services Manager, Release 3.1(9).

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.

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. See CSCuk37938 in the Release Notes.

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

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

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 chapter "Configuring an LDAP Directory for SESM Deployments" in the Cisco Subscriber Edge Services Manager Deployment 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.)


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 PDA, WAP, and 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 protected port.

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.

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.

On Windows, enter:

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

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

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>

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 or DNS names 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 (RADIUS mode). 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. 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:cisco</Item>
<Item>ssg2:cisco</Item>
</Array>
</Set>

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

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 SPE mode, 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 Web Portal Guide.

The SSG is not caching profiles.

In RADIUS mode, the SSG must have the following line in its configuration for SSO to work:

ssg profile-cache

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 RADIUS mode, communication between NWSP and the RADIUS server is not configured correctly.

In SPE mode, 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 RADIUS mode, 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 SPE mode, 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/spe.xml or 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>

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 RADIUS mode, 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 SPE mode, 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 the cache timeout period. 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.

An authenticated service 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 SPE mode, 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 RADIUS mode, use the TE subattribute code in a service-group profile

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


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.

The JVM cannot be found or is the wrong version.

SESM Release 3.1(9) requires JVM Version 1.3.1x. On Solaris, the startup scripts do not start if the referenced version is earlier than Version 1.3.1.

1. Check the version of the JVM by executing the following command:

java -version

If this command fails or does not show a JVM Version 1.3.1x, follow the instructions in "Verifying Successful Installation and Linking of the JVM" section.

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

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.

The JVM you are using is a JRE, not a JDK.

A JRE is acceptable. A JDK is required if you change a JSPs and want to recompile the

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 Web Developer Guide for procedures.

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 "Running SESM Web Portals" chapter in the Cisco Subscriber Edge Services Manager Web Portal 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.

All interim updates from the SESM solution are sent at the same time.

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.


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

http://www.microsoft.com/japan/

For the Netscape browser, go to:

http://wp.netscape.com/eng/intl/

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

SPE caches subscriber and service profiles. Each SESM application (NWSP, RDP, CDAT, and so on) has its own SPE cache. The timeout values and sizes for these caches are configured in the Directory MBean used by each application. For example, the following configuration files each contain a version of the Directory MBean:

nwsp/config/dessauth.xml 
rdp/config/dessauth.xml

In SESM deployments, an object must time out in two SPE caches (the SPE caches for RDP and for NWSP) before a new version of the profile is downloaded from the SPE database. The default timeout period on each cache is 600 seconds (10 minutes.) Therefore, the default configuration causes a wait of up to 20 minutes before a change is noticed.

NWSP caches service profiles and sessions:

service and service group profiles —The profileCacheTimeout attribute in the SESM MBean configures timeouts for service information. The default setting is 600 seconds (10 minutes).

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 sessionCacheTimeout attribute in the SESM MBean configures timeouts for sessions.


Captive Portal Troubleshooting

See the "Troubleshooting Captive Portal Solutions" chapter in the Cisco Subscriber Edge Services Manager Captive Portal Guide.