Cisco CNS Access Registrar User's Guide, 3.0 - Using Replication [Cisco Access Registrar]

Table Of Contents

Using Replication

Setting Up Replication

Configuring the Master

Configuring The Member

Verifying the Configuration

Replication Example

Adding a User

Master Server's Log

Member Server's Log

Verifying Replication

Master Server's Log

Member Server's Log

Using aregcmd -pf Option

Master Server's Log

Member Server's Log

An Automatic Resynchronization Example

Master Server's Log

Member Server's Log

Full Resynchronization

Replication Log Messages

Information Log Messages

Warning Log Messages

Error Log Messages

Log Messages You Should Never See

Using Replication

This chapter provides information about how to use the replication feature. When you set up replication, all configuration is replicated from the master server to members servers except for Administrators, Interfaces, Replication, and Advanced machine-specific settings.

Setting Up Replication

This section provides step-by-step instructions about how to configure replication on both the master and member servers. The following section, "Replication Example" section, shows an example of replication configuration.

Two properties in /Radius/Replication control how long an out-of-sync condition lasts. The RepTransactionSyncInterval property controls the length of time between resynchronization processing. The RepTransactionArchiveLimit property controls the number of transactions to be archived before resynchronization processing takes place.

The RepTransactionSyncInterval property has a default setting of 60000 milliseconds (or one minute). If you set RepTransactionSyncInterval to a smaller value, you decrease the amount of time between resynchronization processing. Doing so reduces the amount of time that member servers are out of sync with the master server, but also results in additional network traffic, additional processing by the Cisco AR servers, and unnecessary resynchronization processing if the value is set too small. (Values as small as 10000 have been successfully tested.)

When you set the RepTransactionArchiveLimit property, you should consider the following:

•How much hard disk space can you devote to transaction archive storage?

•How often do you change your configuration (issue a save through aregcmd)?

If you have limited hard disk space, the default value of 100 transactions might be appropriate. If you have sufficient hard disk space, you can increase the RepTransactionArchiveLimit property value to a value of 10,000 or greater.

Your goal is to limit the need to perform a full-resynchronization. A full-resynchronization is required when the member has missed so many transactions that the master no longer contains all the transactions required to resynchronize the member.

Even by modifying these two properties, you might not be able to prevent the need for a full resynchronization, but you can limit the possibility.

Configuring the Master

Use the following steps to configure the master server for replication. In a given configuration, you can have only one master server.

Step 1 Launch aregcmd on the machine which is the master.

Step 2 Change directory to /Radius/Replication.

cd /Radius/Replication
Step 3 Set the RepType to SMDBR.

set RepType SMDBR

Step 4 Set the RepIPAddress to the IP address of the master.

set RepIPAddress 209.165.202.128

Step 5 Set the RepSecret to MySecret.

set RepSecret MySecret

Step 6 Set RepIsMaster to TRUE.

set RepIsMaster TRUE

Step 7 Set RepMasterIPAddress to the same value used in step 3.

set RepIPMaster 209.165.202.128

Step 8 Change directory to /Radius/Advanced and set the MaximumNumberOfRadiusPackets property to 8192.

cd /Radius/Advanced

set MaximumNumberOfRadiusPackets 8192

Step 9 Change directory to Rep Members.

cd "rep members"

Note You must enclose Rep Members in quotes due to the space in the name.

Step 10 Add member1.

add member1

Step 11 Change directory to member1.

cd member1

Step 12 Set the IPAddress to the IP Address of the machine to be the member.

set IPAddress 209.166.202.129

Note The RepPort and RepMasterPort properties on the Master must correspond to one of the ports configured in /Radius/Advanced/Ports, if one is configured. Otherwise, the default values for the RepPort and RepMasterPort properties are sufficient.

Step 13 Save the configuration.

save

Step 14 Reload the configuration.

reload

Configuring The Member

Use the following steps to configure the member server for replication.

Step 1 On the machine which is to be the member, using aregcmd, navigate to //localhost/Radius/Replication.

Step 2 Set the RepType to SMDBR.

set RepType SMDBR

Step 3 Set the RepIPAddress to the IP address of the member.

set RepIPAddress 209.166.202.129

Step 4 Set the RepSecret to MySecret.

set RepSecret MySecret

Step 5 Set RepMasterIPAddress to IP Address of the master (the same value used in Step 3 on page 1-1).

set RepMasterIPAddress 209.165.202.128

Step 6 Change directory to /Radius/Advanced and set the MaximumNumberOfRadiusPackets property to 8192.

cd /Radius/Advanced

set MaximumNumberOfRadiusPackets 8192

Step 7 If the Master has been configured to use a port other than the well-known (and default) RADIUS ports, configure each Member to use the same port.

Note The RepPort and RepMasterPort properties on the Master must correspond to one of the ports configured in /Radius/Advanced/Ports, if one is configured. Otherwise, the default values for the RepPort and RepMasterPort properties are sufficient.

Step 8 Save the configuration.

save

Step 9 Reload the configuration.

reload

Verifying the Configuration

After both servers have successfully started, use aregcmd to make a small change to be replicated to the member server which you can easily verify. Cisco recommends setting the description in //localhost/Radius to something like Test1. After you issue an aregcmd save and the prompt returns, run aregcmd on the member server and change directory to //localhost/Radius. Ensure that the description is set to Test1. If this was successful, then replication is properly configured and functional.

Note Before the Cisco AR server can replicate changes, you must successfully save the replication configuration.

If possible, open an xterm window on both the master and member. In each of these windows, change directory to $INSTALL/logs and run xtail to watch the logs. This allows you to watch replication log messages as they occur. If you are using a system which had a previous installation of Cisco Access Registrar, delete all files located in the $INSTALL/data/archive directory if it is present on either the master or member systems.

Replication Example

This section provides an example of replication and shows the actions that occur.

Adding a User

On the master server, use aregcmd to add a new user to the default user list. To add a new user, perform the following steps.

Step 1 Change directory to //localhost/Radius/UserLists/Default.

Step 2 Enter the following.

add testuser

Step 3 Change directory to testuser.

cd testuser

Step 4 Set the password for testuser.

set password testuser

