beautypg.com

Slave server, Security, Replication archive – Cisco Cisco Access Registrar 3.5 User Manual

Page 41: Ensuring data integrity

background image

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.