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 Replication

SBR Carrier supports the replication of RADIUS configuration data from a primary server to one or more replica servers within a replication realm. Replication provides administrators with an easy way to configure multiple servers that require the same information. Depending on network configuration, you can use replication to increase AAA capacity, balance AAA traffic across RADIUS servers, or ensure that authentication services are not interrupted if access to a primary or replica server is interrupted (redundancy).

Note: Clarification is required as to the meaning of the term SBRC Standalone Server in Release 7.2 versus the meaning associated with the Centralized Configuration Management (CCM) feature of the SBRC product as it is discussed in older documentation. The CCM feature of the SBRC product allows you to designate a RADIUS process as an SBRC primary, from which configuration is published to other RADIUS processes that are designated as SBRC replicas. Older documentation often refers to these as simply primaries and replicas. SBRC replicas are unrelated to SSR cluster data replication and node groups; the latter are technical concepts involved in implementing the high availability feature of the SSR feature in Release 7.2.x.

Figure 118 illustrates an environment where RADIUS traffic is load-balanced by configuring each network access server to authenticate users through a different RADIUS server (solid line). If a RADIUS server becomes unavailable, the NAD can fail over to its backup RADIUS server (dotted line).

Figure 118: Using Replication for Load Balancing and Redundancy

Using Replication for Load Balancing
and Redundancy

All the servers within a realm reflect the current configuration specified by the network administrator: the network administrator modifies the configuration on the primary server, and the primary server propagates the new configuration to its replica servers. For example, after a network administrator configures a new RADIUS client or profile on the primary server, the network administrator tells the primary server to publish a date-stamped configuration package file that contains the updated configuration information. After publication, the primary server notifies each replica server that a new configuration package is ready. Each replica server then downloads and installs the configuration package to update its settings.

Figure 119: Publication and Distribution of Configuration Packages in a Replication Environment

Publication and Distribution of Configuration Packages
in a Replication Environment

The primary server maintains a list of the replica servers that have registered with it. The primary server uses this list to track which servers to notify after it publishes an updated configuration package to resynchronize the configuration of replica servers.

Note: By default, file permissions for configuration packages on Solaris servers are set to rw-rw----, which excludes users other than the file owner and the owner’s group from displaying the contents of file packages.

If the primary server needs to be taken out of service for an extended period, the network administrator promotes one of the replica servers to be the new primary server. Thereafter, the other replica servers copy the configuration package from the promoted primary server.

The following types of information are included in a configuration package.

  • Server information
  • RADIUS client information
  • User information
  • Profile information
  • Proxy target information
  • EAP method configuration
  • Filters
  • RADIUS tunnel information
  • Name parsing information
  • Authentication method information
  • Authentication realm information
  • Rejection messages
  • JavaScript (.jsi) files

     

You administer this information by launching the Web GUI for the primary server: the information is propagated to the replica servers in the domain. If you launch the Web GUI for a replica server, you can view this information, but you cannot modify it.

The following types of information are not included in a configuration package:

  • Address pool information—You administer address pools for a server by launching the Web GUI for that server. Because an address must not be assigned to two users at the same time, each server in a realm must have its own address pools, and these pools must not overlap.
  • Administrator information—Administrator information must be configured for each primary and replica server separately.
  • Statistics information—Server statistics are not replicated. You can view statistics for replica servers when you launch the Web GUI for the primary server.
  • Report information—Report information is not replicated. To obtain report information for a primary or replica server, launch the Web GUI for the applicable server.
  • SBR Carrier configuration files—Configuration files *.ini files other than filter.ini and eap.ini, *.aut files other than peapauth.aut, ttlsauth.aut, tlsauth.aut, and tlsauth.eap, and *.dir files are not replicated. When you change configuration files on the primary server, you must copy the modified files to the appropriate directory on each replica server.

    Note: Configuration packages are retained until they are replaced. An old configuration package is automatically deleted 24 hours after a new configuration package is published.

Modified: 2018-01-11