Storing Subscriber and Service Session Data

To aid in recovering from an SAE failover, the SAE stores subscriber and service session data in flat files on the SAE host. The SRC component that controls the storage of session data on the SAE is called the session store. The session store queues data and then writes the data to session store files on the SAE host’s disk. After the data has been written to disk, it can survive a server reboot.

You can configure how the SAE stores session data for JunosE routers, devices running Junos OS, simulated routers, and PacketCable Multimedia Specification (PCMM) devices.

Session Store Files

Session store files are numbered flat files. Session store files are located in a directory on the SAE host. You can configure the size of session store files. After the maximum size has been reached, the session store creates a new file and begins writing data to the new file.

Store operations, such as adding a session to the store (put store operations) or removing a session from the store (remove store operations), are queued in a buffer before they are written to the session store file. You can configure parameters that determine when the session store writes a queue to a session store file.

Session store files are deleted if they have not been modified and if no session activity has taken place for one week. All the data files that contain the sessions associated with a particular virtual router are deleted at the same time.

Active and Passive Session Stores

You can have a community of SAEs and duplicate session store data on each SAE in the community in case of an SAE failover. SAE communities are made up of SAEs that you configure as connected SAEs for a virtual router object.

SAEs in a community are given the role of either active SAE or passive SAE. The active SAE keeps session data up to date within the community. Each active session store opens a Transmission Control Protocol (TCP) connection to its passive SAE. The TCP connection triggers the creation of a passive session store in that SAE. When the active session store writes operations to the session store file, it passes them to passive session stores on all SAEs in the community.

When you modify a community, wait for passive session stores on the new community members to be updated before you shut down the currently active SAE. Otherwise, if you add a new member to a community, and then a failover from the current active SAE to the new member is triggered immediately, the new member’s session store may not have received all data from the active SAE’s session store.

Standby SAEs

You can configure standby SAEs for a configuration that include JunosE routers. In a community of SAEs, a standby SAE can provide redundancy for the active SAE. The active SAE connects to the standby SAE through a COPS-PR connection on port 3228. The active SAE maintains a separate session store connection with the standby SAE through port 8820 (default).

The active SAE replicates state and session data, including COPS messages received from JunosE routers, to the standby SAE. This replication reduces the failover time from one SAE to another. The active SAE detects a connection failure when a subsequent COPS message needs to be replicated because it has to wait for the standby to respond to the replication message. Both the active and standby SAEs detect a connection failure when the keep-alive timeout occurs (1 second).

Note: We recommend that you use a highly reliable and available connection between an active SAE and a standby SAE to ensure availability of the two SAEs. For standby SAEs, you configure an SAE community and the session store at the same time by configuring SAE identifiers for in the configuration for the shared network device virtual router. In the configuration, an exclamation point identifies standby SAEs.

Session Store File Rotation

The session store periodically rotates the session store files. During rotation, the session store copies put store operations for live sessions from the oldest file to the end of the newest file. (Live sessions are sessions that have been created but not yet deleted.) It then deletes the oldest file. Sessions are rotated in batches, and you can configure the number of sessions that are rotated at the same time, and how much disk space is used by live sessions before files are rotated. No session store activity can take place while a batch of sessions is rotated.