I wonder if someone could please help me discover why we can't get our primary Cisco Secure ACS, UK-SU-AP091, to replicate with our secondary Cisco Secure ACS, UK-SU-AP092?
They can both talk to each other, but the replication status is stuck in pending. See attachment.
Any help will be greatly appreciated..
Please login to the secondary unit via ssh and enter "show application status acs". Let us know what the output is.
Thanks-ever-so-much for getting back to me.
The problem is, we can't even log into the secondary ACS because it hasn't synchronized with the primary with the new username and passwords.
We're in a real bind here. You're help will be greatly appreciated..
The login I'm talking about is using the local account userid (admin) and password - not any credential in the ACS database or remote system (e.g. AD or LDAP) identity store. If you don't have that password then you'd have to reboot it and do a password recovery.
The reason we use this one is to see if the services are runing and restart them if necessary. That's the most common cause of the primary unit showing the secondary as offline.
Thanks again for responding.
I must say, as simple as it seems, I never thought of that approach. We thought that because the the online status indicates that it's offline and we have rebooted the server a number of times it must be something other than services.
Marvin, shouldn't the services start after a reboot?
BTW, the server is a Linux box..
Yes the services SHOULD start upon reboot but if they didn't then I would expect the symptoms you are seeing. That's not the only possibility but it is the most likely one.
While you in the cli you can also verify reachability of the other server. If all services are runing on both servers and there is connectiivty between them on the requisite ports (tcp/2000 is used for database replication)
I can ping the secondary server from the primary.
Are you saying that my only option is to access the device with admin password or do a password recovery and restart the services?
Well that's not your ONLY option. It's by far the best one. The primary server is attempting to communicate with the secondary and for whatever reason not succeeding.
If there is no reachability problem or firewall blocking the necessary ports in between then my first guess (95% + probability) would be that the services are not up on the secondary server.
If you cannot access the cli to check that, then you could do more obscure and less helpful checks like capture the traffic towards the secondary server from the local switch port where it connects to the network and examine for the incoming calls from the primary and the responses (if any) from the secondary. You could do a port scan (i.e. using nmap) on the secondary server and see if it responds to tcp/2000 (database replication) and/or tcp/49 and tcp/1812 (TACACS and RADIUS respectively).
After all of that and at the end of the day though, you're going to need to get into that secondary server. Not having local admin cli access is not a tenable long term situation to operate a production HA deployment.