Introduction
The AAA servers are configured on each Wireless LAN Controller. My controllers have both servers defined with Server1-Primary and Server 2-Secondary. Primary ACS server have been hanging and not responding but it is not failing over secondary ACS server which is configured as backup server.
The ACS servers are installed on VMware with the following configuration:
Cisco Secure ACS
Version : 5.2.0.26
Failover will only occur if the primary doesn't respond. If the primary responds even though its hosed up, the wlc will not failover.
If your ACS is a primary secondary and the primary gets hung up but the secondary still doesn't take over the primary role, then you might have an issue with the primary and you should maybe promote the secondary as the primary and fix the issue with the primary because the WLC will still send request to the primary if that is how it is defined in your wlan, until the primary doesn't respond and is marked dead.
Well, You need to make sure that the primary server is really down. The issue has been the "hangup" does not cause the server to be completely down.
Understanding Full Replication
Under normal circumstances, each configuration change is propagated to all secondary instances. Unlike ACS 4.x where full replication was performed, in ACS 5.2, only the specific changes are propagated. As configuration changes are performed, the administrator can monitor (on the Distributed System Management page) the status of the replication and the last replication ID to ensure the secondary server is up to date.
If configuration changes are not being replicated as expected, the administrator can request a full replication to the server. When you request full replication, the full set of configuration data is transferred to the secondary server to ensure the configuration data on the secondary server is re synchronized.
Note
Replication on the Message Bus happens over TCP port 61616. Full replication happens over the Sybase DB TCP port 2638.
ACS 4.x and 5.2 Replication
In ACS 4.x, you must select the database object types (or classes) you wish to replicate from primary instance to the secondary instance. When you replicate an object, a complete configuration copy is made on the secondary instance.
In ACS 5.2, any configuration changes made in the primary instance are immediately replicated to the secondary instance. Only the configuration changes made since the last replication are propagated to the secondary instance.
ACS 4.x did not provide incremental replication, only full replication, and there was service downtime for replication. ACS 5.2 provides incremental replications with no service downtime.
You can also force a full replication to the secondary instance if configuration changes do not replicate it. Full replication is used when a new secondary instance is registered and other cases when the replication gap between the secondary instance and the primary instance is significant.
lists some of the differences between ACS 4.x and 5.2 replication.
Differences Between ACS 4.x and 5.2 Replication
ACS 5.2
You can choose the data items to be replicated. | You cannot choose the data items to be replicated. All data items, by default are replicated. |
Supports multi-level or cascading replication. | Supports only a fixed flat replication. Cascading replication is not supported. |
Some data items such as, the external database configurations are not replicated. | All data items are replicated. |
Replicating a Secondary Instance from the Distributed System Management Page
Note
All ACS appliances must be in sync with the AD domain clock.
To replicate a secondary instance:
Step 1Choose System Administration > Operations > Distributed System Management.
The Distributed System Management page appears.
Step 2 From the Secondary Instances table, check one of check boxes next to the secondary instances that you want to replicate.
Step 3 Click Full Replication.
The system displays the following warning message:
This operation will force a full replication for this secondary server. ACS will be restarted. You will be required to login again. Do you wish to continue?
Step 4 Click OK.
Step 5 Log in to the ACS machine.
Step 6 Choose System Administration > Operations > Distributed System Management.
The Distributed System Management page appears. On the Secondary Instance table, the Replication Status column shows UPDATED. Replication is complete on the secondary instance. Management and runtime services are current with configuration changes from the primary instance.
Replicating a Secondary Instance from the Deployment Operations Page
Note
All ACS appliances must be in sync with the AD domain clock.
To replicate a secondary instance:
Step 1Choose System Administration > Operations > Local Operations > Deployment Operations.
The Deployment Operations page appears. See the Table 17-6 for valid field options.
Step 2 Click Force Full Replication.
Note
The Force Full Replication button only appears if the secondary instance is the local machine you are logged in to.
The system displays the following warning message:
This operation will force a full replication for this secondary server. ACS will be restarted. You will be required to login again. Do you wish to continue?
Step 3 Click OK.
Step 4 Log into the ACS machine.
Step 5 Choose System Administration > Operations > Distributed System Management.
The Distributed System Management page appears. On the Secondary Instance table, the Replication Status column shows UPDATED. Replication is complete on the secondary instance. Management and runtime services are current with configuration changes from the primary instance.
Reference
Migration Guide for the Cisco Secure Access Control System 5.2 - Replication
User Guide for Cisco Secure Access Control System 5.2 - ACS 4.x and 5.2 Replication
This document was generated from the following discussion: Wireless ACS not failin gover