Cisco ISE 2.4 - Unable to login to secondary admin

[dgaikwad]

Hi Experts,

Recently we have deployed a new ISE 2.4 cluster.

So there are some use cases that we wanted to check and create a guidelines document for these scenarios.

I went to the command line of the primary admin, ran halt.

The primary went down, and then I went to the secondary, entered the internal admin credentials... 

It got stuck at the login window itself..

I waited for a few minutes thinking that there might be the process that is taking over, but nothing happened...

After shutting down the primary it took almost 15 minutes for me login back to Secondary.

During all this time I was able to login to the CLI...

The real question that remains is that, is this expected behavior? Should the login to the secondary be instantons?

Since such a behavior will panic the admin team...

[paul]

Do you have PAN autofailover enabled?  Depending on how fast you went to the secondary admin you could have been in a PAN failover situation.  The process usually takes 20-30 min depending on your timers.  There is a service restart as part of the failover.

[dgaikwad]

We have not configured auto-failover in our cluster.

What we were doing was to just to replicate the issue that might occur when we move this cluster to production.

So, when we were testing this out, it took more than 15 minutes for me to login to the secondary and then select the promote to primary settings.

Is this something of a known behavior?

Or are we missing on any configuration from our end?

[anthonylofreso]

Whenever I need to do something like this, I will always login to the secondary and promote to primary. Once promotion is complete, I go back and halt the other PAN.

Administration > System > Deployment , click on PAN, 'Promote to Primary'

We had issues with auto fail over, so decided to disable it.

[Jason Kunst]

Also recommend becoming familiar with the admin guide sections on it and the Cisco live presentation from Craig Hyps

Performance and scale

https://community.cisco.com/t5/security-documents/ise-training/ta-p/3619944

[dgaikwad]

We have not configured auto-failover in our cluster.

What we were doing was to just to replicate the issue that might occur when we move this cluster to production.

So, when we were testing this out, it took more than 15 minutes for me to login to the secondary and then select the promote to primary settings.

Is this something of a known behavior?

Or are we missing on any configuration from our end?

[anthonylofreso]

I've never timed it. 15 minutes seems long, but could be normal. It definitely takes longer than 5 minutes for promotion to occur.

[paul]

If I had to guess I would say your services restarted on the secondary admin when you tried to login. I have seen that issue before, usually if the customer is doing VM snapshots which are not allowed in an ISE environment. You should be able to log into your secondary admin at any time.

[dgaikwad]

I was wondering the same if the services would have been restarted on the secondary when we stopped primary, but I ruled that out since there is no automatic failover configured.

I was wondering if there are any logs that I could refer to check out if such a thing happened.

Since, the login itself took more than 15 minutes, even before I could promote it to the primary.

[anthonylofreso · Accepted solution]

Seemed un-related at first, but might be worth checking. We've had an issue for a while now (TAC took a crack at it, and now the BU is working the case) where our local Admin account will get disabled. Evident by messages in the 'Alarms' dashlet on the dashboard reading "Administrator Account Locked/Disabled"
I'll spare you the details, just to keep the conversation relevant. Unless you are also seeing this.
[cid:image001.png@01D4556D.0BE0DFF0]

[anthonylofreso]

eh, was curious if you could reply by email, with images. It appears not. Screenshot attached to this.

[Jason Kunst · Accepted solution]

Agree look at with the tac

[dgaikwad]

Worked with a TAC yesterday, to replicate the issue.

Unfortunately, was not able to replicate the issue, as per the TAC it could have been cosmetic.

What log parameters do I need to keep enabled if I face this issue in the future?

[Jason Kunst]

The TAC should have the answer