CLUSTER ISE 3.1 - SYSTEM SUMMARY NO DATA

[Mohamad Lukman]

we have upgraded ISE from 2.6 to 3.1, our ISE client is in Cluster mode and when upgrading we do Deregister
to upgrade the node,
The ise upgrade is divided into 2 phases, phase 1 is an upgrade for ise01 and phase 2 is an upgrade for ise02
After completing the upgrade, we re-register to create a cluster, to setup the ISE

ISE01: PRI(A) SEC(M)
ISE02: SEC(A) PRI(M)

but after a few days after the upgrade ISE01: [system summary no data], ISE02: [data appears],

Is there a misconfiguration, resulting in system summary no data in ISE01?

please provide a solution teams...

[Arne Bier]

Hi Mohamad,

There is no need to manually de-register any nodes when performing an ISE upgrade. In an ISE deployment of any size (2 or more nodes) the first ISE node to be upgraded is always the Secondary PAN.  When you run the upgrade on that one, ISE automatically de-registers itself from the Primary PAN. The Secondary is de-registered because that is the only way to make a new Deployment (by making that node the new Primary).

Whether or not that broke your upgrade is unclear to me. It should not have broken it.

Have you patched the new node?

If the new node is Primary Admin, Primary Monitoring, and it's patched, then there should be no reason I can think of, why it doesn't show node health.

I would upgrade the other node and then register them both back together.

If you get Queue Link Errors, then create a Cert Singing Request for the ISE Internal CA.  That will fix that issue.

If however you are using ISE for ISE BYOD feature, then don't do this lightly. 

[Mohamad Lukman]

Hi Bier,

Thank you for replying to this case,

ise we already use Pacth8, (Software 3.1 Pacth
we found this on Logg Queue

Description:
Queue Link Error: Message=Certificate Issue From ISE02.intra.net To ISE01.intra.net; Cause={tls_alert;{unknown_ca;"tls Client: In State Certify At Ssl_handshake.erl:1887 Generated Client Alert: Fatal - Unknown CA\n"} Action=Regenerate ISE Messaging Service Certificate

Does this log require generating a certificate again, is there any other way besides generating a certificate again?

[Arne Bier · Accepted solution]

If you don't use the internal CA for things like BYOD, then there is no risk in renewing this. It has no downtime and can be done at any time.  The ISE Messaging Service has its own certificate, which you can also renew (as a CSR) - but it's never resolved the issue for me and my customers. The 100% sure solution is to renew the ISE Internal CA cert.