- Introdução
- O que é o Queue Link / Queue Link Error ?
- Troubleshooting - Queue Link Error
- Cause=basic_cancel
- Cause=Timeout
- Cause=Econnrefused
- Cause={tls_alert;"handshake failure"}
- Cause={tls_alert;"unknown Ca"}
- Gerando Certificate Signing Requests (CSR)
- Outras Causas
- Efeitos do Queue Link Error !!!
- ISE Messaging Settings
- Light Data Distribution (LDD)
A versão em Inglês deste Artigo se encontra em: ISE- Queue Link Error.
 |
Para obter uma cópia off-line ou impressa deste documento, basta escolher ⋮ Opções > Página Amigável para Impressora. Você pode então Imprimir > Imprimir em PDF ou Copiar & Colar em qualquer outro formato de documento de sua preferência. |
Introdução
Este documento apresenta brevemente o significado do Queue Link Error, como lidar com ele e seu impacto na Implantação do ISE.
O que é o Queue Link / Queue Link Error ?
Desde o ISE 2.6 o ISE RabbitMQ Container foi renomeado para ISE Messaging Service (um Message Broker Container que é executado em um Docker). O ISE Messaging Service é iniciado em cada ISE Node e usado para trocar informações entre Nodes (via TLS usando um Certificado emitido pela CA Interna do ISE). Queue Link é a conexão entre esses Nodes, e Queue Link Error significa que algo deu errado!!!
Este Alarme é esperado caso você esteja realizando operações de Implantação, como: registrar um Node para Implantação, sincronizar manualmente um Node via PPAN, um Node fora de sincronia, o Application Service de um Node sendo reiniciado, alteração de Domain Name ou Hostname do PAN/PSN, restaurando um Backup em uma Nova Implantação ou Promovendo o PPAN Antigo para um PPAN Novo pós upgrade.
Você pode verificar o ISE Messaging Service via ISE CLI usando o seguinte comando:
ise/admin# show application status ise
ISE PROCESS NAME STATE PROCESS ID
--------------------------------------------------------------------
Database Listener running 15215
Database Server running 131 PROCESSES
Application Server running 27711
...
Docker Daemon running 16843
TC-NAC Service disabled
...
ISE Messaging Service running 43944
Segmentation Policy Service disabled
SSE Connector disabled
IMPORTANTE: " ... o Process Down alarm náo é mais acionado quando o ISE Messaging Service falha num Node. Quando o ISE Messaging Service falha num Node, TODOS os Syslogs e o Process Down alarm serão perdidos até que o Messaging Service seja reativado naquele Node... " (em Cisco ISE 3.1 Maintain and Monitor) !!!
Troubleshooting - Queue Link Error
Em ISE > Home você pode ver o registro Queue Link Error no painel Alarms:
Clique no registro Queue Link Error para abrir uma descrição detalhada do mesmo:
A descrição da Suggested Actions é:
"Por favor verifique e restaure a conectividade entre os Nodes.
Certifique-se de que os Nodes e o ISE Messaging Service estejam em funcionamento.
Certifique-se que as portas do ISE Messaging Service não estejam bloqueadas por um Firewall.
Por favor observe que estes Alarmes podem ocorrer entre Nodes, quando os Nodes estão sendo registrados no Deployment ou manualmente sincronizados via PPAN ou quando os Nodes estão fora de sincronismo ou quando os Nodes estão sendo reiniciados."
Você também pode verificar estas informações em Operations > Reports > Reports > Audit > Operations Audit > filtragem por:
- Object Type = System-Management
- Requested = The federation link was down or Event = Unknown CA
Nota: o ISE Messaging Services utiliza a port TCP/8671 !!! Por favor verifique o seguinte comando ISE CLI:
ise/admin# show ports
...
Process : docker-proxy (43916)
tcp: :::8671
Nota: o TCP/8671 é usado para TODOS os Nodes (PAN, MnT e PSN) para Inter-Node Communication. Dê uma olhada nos seguintes comandos ISE CLI:
isePAN/admin# show logging application ise-messaging/rabbit-ise-connection.log
...
2022-11-22 18:47:39.224 [error] <0.7017.0>@rabbit_reader:log_hard_error:785 Error on AMQP connection <0.7017.0> (<PSN IP Addr>:40486 -> 169.254.x.y:5671 - Federation link (upstream: E-Mesh-FOR-<PAN Hostname>:8671-TO-<PSN Hostname>, policy: Policy-FullMesh), vhost: '/', user: 'rabbitmq', state: running), channel 0:
...
isePSN/admin# show logging application ise-messaging/rabbit-ise-connection.log
2022-11-22 18:47:39.201 [warning] <0.3335.1078>@rabbit_reader:log_connection_exception_with_severity:447 closing AMQP connection <0.3335.1078> (<PAN IP Addr>:50533 -> 169.254.x.y:5671 - Federation link (upstream: E-Endpoints-FOR-<PSN Hostname>:8671-TO-<PAN Hostname>, policy: Policy-Endpoints), vhost: '/', user: 'rabbitmq'):
...
Exemplos de Causas que você pode ver na mensagem de Queue Link Error:
- Cause=Timeout
- Cause=Econnrefused
- Cause={tls_alert;"handshake failure"}
- Cause={tls_alert;"unknown Ca"}
Nota: também é possível ver a mensagem de Queue Link Error via ISE CLI com o seguinte comando:
ise/admin# show logging application ise-messaging/rabbit-ise-federation.log
...
2022-06-05 02:55:04.776 [warning] <0.446.0>@rabbit_federation_link_util:log:283 Federation exchange 'E-Mesh' in vhost '/' did not connect to exchange 'E-Mesh' in vhost '/' on amqps://<Node IP Addr>:8671
{error,{tls_alert,"unknown ca"}}
Cause=basic_cancel
O motivo para este erro aparecer geralmente é quando: alteração do hostname dos ISE Nodes ou houve um Node Promotion (há links residuais do Old PAN para o resto do Deployment que as vezes não são limpos na promotion)!!!
Por favor, dê uma olhada em:
- CSCvs01949 ISE Messaging service triggers Queue Link error alarms with the reason basic_cancel.
- CSCvr64000 Hostname change causes ISE Messaging issues - MNT Failover and Queue Link Error-basic_cancel.
Cause=Timeout
Este Alarme não causa impacto funcional, é potencialmente causado por Network Congestion durante o tempo entre alarmes em que os Nodes Alarm são acionados... este Alarme pode ser ignorado !!!
Por favor, veja em:
- CSCvv99093 ISE Nodes intermittently trigger Queue Link Alarms : Cause=Timeout.
- CSCwa82247 ISE Queue Link Error : Cause=Timeout due to 169.254.2.0/25 in ISE iptables.
- CSCwa43187 ISE Queue Link Error: Message=From Node1 To Node2; Cause=Timeout in NAT'ed deployment.
Verifique também o fluxo TCP 8671 entre os Nodes, via ISE CLI:
ise/admin# tech dumptcp 0 | inc 8671
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10.10.10.1.34190 > 10.10.10.2.8671: Flags [S], cksum 0x9544 (correct), seq 113726506, win 29200, options [mss 1460,sackOK,TS val 2259048610 ecr 0,nop,wscale 7], length 0
--
10.10.10.2.8671 > 110.10.10.1.34190: Flags [S.], cksum 0x5f32 (incorrect -> 0xf139), seq 1497652336, ack 113726507, win 28960, options [mss 1460,sackOK,TS val 2258331801 ecr 2259048610,nop,wscale 7], length 0
--
Cause=Econnrefused
Este Alarme é considerado cosmético. É potencialmente causado por um período de tempo em que não é possível se conectar ao seu Node e a conexão é recusada !!!
Por favor, veja em:
Cause={tls_alert;"handshake failure"}
Há vários motivos possíveis para o erro, mas na maioria das vezes é devido a um problema com a Certificate Chain usada pelo ISE Messaging Service. Por favor dê uma olhada em Gerando Certificate Signing Requests (CSR)
Cause={tls_alert;"unknown Ca"}
Existem várias razões possíveis para o erro:
1. quando a opção Dedicated MnT estiver selecionada (em Administration > System > Deployment > selecione o MnT Node e desmarque Dedicated MnT) ... dê uma olhada em?
2. ao utilizar um Third-Party signed certificate ... dê uma olhada em:
3. mas na maioria das vezes é devido a um problema com o Certificate Chain usado pelo ISE Messaging Service. Por favor, dê uma olhada abaixo em Gerando Certificate Signing Requests (CSR).
Gerando Certificate Signing Requests (CSR)
1º verifique se a Certificate Authority está ativada, em Administration > System > Certificates > Certificate Authority > Internal CA Settings > se você vir Disable Certificate Authority, então ela está ativada !!!
2º em Administration > System > Certificates > Certificate Management > Certificate Signing Requests > clique Generate Certificate Signing Requests (CSR):
Selecione ISE Messaging Service em Usage, selecione o Node(s) que deseja reemitir e gerar cliclando em Generate ISE Messaging Service Certificate:
A seguinte message aparece:
IMPORTANTE: durante a gera;áo do ISE Messaging Service NÃO há reboot ou interrupção no Deployment, apenas a inicialização do ISE Messaging Service !!!
3º se não for apenas um problema com o ISE Messaging Service de um determinado Node(s), talvez seja necessário substituir toda a Chain da Internal CAs, em Administration> System> Certificates> Certificate Management> Certificate Signing Requests > clique Generate Certificate Signing Requests (CSR) > selecione ISE Root CA em Usage e clique Replace ISE Root CA Certification Chain:
A seguinte message aparece:
IMPORTANTE 1: quando você substituiu o Cisco ISE Root CA chain, o Cisco ISE Messaging Service Certificate é também substituído. Isto é seguido pelo restart do Cisco ISE Messaging Service com um downtime de cerca de 2 minutos. Durante a substituição do ISE Root CA NÃO há reboot ou interrupção do Deployment !!!
IMPORTANTE 2: para evitar a perda dos Syslogs durante o downtime, desabilite por um curto período de tempo os Cisco ISE Messaging Services (em Administration > System > Logging > Log Settings > desmarque Use "ISE Messaging Service" for UDP Syslogs delivery to MnT) .
IMPORTANTE 3: se você notar um Slow Replication no Secondary Nodes após a regeneração do Root CA, então registrar novamente o Secondary Node irá corrigir o problema, dê uma olhada em:
IMPORTANTE 4: você não consegue regenearar o Root CA, se Essentials License estiver desabilitada na License Page (em Administration > System > License) , dê uma olhada em:
4º em Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates, Delete & Revoke velhos Certificates..
IMPORTANTE 1: quando você regera a Internal CA Root Chain, o ISE não exclui a Antiga automaticamente. Contanto que o ISE retenha a Root Chain Antiga, ele confiará nos Trust Certificates apresentados pelos Endpoints com Identity Certificates assinados por essa Chain (se for o caso) !!!
IMPORTANT 2: excluir Old Internal Certificates é uma etapa importante:
Para evitar bugs com 200+ Internal Certificates no PPAN que causam Slow UI, Slow Replication e High CPU/Load, dê uma olhada em:
Para evitar que a ação acima não funcione e gere erro:
Outras Causas
Outras causas do Queue Link Error:
Por favor, dê uma olhada em:
- CSCwa73860 After Upgrade, the files in the rabbitmq cert directory have incorrect permissions.
- CSCvz37241 Move Queue Link Error from WARN to Critical and Restart if Timeout
- CSCvr40715 Enhance CA to ensure certificate chain is intact post an upgrade or DB restore
- CSCvp45528 Queue Link Error alarm generated after signing of ISE CA certificate by external Root CA
Efeitos do Queue Link Error !!!
O Queue Link Error pode não ser prejudicial dependendo da situação de uso. Vejamos alguns exemplos em que o ISE Messaging Service é usado.
ISE Messaging Settings
Se houver um problema com Queue Link e houver um problema com a transferência de registros para o MnT entre PSN e MnT:
- Live Logs não são exibidos
- Report não é exibido
- Dashboard System Summary não é exibido
Além das medidas acima, esse evento pode ser recuperado desmarcando a opção Use "ISE Messaging Service" for UDP Syslogs delivery to MnT e alternando para "log transfer" que não passa pelo Messaging Service em Administration > System > Logging > Log Settings > ISE Messaging Settings:
Light Data Distribution (LDD)
Por favor, dê uma olhada em:
- CSCwc23593 LSD is causing high CPU
- CSCwa90930 Need hard Q cap on RMQ.
- CSCwc24037 Profiling causing high memory utilization on ISE 2.7P7.
- CSCvt63793 Posture - non redirection flow fails with "No policy server detected" when LSD is disabled.
- CSCwa15191 ISE: Endpoint stuck in posture unknown status due to LSD not able to find session by MAC.
- CSCwc41425 CIAM: BEMS01441628: Ise posture failed due to server issues on prod deployment (ISE 693656586).
- CSCwb47863 Redirectionless posture over flexVPN fails [CSR 8k].
- CSCwd46505 ISE-PIC does not show Queue Link Errors
- CSCvz37241 Move Queue Link Error from WARN to Critical and Restart if Timeout