Step 5 Confirm the password by entering testuser again.

Step 6 Enter save to save the configuration.

Master Server's Log

The log on the master shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:17:07 name/radius/1 Info Server 0 Initiating Replication of Transaction 
1 with 2 Elements.
04/02/2001 23:17:07 name/radius/1 Info Server 0 Replication Transaction #1 With 2 
Elements Initiated
Member Server's Log

The log on the member shows the following:
*** ./name_radius_1_log ***
4/02/2001 23:15:18 name/radius/1 Info Server 0 Radius Server is On-Line
04/02/2001 23:17:12 name/radius/1 Info Server 0 Committing Replication of Transaction 
1 with 2 Elements.
04/02/2001 23:17:16 name/radius/1 Info Server 0 Replication Transaction #1 With 2 
Elements Committed.
Verifying Replication

You can use one of two methods to verify that the new user testuser was properly replicated to the member.

•Run aregcmd on the member and look at the default userlist to see if it is there.

•Run radclient on the member and enter simple testuser testuser to create a simple access request packet (p001).

Enter p001 send to send it. When it returns with p002, enter p002 to see if it is an Access Accept packet or an Access Reject packet. If it is an Access Accept, the user was properly replicated to the member. Using radclient is the recommended method to validate that a user was properly replicated.

On the Master, use aregcmd to delete the user from the default user list and save the user list.

Master Server's Log

The log on the master shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:20:48 name/radius/1 Info Server 0 Initiating Replication of Transaction 
2 with 1 Elements.
04/02/2001 23:20:48 name/radius/1 Info Server 0 Replication Transaction #2 With 1 
Elements Initiated
Member Server's Log

The log on the member shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:20:53 name/radius/1 Info Server 0 Committing Replication of Transaction 
2 with 1 Elements.
04/02/2001 23:20:57 name/radius/1 Info Server 0 Replication Transaction #2 With 1 
Elements Committed.
Repeat the validation procedure above to ensure the user testuser is no longer present on the member.

Using aregcmd -pf Option

Cisco Access Registrar's replication feature works well using aregcmd input files. An aregcmd input file contains a list of aregcmd commands. For example, if the initial configuration of Cisco Access Registrar were constructed in an input file, the master and member could be configured for replication first, then the input file applied to the master will be automatically replicated to the member.

To illustrate replication using an aregcmd input file, do the following:

Step 1 Create a text file called add5users with the following contents:

add /Radius/UserLists/Default/testuser1

cd /Radius/UserLists/Default/testuser1

set password testuser1

add /Radius/UserLists/Default/testuser2

cd /Radius/UserLists/Default/testuser2

set password testuser2

add /Radius/UserLists/Default/testuser3

cd /Radius/UserLists/Default/testuser3

set password testuser3

add /Radius/UserLists/Default/testuser4

cd /Radius/UserLists/Default/testuser4

set password testuser4

add /Radius/UserLists/Default/testuser5

cd /Radius/UserLists/Default/testuser5

set password testuser5

save

Step 2 On the master server, run the following command:

aregcmd -pf add5users

Master Server's Log

The log on the master shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:27:08 name/radius/1 Info Server 0 Initiating Replication of Transaction 
3 with 10 Elements.
04/02/2001 23:27:08 name/radius/1 Info Server 0 Replication Transaction #3 With 10 
Elements Initiated
Member Server's Log

The log on the member shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:27:12 name/radius/1 Info Server 0 Committing Replication of Transaction 
3  with 10 Elements.
04/02/2001 23:27:17 name/radius/1 Info Server 0 Replication Transaction #3 With 10  
Elements Committed.
When the prompt returns, go to the member and use aregcmd to view the /radius/defaults/userlist. There should be five users there named testuser1 through testuser5.

An Automatic Resynchronization Example

This example will illustrate resynchronization of the member. This will be accomplished by stopping the member, making changes on the master, then restarting the member forcing a resynchronization.

Step 1 At the member, stop the AR server:

/etc/init.d/arservagt stop

At the master, run aregcmd and change directory to /radius/userlist/default.

cd /radius/userlist/default

Step 2 Enter the following:

add foouser

Step 3 Change directory to foouser.

cd foouser

Step 4 Set the password for foouser.

set password foouser

Step 5 Confirm the password by entering foouser again.

Step 6 Save the configuration:

save

Master Server's Log

The log on the master shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:31:02 name/radius/1 Info Server 0 Initiating Replication of Transaction 
5 with 2 Elements.
04/02/2001 23:31:02 name/radius/1 Info Server 0 Replication Transaction #5 With2 
Elements Initiated
On the member, run /etc/init.d/arservagt start. Notice the following log messages in the Master's log:
*** ./name_radius_1_log ***
04/02/2001 23:33:19 name/radius/1 Info Server 0 Resynchronizing member1.
Member Server's Log

