Filter
Top Products
4-3
Cisco Access Registrar 3.5 Concepts and Reference Guide
OL-2683-02
Chapter 4 Understanding Replication
How Replication Works
Slave Server
Step 1 When the slave server receives the transaction, its contents are verified.
Step 2 Once verified, the changes are applied to the slave server's database
Step 3 The changes are then applied (hot-configured) in the slave server's in-memory configuration.
Step 4 The transaction is written to the slave server's replication archive.
Security
Replication has two primary security concerns:
• Security of the transactions transmitted to the slave server
• Storage of transactions in the replication archive
Both of these concerns use shared secret (MD5) encryption via the shared secret specified in the
replication configuration on both master and slave servers. Replication data transmitted between master
and slave is encrypted at the source and decrypted at the destination the same way as standard RADIUS
packets between Access Registrar's clients and the Access Registrar server. Transactions written to the
replication archive are also encrypted in the same manner and decrypted when read from the replication
archive.
Replication Archive
The replication archive serves two primary purposes:
1. To provide persistent, or saved, information regarding the last successful transaction
2. To persist transactions in case the slave server requires re synchronization (see Ensuring Data
Integrity below for more information on re synchronization).
The replication archive is simply a directory located in ../CSCOar/data/archive. Each transaction
replicated by the master is written to this directory as a single file. The name of each transaction file is
of the form txn########## where ########## is the unique transaction number assigned by the master
server. The replication archive size, that is the number of transaction files it may contain, is configured
in the Replication configuration setting of TransactionArchiveLimit. When the TransactionArchive limit
is exceeded, the oldest transaction file is deleted.
Ensuring Data Integrity
Access Registrar's configuration replication feature ensures data integrity through transaction data
verification, transaction ordering, automatic resynchronization and manual full-resynchronization. With
the single exception of a manual full-resynchronization, each of the following techniques help to
automatically ensure that master and slave servers contain identical configurations. A detailed
description of each technique follows.