Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Overview of Managing and Controlling Sessions in SBR Carrier

Introduction

SBR Carrier tracks the status of user connections that it authenticates in a current sessions table (CST). Because the CST is based on RADIUS accounting data, the list of active sessions is accurate only if all of your network access servers (NAS) are configured to support RADIUS accounting. To accurately track session activity, you need to ensure:

  • All clients in your configuration support RADIUS accounting
  • All clients are configured to send accounting messages to SBR Carrier

Storing Sessions in the CST in a Standalone Server versus the SSR Cluster

Whether SBR Carrier is running in standalone mode or as part of a cluster, session information is stored in a CST. However, different files are used to set up the CST depending on whether SBR Carrier is running in standalone mode or in a SSR cluster.

Storing Sessions in the CST of a Standalone Server

For a standalone server, the CST is in local memory, and is configured with the dbclusterlocal.gen file when you run the configuration script. In addition, the setting of the PersistSessions parameter in the radius.ini file determines whether sessions are restored or not restored when SBR Carrier is restarted.

You cannot configure field names in the local CST (dbclusterlocal.gen). However, there are three predefined fields and seven generic fields you can configure using the sessionTable.ini file. In order to use any of the ten predefined fields, they must be mapped to attributes by editing the sessionTable.ini file.

Storing Sessions in the CST of the SSR Cluster

In SSR, the CST is stored in the data nodes of the back-end cluster, and is configured with the dbclusterndb.gen file when you run the configuration script. In SSR, you can configure the field names in the CST using the sessionTable.ini file.

For more information about configuring the CST for a standalone server or SSR, see the SBR Carrier Installation Guide for more information.

Persisting Sessions When SSR Cluster Is Down

If SBR Carrier fails to load the SSR cluster during startup, SBR Carrier reads the value of the FallbackLocal parameter in the radius.ini file. If this parameter is set to true, SBR Carrier uses the local CST and persists sessions in the .hst file. If the FallbackLocal parameter is set to false, SBR Carrier shuts down gracefully.

During SBR runtime, SBR Carrier identifies the cluster availability based on the number of NDB hard errors encountered for a NDB transaction. At the end of each transaction, SBR Carrier monitors the occurrence of hard errors for the transaction. If the number of hard errors exceeds the value set to the NDBHardErrorThreshold parameter in the dbclusterndb.gen file, SBR Carrier checks with the management node for the cluster’s health. Based on the reports provided by the management node, SBR Carrier decides whether the cluster is available or down.

If SBR Carrier decides that the cluster is down and the FallbackLocal parameter in the radius.ini file is set to true, SBR Carrier stores sessions in the local CST. SBR Carrier constantly monitors the cluster health even after storing the session in the local CST. When the SSR cluster becomes available, SBR Carrier again stores the sessions from the local CST to the SSR cluster database. If the FallbackLocal parameter is set to false, SBR Carrier does not store sessions in the local CST even when the cluster is down.

Note:

  • The session persistence process might be affected if the management node is not available.
  • SBR Carrier does not support the synchronization of session data between the local CST and SSR cluster database. Hence, a phantom session created in the local CST cannot be made active in the SSR cluster, or vice versa. Similarly, the Acct-Start message in one store and the Acct-Stop or Interim message in another store do not end in successful transactions and may result in creation of duplicate sessions.
  • Return list processing for IP address allocation may be affected during the session persistence.

Session Management and Control Capabilities

The session management and control capabilities in Steel-Belted Radius Carrier can be divided into two separate categories:

  • The ability to view and delete active sessions
  • The ability to dynamically disconnect sessions or change the state of a session

Viewing and Deleting Sessions

The ability to view and delete sessions is available with the basic Steel-Belted Radius Carrier license. With this basic license, you can search for all sessions, or specify certain criteria and display only sessions that match those criteria. You can then select a session or multiple sessions and delete them.

Note: Deleting a session deletes the session from the Steel-Belted Radius Carrier Current Sessions Table (CST). However, the session remains active. To inactivate a session, you must perform disconnect, which requires the optional Session Control module. For more information, see Overview of the Optional Session Control Module.

Note: In order for a session to be found in the CST, the session must be running on a controlled device, such as a network access server (NAS), which must have sent an accounting start message to the SBR Carrier server.

Disconnecting or Changing the State of Active Sessions

Under some circumstances, you may want to disconnect or make changes to active sessions without requiring the NAS to initiate the change. For example, you may want to terminate an active user’s session by issuing a Disconnect Message (DM) request to the NAS, or you may want to modify the authorization level of an active user’s session issuing a Change of Authorization (CoA) request to the NAS. For example, as a service provider, you may be required to comply with lawful intercept regulations by providing legal organizations with voice and data intercept capabilities. These might include access to private communications between organizations or individuals such as phone calls, e-mail, VoIP, or instant messaging. These lawful intercept capabilities can be performed by issuing a CoA request.

The optional Session Control module enables you to offer dynamic service changes to reinforce current service offerings. Using the Session Control module, you can customize the CoA/DM requests you want to support in your network. You can define actions that can be invoked on active sessions such as disconnecting an active session, increasing the bandwidth of an active session, or any other action you want to define. For more information, see Overview of the Optional Session Control Module.

You can control sessions using Web GUI or a command line utility, or you can develop your own client management application to interface with the Steel-Belted Radius Carrier CoA/DM XML interface.

Available User Interfaces for Managing and Controlling Sessions

You can use the following user interfaces to manage and control sessions in Steel-Belted Radius Carrier:

Web GUI

You can use Web GUI to view and delete sessions, as well as execute actions on active sessions. After you define an action in the deviceModels.xml file, a button for invoking the action becomes visible in Web GUI. You simply perform a query to locate and select one or more active sessions, and then select the action button to execute the action on the selected sessions. For more information, see Using Web GUI to Manage and Control Sessions.

Command Line Utility

You can use the command line utility to view sessions and to execute actions on active sessions. After you define an action in the deviceModels.xml file, you can use the action name as an argument in the command line utility to execute the action on the selected sessions.

Note: The command line utility (SessionControl.sh) is only used to manage and control sessions. It does not provide complete management of SBR Carrier servers.

For more information, see Using the Command Line Utility to Manage and Control Sessions.

XML over HTTPS Interface

Steel-Belted Radius Carrier includes an application programming interface (API), which is a proprietary XML request/response interface that runs over an HTTPS connection (HTTPS over TLS). The Web GUI and command line utility management clients interact with this API when issuing CoA/DM (actions) requests and when receiving responses to those requests. The protocol used for this interface is mirrored on the Simple Object Access Protocol (SOAP), though it is not identical to it.

You can develop your own XML management client to integrate with this API in order to customize the CoA/DM actions you want to support in your network. If you choose to develop your own XML management client to issue CoA/DM actions, all client requests must be in the XML format specified in Client Request Schema Example. In addition, your client management application must be capable of handling client responses from Steel-Belted Radius Carrier in the XML format specified in Client Response Schema Example. Refer to Overview of the Optional Session Control Module for a discussion on how Steel-Belted Radius Carrier processes CoA/DM requests.

Administrative Scripts

If you have purchased the optional Subscriber State Register option, you can use the ShowSessions.sh and DelSession.sh scripts to view and delete sessions. For more information, see Session State Register Administration.

Modified: 2017-09-27