ISE 2.6 alarm "Queue Link Error"

[merylmohan]

Hi ,

ISE 2.6 gives the alarm "Queue Link Error"

Description says : 

"Please check and restore connectivity between the nodes. Ensure that the nodes are up and running. Ensure that ISE Messaging Service ports are not blocked by firewall. Please note that these alarms could occur between nodes, when the nodes are being registered to deployment or manually-synced from PPAN or when the nodes are in out-of-sync state or when the nodes are getting restarted"

All nodes are Up and Completely synced and has been up and running for more than 2 months. We have not restarted or resynced any of the nodes recently

Any ideas why we see this error?

[Garry Cross]

I don't see how this can be an accepted solution.

This post talks about having the CA running on ISE. In my case it is not running nor should it need to be unless you need CA in your network.

Also the bugs reported are supposedly fixed, one of which I can't view as I apparently have insufficient permissions.

I deleted all previous CSR's, created a new one that was not "Multi-use".

I thought the messages had stopped but they continue.

I am getting this message between all nodes in the deployment.

Queue Link Error: Message=From CANISE03.xxx.ca To STLISE01.xxx.ca; Cause=Timeout

One thing to note, we joined the nodes together using the self-signed and then installed one from GoDaddy.

It is version 2.6 with Patch 3 installed.

[Arne Bier]

@Garry Cross  - you're right - CA should not be running on an ISE deployment unless you're doing BYOD (and specifically the use case of BYOD where you're using the internal ISE CA - there are other BYOD use cases that don't use the ISE CA). But besides that, the solution to this error happens to be a workaround - I have found that by enabling the CA and then regenerating the CA certs, then the queue link error stops. Why? Who the heck knows. But it works. I have not seen a good explanation about this but it clears the alarm.

Don't look too closely under the hood of ISE ... the logs are full of errors that might give you nightmares. But on the surface, ISE presents a calm smiling face :-/

[obrien-r]

Unfortunately, we are running into this error even after enabling the CA, regenerating the ISE root certificate. And this is on ISE 2.6 Patch 3... Really is not fixed, and workarounds don't seem to be consistent in working or not...

[Arne Bier]

Have you had any luck with the TAC?

[t1mc]

I patched a 3 node deployment to Patch 6 and I am too encountering theese errors. I re-created the CA certs, ISE Messageing Service certs, reloaded all 3 nodes but the health status and logs of the third node (PSN only) was still not availble.

I just disabled the 'Use "ISE Messaging Service" for UDP Syslogs delivery to MnT' option and you wouldn't beleive it, but it started working.

I really hope that someone from Cisco reads this as some bugs suggest that this is fixed in Patch 6 but my experience it is obviously not. I also found this bug: CSCvr40715, wich has a severity of 'Enhancement'. I can hardly see the ability to see live logs from a node as an "Enhancement" but basic functionality, rather.

[Marvin Rhoads]

I had the issue myself on a recent ISE 2.6 upgrade. Went from 2.1 to 2.6 on a 4-node deployment. Everything working as expected on 2.6 (unpatched). I updated to 2.6 Patch 5 (heard some bad things about Patch 6) and then the RADIUS and TACACS Live Logs disappeared while Queue Link errors started happening.

I opened a TAC case and the assigned engineer confirmed they are seeing this on a lot of customer deployments. The Internal CA re-signing fixed the problem.

A couple of days later I did an upgrade on a 2-node deployment from 2.4 to 2.6 and then on to patch 5. The problem never manifested.

I guess that's why they call it a bug.

[t1mc]

I get it that it is a bug, but what I do not get it why it is logged as an Enhancement with 120 support cases logged on it. Who knows when this will get picked up by the devs and be actually fixed.

[Marvin Rhoads]

In my TAC case, the engineer cited a different BugID:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp45528/?rfs=iqvred

It's rated Sev 3 and supposed to have been fixed in ISE 2.6 Patch 2.

He shared verbally that subsequent patches failed to retain the fix.

[james.n.white36]

I was able to fix the issue using three steps without service interruption:

Step 1: Go to "Administration" -> "Certificates" -> "Certificate Signing Request".

Step 2: Click "Generate Signing Requests (CSR) -> Usage Certificate(s) will be used for "ISE Root CA". -> "Replace ISE Root CA Certificate Chain".

Step 3: Click "Generate Signing Requests (CSR) -> Usage Certificate(s) will be used for "ISE Messaging Service". -> Select all Nodes -> "Generate ISE Messaging Service Certificate"

This instantly resolved the bug. Everything was in sync and working but the status of the other node was not available along with receive the alerts.

If you do not have these options, this solution will not work for you.

[old_account_inacctive]

I tried that solution, but when I want to replace the certificat chain, I´m getting the following error:

"Plus License is out of compliance and trying generate Internal CA operations"

Does someone know how to resolve this?

[Arne Bier]

Do you have a screenshot?

Do (or did) you have an issue with Plus Licenses in general? Do you need them?

This should not have any impact on licensing at all. I suggest a TAC case. To be honest I have regenerated quite a few ISE 2.6 internal CA certs and never had an issue.

[old_account_inacctive]

Hi @Arne Bier,

thank you for your reply. I was also wondering, why I get a license warning, when trying to renew the certificate chain of the internal ca.

We never had any issues with the plus license, because we never used it and we dont have installed any Plus Licenses. We only have Device Admin and Base Licenses.

Attached you can find the screenshot of the error message.

[Greg Gibbs]

You're likely getting that error because the Internal CA is technically part of the BYOD feature set, which is a Plus licensed feature.

If the workaround requires regenerating the Internal CA chain but the current licensing does not permit that, you will likely need to open a TAC case.

[old_account_inacctive]

Thanks for clearing that up Greg.

Then I will open a TAC Case.

Thank you guys for your help!

[AMDMan64]

Any luck fixing this?  Our environment is showing the same error.   I have a TAC case open and we're unable to get logging from one of our servers due to the error.  The odd thing is 3 of our 4 servers got new certs, but this one is refusing to - our second administration node.

We used to have Plus licensing and we moved away from it.  The hosts that are working generated certs after we moved away, which is the strangest part.

Definitely not a cool situation.  Who cares if you generate a CA, you can't use it for anything except generating certs for signing requests, so that error is completely worthless.