The log on the member shows the following:
*** ./name_radius_1_log ***
04/02/2001 23:33:14 name/radius/1 Info Server 0 Radius Server is Off-Line
04/02/2001 23:33:14 name/radius/1 Info Server 0 Starting Replication Manager
04/02/2001 23:33:24 name/radius/1 Info Server 0 Master Selected As Partner (DEFAULT)
04/02/2001 23:33:24 name/radius/1 Info Server 0 Radius Server is Off-Line
04/02/2001 23:33:24 name/radius/1 Warning Server 0 Requesting resynchronization from 
Master: Last Txn#3
04/02/2001 23:33:24 name/radius/1 Info Server 0 Resynchronization from Master in 
progress.
04/02/2001 23:33:24 name/radius/1 Info Server 0 Committing Replication of Transaction 
4 with 2 Elements.
04/02/2001 23:33:28 name/radius/1 Info Server 0 Replication Transaction #4 With 2 
Elements Committed.
04/02/2001 23:33:28 name/radius/1 Info Server 0 Radius Server is On-Line
As the log above shows, when the member started up, it validated its last received transaction number (#3) with the master's last replicated transaction number (#4). They did not match because a replication was initiated by the master which was not received by the member (because the member was stopped). When the member detected this discrepancy, the member made a resynchronization request to the master. The master responded by transmitting the missed transaction (#4) to the member. After it received and processed the retransmitted transaction, the member determined that it was then synchronized with the master and placed itself in an on-line status.

Full Resynchronization

Full Resynchronization means that the member has missed more transactions than are stored in the master's replication archive and can not be resynchronized automatically. There is no automatic full-resynchronization mechanism in Cisco Access Registrar's configuration replication feature. If a full resynchronization is required, you must export the master server's database and update the member configuration.

Note Before beginning, ensure there are no aregcmd sessions logged into the master server.

To perform a manual full-resynchronization, perform the following steps:

Step 1 On the master server, stop the Cisco AR server agent using the following command:

/etc/init.d/arserver stop
Step 2 On the master server, change directory to $INSTALL/data/db.

Step 3 Create a tarfile made up of the three database files, mcddb.d01, mcddb.d02, and mcddb.d03.

tar cvf /tmp/db.tar mcddb.d0*

Step 4 Create a tarfile of the archive.

tar cvf /tmp/archive.tar $INSTALL/data/archive

Step 5 On the master server, start the Cisco AR server agent using the following command:

/etc/init.d/arserver start
Step 6 On each member server requiring resynchronization, perform the following:

a. On the member server, stop the Cisco AR server agent using the following command:

/etc/init.d/arserver stop
b. Copy the tarfiles (db.tar and archive.tar) to /tmp.

c. Change directory to $INSTALL/data/db, then untar the compressed database files.

cd $INSTALL/data/db

tar xvf /tmp/db.tar

d. Rebuild the key files using the following command:

$INSTALL/bin/keybuild mcddb

Note This step might take several minutes.

e. Untar the archive.

cd $INSTALL/data/db
tar xvf /tmp/archive.tar
f. As a safety check, run the following UNIX command to verify the integrity of the database.

$INSTALL/bin/dbcheck mcddb

Note You must be user root to run dbcheck.

No errors should be detected.

g. Start the Cisco AR server agent using the following command:

/etc/init.d/arserver start

Note After you start the member server with the master server's database, you will probably see messages such as the following:

03/24/2005 23:21:23 name/radius/1 Error Server 0 TXN_SYNC: Failed to get master's socket handle.
03/24/2005 23:21:49 name/radius/1 Warning Server 0 TXN_SYNC Received by Master from unknown member 10.1.9.74. Validation Failed

These messages will likely continue until you complete steps h and i.

h. Change directory to //radius/replication and change the following attributes:

•Change the RepIPAddress to that of the member.

•Change RepIsMaster to FALSE.

•Remove any entries under Rep Members.

i. Save and reload the configuration.

save
Validating //localhost...
Saving //localhost...
reload
The member will start up and show on-line status in the log after it has verified it is synchronized with the master.

Replication Log Messages

This section contains typical replication log messages and explains what each means. This section include the following subsections:

•Information Log Messages

•Warning Log Messages

•Error Log Messages

•Log Messages You Should Never Receive

Information Log Messages
 Starting Replication Manager
Displayed at start-up and indicates the Replication Manager is configured and enabled. (RepType=SMDBR)
 Replication Disabled
Displayed at start-up and indicates that Replication is not enabled. (RepType=NONE)
 Radius Server is On-Line
Displayed by the member at start-up to indicate the member is synchronized with the master and processing RADIUS requests. It is also displayed after a successfully completed resynchronization. This message is never displayed on the master.
 Radius Server is Off-Line
Displayed by the member at start-up to indicate the radius server is not processing RADIUS requests until it can ensure synchronization with the master. When this is displayed after startup, it indicates the member is no longer synchronized with the master and is directly associated with a resynchronization request to the master. This message is never displayed on the master.
 Resynchronizing <member name>
Displayed by the master to indicate that it is resynchronizing the specified member (member).
 Resynchronization from Master in progress.
Displayed by the member to indicate the master is in the process of resynchronizing it.
 Resynchronization complete.
Displayed by the member to indicate the resynchronization has completed successfully.
 Resynchronization did not complete before timeout. Retrying.
Indicates the master did not complete the resynchronization before the member expected it to complete and that the member is re-requesting resynchronization from the master for the remaining missed transactions.
 Master Selected As Partner (DEFAULT)
Displayed by the member to indicate it has successfully connected with the master.
 Initiating Replication of Transaction <transaction #> with <# of elements> 
Elements.
Displayed by the master to indicate that it is beginning replication of a transaction to the member.
 Replication Transaction #<transaction #> With <# of elements> Elements Initiated
Displayed by the master to indicate that it has completed sending the transaction to the member.
 Committing Replication of Transaction <transaction #> with <# of elements> 
Elements.
Displayed by the member to indicate that it has received a transaction and is processing it.
 Replication Transaction #<transaction#> With <# of element> Elements Committed
Displayed by the member to indicate that the transaction has been successfully processed.
 Stopping Replication Manager
Displayed at shutdown by both the master and member to indicate the replication manager is being shut down.
 Stopping Replication Manager - waiting for replication to complete...
Displayed by the member when a shutdown is attempted while received replications are being processed. Once the replications are complete, the shutdown will complete.
 Replication in progress. Please wait...
Periodically displayed while a shutdown is pending and replications are being completed.
 Replication Manager Stopped
Displayed by both the master and member to indicate the replication manager has been successfully shutdown.

Warning Log Messages
 Transaction Sync not received within configured TransactionSyncInterval.  
Communication with the Master may not be possible.
The member displays this log messages to indicate that it has not received a TransactionSync message from the master within its configured TransactionSync interval.
 TXN_SYNC Received by Master from unknown member <ip address>. Validation Failed
Displayed by the master when a TransactionSync message is received by the master. Since there can be only one configured master in a replication network, and the master is the only server who can send a TransactionSync message, this indicates there is another configured master in the replication network.
 TXN_SYNC Received from unknown Master <ip address>. Validation Failed
Displayed by the member to indicate that a TransactionSync message was received from a server not configured as its master.
 Requesting resynchronization from Master: Last Txn#<transaction#>
Displayed by the member to indicate that it is requesting resynchronization from the master. The LastTxn# is the last transaction number the member received and processed successfully.
 Resynchronization Request received from unknown member.
Displayed by the master when a resynchronization request is received by a member who is not listed in its /radius/replication/rep members configuration.
 Resynchronization of <member name> requires Full Resynchronization.
Displayed by the master to indicate that the member cannot be automatically resynchronized because its last transaction number is not within the configured history length of the archive (TransactionArchiveLimit). A manual resynchronization of the member is required to put the member back in-sync.
 MEMBER_SYNC Received from unknown Master at <ip address>. Validation Failed
Displayed by a member indicating that a master, other than its configured master, is requesting partnership.
 MEMBER_SYNC Received by Master from unknown member <ip address>. Validation Failed
Displayed by the master to indicate a member not listed in its /radius/replication/rep members configuration has requested partnership.
 TXN_EXPECT Received by Master from unknown <ip address>.
Displayed by the master to indicate it has received a transaction which originated from another illegal master.
 TXN_EXPECT Received from unknown Master <ip address>.
Displayed by the member to indicate it has received a transaction which originated from a master other than its configured master.
 TXN_EXPECT Broadcast failed.
Indicates that the master could not initiate a replication.
 DATA_SYNC Received by Master from unknown <ip address>
Displayed by the master to indicate that it received a replication transaction from another illegal master.
 DATA_SYNC Received from unknown <ip address>
Displayed by the member to indicate that a transaction was received from a server external to the replication network.

Error Log Messages
 DATA_SYNC Validation failed - CRC Mismatch
Displayed by the member to indicate a received transaction element is invalid.
 TXN_SYNC: Failed To Get Member Socket Handle.

TXN_SYNC: Failed to get master's socket handle.

MEMBER_SYNC could not get socket handle

TXN_EXPECT: Failed to get socket handle.

DATA_SYNC could not get socket handle.

These messages indicate an invalid interface configuration in Cisco Access 
Registrar. 

They could also be the result of specifying an invalid RepPort setting.

Failed To Create TXN_SYNC packet. (out of packets?)

Failed To Create TXN_SYNC packet.

MEMBER_SYNC Failed to create packet.(out of packets?)

MEMBER_SYNC Failed to create packet.

TXN_EXPECT Failed to create packet.(out of packets?)

TXN_EXPECT Failed to create packet.

DATA_SYNC Create packet failed.(out of packets?)

DATA_SYNC Create packet failed.
These message indicate that a packet could not be created. This could be the result of a low memory condition or the result of the /Radius/Advanced/ MaximumNumberOfRadiusPackets setting being set too low
 TXN_SYNC validation failed - Internal error (pTxnSync=NULL).

MEMBER_SYNC validate failed - Internal Error (pMemberSync=NULL)

DATA_SYNC Validation Failed - Internal (pDataSync = NULL).

TXN_EXPECT Could not add new datablock to pending transaction queue.

Replication Member could not be added to member list.

Replication Member could not be added to member list.
These messages are the result of a failed memory allocation possibly due to an out of memory condition.
 DATA_SYNC Packet creation failed - Invalid ordinal.

Attempt To Replicate Transaction With Zero Elements.

Internal Error - Selected member not valid

Internal Replication Error ChangeType <change type> For <element path>

Internal error - Replication manager is invalid
These messages indicate an internal application failure.
 Cannot archive transaction datablock

Could not archive transaction
These messages are the result of a failed archive attempt. This could be the result of a low disk space condition.
 Could not commit transaction to MCD

Cannot Get Value For Unsupported DataType <data type id>

MCD Replication Cannot Delete Value <element path>

MCD Replication Cannot Delete Directory <element path>

MCD Replication Cannot Delete Value For <element path> With Unsupported DataType

<data type id>

MCD Replication Cannot Create Dir For <element path>

MCD Replication Cannot Set Value For <element path>

MCD Replication Cannot Set Value For <element path>

MCD Replication Cannot Set Value For <element path>

MCD Replication Cannot Set Value For <element path>

MCD Replication Cannot Set Value For <element path> With Unsupported DataType 
<data type id>

MCD Replication Cannot Set Value For <element path> With UNKNOWN DataType <data 
type id>
These messages are the result of a failed replication commit attempt.

Log Messages You Should Never See

The following list contains log messages which you should never see displayed in a log. If any of these messages are displayed in the log, contact Cisco Access Registrar technical support for assistance.
 <member name> Selected As Partner (DEFAULT)

DATA_SYNC Received from non-partner <ip address>

DATA_RE_SYNC CRC mismatch. Replying with NAK

DATA_RE_SYNC Commit Failed. Replying with NAK

EVAL_SYNC Validation failed. <ip address> is not a Master or Member of the

Replication network

EVAL_SYNC Received from unknown member.

PARTNER_SYNC Received from unknown member <ip address>.

PARTNER_SYNC Received from unknown member <ip address>.

EVAL_SYNC Cannot get socket handle.

EVAL_SYNC Failed to create packet.(out of packets?)

EVAL_SYNC Failed to create packet.

EVAL_SYNC Validation failed - Internal Error (pEvalSync=NULL).

PARTNER_SYNC Failed to get socket handle.

PARTNER_SYNC Failed to create packet. (out of packets?)

PARTNER_SYNC Failed to create packet.

DATA_RE_SYNC Can't get socket handle

DATA_RE_SYNC Failed to create packet (out of packets?)

DATA_RE_SYNC Failed to create packet

DATA_RE_SYNC Failed validation - Internal Error (pReSync = NULL)

DATA_RE_SYNC Cannot Set Value For <element path>

DATA_RE_SYNC Cannot Set Value For <element path>

DATA_RE_SYNC Cannot Set Value For <element path>

DATA_RE_SYNC Cannot Set Value For <element path>

DATA_RE_SYNC Cannot Set Value For <element path> With Unsupported DataType <data

type id>

DATA_RE_SYNC Cannot Set Value For <element path> With UNKNOWN DataType <data type 
id>;

DATA_RE_SYNC Received by Master from unknown member <ip address>

DATA_RE_SYNC Received from unknown Master <ip address>DATA_RE_SYNC Reply received 
by Master from unknown Member <ip address>

Could not replicate data element to partners.

Could not replicate to partners - Invalid Ordinal.

	Cisco CNS Access Registrar User's Guide, 3.0
	Using Replication
Cisco CNS Access Registrar User's Guide, 3.0 Index About This Guide Overview Using aregcmd Commands Access Registrar Server Objects Using the radclient Commands Configuring Local Authentication and Authorization Using Extension Points Using Replication Using On-Demand Address Pools Cisco Access Registrar Features Using the Policy Engine Wireless Support Using LDAP Using Open Database Connectivity Backing Up the Database Using the REX Accounting Script Logging syslog Features Troubleshooting Cisco Access Registrar Cisco Access Registrar Dictionaries Cisco Access Registrar Environment Variables RADIUS Attributes Cisco Access Registrar 3.0 User's Guide	Download this chapter Using Replication Table Of Contents Using Replication Setting Up Replication Configuring the Master Configuring The Member Verifying the Configuration Replication Example Adding a User Master Server's Log Member Server's Log Verifying Replication Master Server's Log Member Server's Log Using aregcmd -pf Option Master Server's Log Member Server's Log An Automatic Resynchronization Example Master Server's Log Member Server's Log Full Resynchronization Replication Log Messages Information Log Messages Warning Log Messages Error Log Messages Log Messages You Should Never See Using Replication This chapter provides information about how to use the replication feature. When you set up replication, all configuration is replicated from the master server to members servers except for Administrators, Interfaces, Replication, and Advanced machine-specific settings. Setting Up Replication This section provides step-by-step instructions about how to configure replication on both the master and member servers. The following section, "Replication Example" section, shows an example of replication configuration. Two properties in /Radius/Replication control how long an out-of-sync condition lasts. The RepTransactionSyncInterval property controls the length of time between resynchronization processing. The RepTransactionArchiveLimit property controls the number of transactions to be archived before resynchronization processing takes place. The RepTransactionSyncInterval property has a default setting of 60000 milliseconds (or one minute). If you set RepTransactionSyncInterval to a smaller value, you decrease the amount of time between resynchronization processing. Doing so reduces the amount of time that member servers are out of sync with the master server, but also results in additional network traffic, additional processing by the Cisco AR servers, and unnecessary resynchronization processing if the value is set too small. (Values as small as 10000 have been successfully tested.) When you set the RepTransactionArchiveLimit property, you should consider the following: •How much hard disk space can you devote to transaction archive storage? •How often do you change your configuration (issue a save through aregcmd)? If you have limited hard disk space, the default value of 100 transactions might be appropriate. If you have sufficient hard disk space, you can increase the RepTransactionArchiveLimit property value to a value of 10,000 or greater. Your goal is to limit the need to perform a full-resynchronization. A full-resynchronization is required when the member has missed so many transactions that the master no longer contains all the transactions required to resynchronize the member. Even by modifying these two properties, you might not be able to prevent the need for a full resynchronization, but you can limit the possibility. Configuring the Master Use the following steps to configure the master server for replication. In a given configuration, you can have only one master server. Step 1 Launch aregcmd on the machine which is the master. Step 2 Change directory to /Radius/Replication. cd /Radius/Replication Step 3 Set the RepType to SMDBR. set RepType SMDBR Step 4 Set the RepIPAddress to the IP address of the master. set RepIPAddress 209.165.202.128 Step 5 Set the RepSecret to MySecret. set RepSecret MySecret Step 6 Set RepIsMaster to TRUE. set RepIsMaster TRUE Step 7 Set RepMasterIPAddress to the same value used in step 3. set RepIPMaster 209.165.202.128 Step 8 Change directory to /Radius/Advanced and set the MaximumNumberOfRadiusPackets property to 8192. cd /Radius/Advanced set MaximumNumberOfRadiusPackets 8192 Step 9 Change directory to Rep Members. cd "rep members" Note You must enclose Rep Members in quotes due to the space in the name. Step 10 Add member1. add member1 Step 11 Change directory to member1. cd member1 Step 12 Set the IPAddress to the IP Address of the machine to be the member. set IPAddress 209.166.202.129 Note The RepPort and RepMasterPort properties on the Master must correspond to one of the ports configured in /Radius/Advanced/Ports, if one is configured. Otherwise, the default values for the RepPort and RepMasterPort properties are sufficient. Step 13 Save the configuration. save Step 14 Reload the configuration. reload Configuring The Member Use the following steps to configure the member server for replication. Step 1 On the machine which is to be the member, using aregcmd, navigate to //localhost/Radius/Replication. Step 2 Set the RepType to SMDBR. set RepType SMDBR Step 3 Set the RepIPAddress to the IP address of the member. set RepIPAddress 209.166.202.129 Step 4 Set the RepSecret to MySecret. set RepSecret MySecret Step 5 Set RepMasterIPAddress to IP Address of the master (the same value used in Step 3 on page 1-1). set RepMasterIPAddress 209.165.202.128 Step 6 Change directory to /Radius/Advanced and set the MaximumNumberOfRadiusPackets property to 8192. cd /Radius/Advanced set MaximumNumberOfRadiusPackets 8192 Step 7 If the Master has been configured to use a port other than the well-known (and default) RADIUS ports, configure each Member to use the same port. Note The RepPort and RepMasterPort properties on the Master must correspond to one of the ports configured in /Radius/Advanced/Ports, if one is configured. Otherwise, the default values for the RepPort and RepMasterPort properties are sufficient. Step 8 Save the configuration. save Step 9 Reload the configuration. reload Verifying the Configuration After both servers have successfully started, use aregcmd to make a small change to be replicated to the member server which you can easily verify. Cisco recommends setting the description in //localhost/Radius to something like Test1. After you issue an aregcmd save and the prompt returns, run aregcmd on the member server and change directory to //localhost/Radius. Ensure that the description is set to Test1. If this was successful, then replication is properly configured and functional. Note Before the Cisco AR server can replicate changes, you must successfully save the replication configuration. If possible, open an xterm window on both the master and member. In each of these windows, change directory to $INSTALL/logs and run xtail to watch the logs. This allows you to watch replication log messages as they occur. If you are using a system which had a previous installation of Cisco Access Registrar, delete all files located in the $INSTALL/data/archive directory if it is present on either the master or member systems. Replication Example This section provides an example of replication and shows the actions that occur. Adding a User On the master server, use aregcmd to add a new user to the default user list. To add a new user, perform the following steps. Step 1 Change directory to //localhost/Radius/UserLists/Default. Step 2 Enter the following. add testuser Step 3 Change directory to testuser. cd testuser Step 4 Set the password for testuser. set password testuser Step 5 Confirm the password by entering testuser again. Step 6 Enter save to save the configuration. Master Server's Log The log on the master shows the following: * ./name_radius_1_log * 04/02/2001 23:17:07 name/radius/1 Info Server 0 Initiating Replication of Transaction 1 with 2 Elements. 04/02/2001 23:17:07 name/radius/1 Info Server 0 Replication Transaction #1 With 2 Elements Initiated Member Server's Log The log on the member shows the following: * ./name_radius_1_log * 4/02/2001 23:15:18 name/radius/1 Info Server 0 Radius Server is On-Line 04/02/2001 23:17:12 name/radius/1 Info Server 0 Committing Replication of Transaction 1 with 2 Elements. 04/02/2001 23:17:16 name/radius/1 Info Server 0 Replication Transaction #1 With 2 Elements Committed. Verifying Replication You can use one of two methods to verify that the new user testuser was properly replicated to the member. •Run aregcmd on the member and look at the default userlist to see if it is there. •Run radclient on the member and enter simple testuser testuser to create a simple access request packet (p001). Enter p001 send to send it. When it returns with p002, enter p002 to see if it is an Access Accept packet or an Access Reject packet. If it is an Access Accept, the user was properly replicated to the member. Using radclient is the recommended method to validate that a user was properly replicated. On the Master, use aregcmd to delete the user from the default user list and save the user list. Master Server's Log The log on the master shows the following: * ./name_radius_1_log * 04/02/2001 23:20:48 name/radius/1 Info Server 0 Initiating Replication of Transaction 2 with 1 Elements. 04/02/2001 23:20:48 name/radius/1 Info Server 0 Replication Transaction #2 With 1 Elements Initiated Member Server's Log The log on the member shows the following: * ./name_radius_1_log * 04/02/2001 23:20:53 name/radius/1 Info Server 0 Committing Replication of Transaction 2 with 1 Elements. 04/02/2001 23:20:57 name/radius/1 Info Server 0 Replication Transaction #2 With 1 Elements Committed. Repeat the validation procedure above to ensure the user testuser is no longer present on the member. Using aregcmd -pf Option Cisco Access Registrar's replication feature works well using aregcmd input files. An aregcmd input file contains a list of aregcmd commands. For example, if the initial configuration of Cisco Access Registrar were constructed in an input file, the master and member could be configured for replication first, then the input file applied to the master will be automatically replicated to the member. To illustrate replication using an aregcmd input file, do the following: Step 1 Create a text file called add5users with the following contents: add /Radius/UserLists/Default/testuser1 cd /Radius/UserLists/Default/testuser1 set password testuser1 add /Radius/UserLists/Default/testuser2 cd /Radius/UserLists/Default/testuser2 set password testuser2 add /Radius/UserLists/Default/testuser3 cd /Radius/UserLists/Default/testuser3 set password testuser3 add /Radius/UserLists/Default/testuser4 cd /Radius/UserLists/Default/testuser4 set password testuser4 add /Radius/UserLists/Default/testuser5 cd /Radius/UserLists/Default/testuser5 set password testuser5 save Step 2 On the master server, run the following command: aregcmd -pf add5users Master Server's Log The log on the master shows the following: * ./name_radius_1_log * 04/02/2001 23:27:08 name/radius/1 Info Server 0 Initiating Replication of Transaction 3 with 10 Elements. 04/02/2001 23:27:08 name/radius/1 Info Server 0 Replication Transaction #3 With 10 Elements Initiated Member Server's Log The log on the member shows the following: * ./name_radius_1_log * 04/02/2001 23:27:12 name/radius/1 Info Server 0 Committing Replication of Transaction 3 with 10 Elements. 04/02/2001 23:27:17 name/radius/1 Info Server 0 Replication Transaction #3 With 10 Elements Committed. When the prompt returns, go to the member and use aregcmd to view the /radius/defaults/userlist. There should be five users there named testuser1 through testuser5. An Automatic Resynchronization Example This example will illustrate resynchronization of the member. This will be accomplished by stopping the member, making changes on the master, then restarting the member forcing a resynchronization. Step 1 At the member, stop the AR server: /etc/init.d/arservagt stop At the master, run aregcmd and change directory to /radius/userlist/default. cd /radius/userlist/default Step 2 Enter the following: add foouser Step 3 Change directory to foouser. cd foouser Step 4 Set the password for foouser. set password foouser Step 5 Confirm the password by entering foouser again. Step 6 Save the configuration: save Master Server's Log The log on the master shows the following: * ./name_radius_1_log * 04/02/2001 23:31:02 name/radius/1 Info Server 0 Initiating Replication of Transaction 5 with 2 Elements. 04/02/2001 23:31:02 name/radius/1 Info Server 0 Replication Transaction #5 With2 Elements Initiated On the member, run /etc/init.d/arservagt start. Notice the following log messages in the Master's log: * ./name_radius_1_log * 04/02/2001 23:33:19 name/radius/1 Info Server 0 Resynchronizing member1. Member Server's Log The log on the member shows the following: * ./name_radius_1_log * 04/02/2001 23:33:14 name/radius/1 Info Server 0 Radius Server is Off-Line 04/02/2001 23:33:14 name/radius/1 Info Server 0 Starting Replication Manager 04/02/2001 23:33:24 name/radius/1 Info Server 0 Master Selected As Partner (DEFAULT) 04/02/2001 23:33:24 name/radius/1 Info Server 0 Radius Server is Off-Line 04/02/2001 23:33:24 name/radius/1 Warning Server 0 Requesting resynchronization from Master: Last Txn#3 04/02/2001 23:33:24 name/radius/1 Info Server 0 Resynchronization from Master in progress. 04/02/2001 23:33:24 name/radius/1 Info Server 0 Committing Replication of Transaction 4 with 2 Elements. 04/02/2001 23:33:28 name/radius/1 Info Server 0 Replication Transaction #4 With 2 Elements Committed. 04/02/2001 23:33:28 name/radius/1 Info Server 0 Radius Server is On-Line As the log above shows, when the member started up, it validated its last received transaction number (#3) with the master's last replicated transaction number (#4). They did not match because a replication was initiated by the master which was not received by the member (because the member was stopped). When the member detected this discrepancy, the member made a resynchronization request to the master. The master responded by transmitting the missed transaction (#4) to the member. After it received and processed the retransmitted transaction, the member determined that it was then synchronized with the master and placed itself in an on-line status. Full Resynchronization Full Resynchronization means that the member has missed more transactions than are stored in the master's replication archive and can not be resynchronized automatically. There is no automatic full-resynchronization mechanism in Cisco Access Registrar's configuration replication feature. If a full resynchronization is required, you must export the master server's database and update the member configuration. Note Before beginning, ensure there are no aregcmd sessions logged into the master server. To perform a manual full-resynchronization, perform the following steps: Step 1 On the master server, stop the Cisco AR server agent using the following command: /etc/init.d/arserver stop Step 2 On the master server, change directory to $INSTALL/data/db. Step 3 Create a tarfile made up of the three database files, mcddb.d01, mcddb.d02, and mcddb.d03. tar cvf /tmp/db.tar mcddb.d0* Step 4 Create a tarfile of the archive. tar cvf /tmp/archive.tar $INSTALL/data/archive Step 5 On the master server, start the Cisco AR server agent using the following command: /etc/init.d/arserver start Step 6 On each member server requiring resynchronization, perform the following: a. On the member server, stop the Cisco AR server agent using the following command: /etc/init.d/arserver stop b. Copy the tarfiles (db.tar and archive.tar) to /tmp. c. Change directory to $INSTALL/data/db, then untar the compressed database files. cd $INSTALL/data/db tar xvf /tmp/db.tar d. Rebuild the key files using the following command: $INSTALL/bin/keybuild mcddb Note This step might take several minutes. e. Untar the archive. cd $INSTALL/data/db tar xvf /tmp/archive.tar f. As a safety check, run the following UNIX command to verify the integrity of the database. $INSTALL/bin/dbcheck mcddb Note You must be user root to run dbcheck. No errors should be detected. g. Start the Cisco AR server agent using the following command: /etc/init.d/arserver start Note After you start the member server with the master server's database, you will probably see messages such as the following: 03/24/2005 23:21:23 name/radius/1 Error Server 0 TXN_SYNC: Failed to get master's socket handle. 03/24/2005 23:21:49 name/radius/1 Warning Server 0 TXN_SYNC Received by Master from unknown member 10.1.9.74. Validation Failed These messages will likely continue until you complete steps h and i. h. Change directory to //radius/replication and change the following attributes: •Change the RepIPAddress to that of the member. •Change RepIsMaster to FALSE. •Remove any entries under Rep Members. i. Save and reload the configuration. save Validating //localhost... Saving //localhost... reload The member will start up and show on-line status in the log after it has verified it is synchronized with the master. Replication Log Messages This section contains typical replication log messages and explains what each means. This section include the following subsections: •Information Log Messages •Warning Log Messages •Error Log Messages •Log Messages You Should Never Receive Information Log Messages Starting Replication Manager Displayed at start-up and indicates the Replication Manager is configured and enabled. (RepType=SMDBR) Replication Disabled Displayed at start-up and indicates that Replication is not enabled. (RepType=NONE) Radius Server is On-Line Displayed by the member at start-up to indicate the member is synchronized with the master and processing RADIUS requests. It is also displayed after a successfully completed resynchronization. This message is never displayed on the master. Radius Server is Off-Line Displayed by the member at start-up to indicate the radius server is not processing RADIUS requests until it can ensure synchronization with the master. When this is displayed after startup, it indicates the member is no longer synchronized with the master and is directly associated with a resynchronization request to the master. This message is never displayed on the master. Resynchronizing <member name> Displayed by the master to indicate that it is resynchronizing the specified member (member). Resynchronization from Master in progress. Displayed by the member to indicate the master is in the process of resynchronizing it. Resynchronization complete. Displayed by the member to indicate the resynchronization has completed successfully. Resynchronization did not complete before timeout. Retrying. Indicates the master did not complete the resynchronization before the member expected it to complete and that the member is re-requesting resynchronization from the master for the remaining missed transactions. Master Selected As Partner (DEFAULT) Displayed by the member to indicate it has successfully connected with the master. Initiating Replication of Transaction <transaction #> with <# of elements> Elements. Displayed by the master to indicate that it is beginning replication of a transaction to the member. Replication Transaction #<transaction #> With <# of elements> Elements Initiated Displayed by the master to indicate that it has completed sending the transaction to the member. Committing Replication of Transaction <transaction #> with <# of elements> Elements. Displayed by the member to indicate that it has received a transaction and is processing it. Replication Transaction #<transaction#> With <# of element> Elements Committed Displayed by the member to indicate that the transaction has been successfully processed. Stopping Replication Manager Displayed at shutdown by both the master and member to indicate the replication manager is being shut down. Stopping Replication Manager - waiting for replication to complete... Displayed by the member when a shutdown is attempted while received replications are being processed. Once the replications are complete, the shutdown will complete. Replication in progress. Please wait... Periodically displayed while a shutdown is pending and replications are being completed. Replication Manager Stopped Displayed by both the master and member to indicate the replication manager has been successfully shutdown. Warning Log Messages Transaction Sync not received within configured TransactionSyncInterval. Communication with the Master may not be possible. The member displays this log messages to indicate that it has not received a TransactionSync message from the master within its configured TransactionSync interval. TXN_SYNC Received by Master from unknown member <ip address>. Validation Failed Displayed by the master when a TransactionSync message is received by the master. Since there can be only one configured master in a replication network, and the master is the only server who can send a TransactionSync message, this indicates there is another configured master in the replication network. TXN_SYNC Received from unknown Master <ip address>. Validation Failed Displayed by the member to indicate that a TransactionSync message was received from a server not configured as its master. Requesting resynchronization from Master: Last Txn#<transaction#> Displayed by the member to indicate that it is requesting resynchronization from the master. The LastTxn# is the last transaction number the member received and processed successfully. Resynchronization Request received from unknown member. Displayed by the master when a resynchronization request is received by a member who is not listed in its /radius/replication/rep members configuration. Resynchronization of <member name> requires Full Resynchronization. Displayed by the master to indicate that the member cannot be automatically resynchronized because its last transaction number is not within the configured history length of the archive (TransactionArchiveLimit). A manual resynchronization of the member is required to put the member back in-sync. MEMBER_SYNC Received from unknown Master at <ip address>. Validation Failed Displayed by a member indicating that a master, other than its configured master, is requesting partnership. MEMBER_SYNC Received by Master from unknown member <ip address>. Validation Failed Displayed by the master to indicate a member not listed in its /radius/replication/rep members configuration has requested partnership. TXN_EXPECT Received by Master from unknown <ip address>. Displayed by the master to indicate it has received a transaction which originated from another illegal master. TXN_EXPECT Received from unknown Master <ip address>. Displayed by the member to indicate it has received a transaction which originated from a master other than its configured master. TXN_EXPECT Broadcast failed. Indicates that the master could not initiate a replication. DATA_SYNC Received by Master from unknown <ip address> Displayed by the master to indicate that it received a replication transaction from another illegal master. DATA_SYNC Received from unknown <ip address> Displayed by the member to indicate that a transaction was received from a server external to the replication network. Error Log Messages DATA_SYNC Validation failed - CRC Mismatch Displayed by the member to indicate a received transaction element is invalid. TXN_SYNC: Failed To Get Member Socket Handle. TXN_SYNC: Failed to get master's socket handle. MEMBER_SYNC could not get socket handle TXN_EXPECT: Failed to get socket handle. DATA_SYNC could not get socket handle. These messages indicate an invalid interface configuration in Cisco Access Registrar. They could also be the result of specifying an invalid RepPort setting. Failed To Create TXN_SYNC packet. (out of packets?) Failed To Create TXN_SYNC packet. MEMBER_SYNC Failed to create packet.(out of packets?) MEMBER_SYNC Failed to create packet. TXN_EXPECT Failed to create packet.(out of packets?) TXN_EXPECT Failed to create packet. DATA_SYNC Create packet failed.(out of packets?) DATA_SYNC Create packet failed. These message indicate that a packet could not be created. This could be the result of a low memory condition or the result of the /Radius/Advanced/ MaximumNumberOfRadiusPackets setting being set too low TXN_SYNC validation failed - Internal error (pTxnSync=NULL). MEMBER_SYNC validate failed - Internal Error (pMemberSync=NULL) DATA_SYNC Validation Failed - Internal (pDataSync = NULL). TXN_EXPECT Could not add new datablock to pending transaction queue. Replication Member could not be added to member list. Replication Member could not be added to member list. These messages are the result of a failed memory allocation possibly due to an out of memory condition. DATA_SYNC Packet creation failed - Invalid ordinal. Attempt To Replicate Transaction With Zero Elements. Internal Error - Selected member not valid Internal Replication Error ChangeType <change type> For <element path> Internal error - Replication manager is invalid These messages indicate an internal application failure. Cannot archive transaction datablock Could not archive transaction These messages are the result of a failed archive attempt. This could be the result of a low disk space condition. Could not commit transaction to MCD Cannot Get Value For Unsupported DataType <data type id> MCD Replication Cannot Delete Value <element path> MCD Replication Cannot Delete Directory <element path> MCD Replication Cannot Delete Value For <element path> With Unsupported DataType <data type id> MCD Replication Cannot Create Dir For <element path> MCD Replication Cannot Set Value For <element path> MCD Replication Cannot Set Value For <element path> MCD Replication Cannot Set Value For <element path> MCD Replication Cannot Set Value For <element path> MCD Replication Cannot Set Value For <element path> With Unsupported DataType <data type id> MCD Replication Cannot Set Value For <element path> With UNKNOWN DataType <data type id> These messages are the result of a failed replication commit attempt. Log Messages You Should Never See The following list contains log messages which you should never see displayed in a log. If any of these messages are displayed in the log, contact Cisco Access Registrar technical support for assistance. <member name> Selected As Partner (DEFAULT) DATA_SYNC Received from non-partner <ip address> DATA_RE_SYNC CRC mismatch. Replying with NAK DATA_RE_SYNC Commit Failed. Replying with NAK EVAL_SYNC Validation failed. <ip address> is not a Master or Member of the Replication network EVAL_SYNC Received from unknown member. PARTNER_SYNC Received from unknown member <ip address>. PARTNER_SYNC Received from unknown member <ip address>. EVAL_SYNC Cannot get socket handle. EVAL_SYNC Failed to create packet.(out of packets?) EVAL_SYNC Failed to create packet. EVAL_SYNC Validation failed - Internal Error (pEvalSync=NULL). PARTNER_SYNC Failed to get socket handle. PARTNER_SYNC Failed to create packet. (out of packets?) PARTNER_SYNC Failed to create packet. DATA_RE_SYNC Can't get socket handle DATA_RE_SYNC Failed to create packet (out of packets?) DATA_RE_SYNC Failed to create packet DATA_RE_SYNC Failed validation - Internal Error (pReSync = NULL) DATA_RE_SYNC Cannot Set Value For <element path> DATA_RE_SYNC Cannot Set Value For <element path> DATA_RE_SYNC Cannot Set Value For <element path> DATA_RE_SYNC Cannot Set Value For <element path> DATA_RE_SYNC Cannot Set Value For <element path> With Unsupported DataType <data type id> DATA_RE_SYNC Cannot Set Value For <element path> With UNKNOWN DataType <data type id>; DATA_RE_SYNC Received by Master from unknown member <ip address> DATA_RE_SYNC Received from unknown Master <ip address>DATA_RE_SYNC Reply received by Master from unknown Member <ip address> Could not replicate data element to partners. Could not replicate to partners - Invalid Ordinal.
	© 1992-2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.