Introduction
Este documento descreve como solucionar o problema de geração consolidado engine.log no Cisco Policy Suite (CPS).
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
A Cisco recomenda que você tenha acesso privilegiado ao acesso de raiz à CLI do CPS.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
No CPS, os registros do mecanismo de política são coletados de todas as máquinas virtuais (VMs) do Quantum Network Suite (QNS) e segregados na VM do cliente pcrfclient.
A estrutura de login é usada para coletar logs relacionados ao mecanismo de política e é salva/segregada na VM do cliente pcrfclient ativa.
Logback é uma estrutura de registro para aplicativos Java, criada como sucessora do popular projeto log4j.
Aqui está a configuração relevante do arquivo /etc/broadhop/logback.xml para a geração e coleta de registros do mecanismo.
1. Os logs do mecanismo de política são enviados a um anexador SOCKET.
<logger name="policy.engine" level="info" additivity="false">
<appender-ref ref="SOCKET" />
</logger>
2. O SOCKET Appender é referenciado ao SOCKET-BASE Appender.
<appender name="SOCKET" class="com.broadhop.logging.appenders.AsynchAppender">
<appender-ref ref="SOCKET-BASE"/>
3. SOCKET-BASE tem uma configuração pela qual os registros são enviados a um Host Remoto: Porta.
<appender name="SOCKET-BASE" class="com.broadhop.logging.net.SocketAppender">
<RemoteHost>${logging.controlcenter.host:-lbvip02}</RemoteHost>
<Port>${logging.controlcenter.port:-5644}</Port>
<ReconnectionDelay>10000</ReconnectionDelay>
<IncludeCallerData>false</IncludeCallerData>
</appender>
Problema
Se houver algum tipo de flap de rede ou erros relacionados ao TCP na configuração ambiental do CPS, a VM do cliente pcrfclient para de receber os logs de tipo de anexador SOCKET de VMs individuais.
A porta 5644, configurada em SOCKET-BASE mostra TIMEWAIT.
[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644
tcp6 0 0 192.168.10.135:5644 192.168.10.137:47876 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:57042 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:60888 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:60570 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:32902 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:57052 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:47640 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:36484 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:57040 TIME_WAIT -
tcp6 0 0 192.168.10.135:5644 192.168.10.137:55788 TIME_WAIT -
[root@dc1-pcrfclient01 ~]#
Se você verificar o mesmo status após alguns minutos, não haverá entradas relacionadas à porta 5644.
[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644
[root@dc1-pcrfclient01 ~]#
Solução
O procedimento para Restaurar a conexão SOCKET é reiniciar os processos qns-1 no pcrfclient ativo.
[root@dc1-pcrfclient01 ~]# monit stop qns-1
[root@dc1-pcrfclient01 ~]# monit status qns-1
Monit 5.26.0 uptime: 4d 22h 43m
Process 'qns-1'
status Not monitored
monitoring status Not monitored
monitoring mode active
on reboot start
data collected Tue, 04 Jan 2022 11:52:38
[root@dc1-pcrfclient01 ~]# monit start qns-1
[root@dc1-pcrfclient01 ~]# monit status qns-1
Monit 5.26.0 uptime: 4d 22h 42m
Process 'qns-1'
status OK
monitoring status Monitored
monitoring mode active
on reboot start
pid 25368
parent pid 1
uid 0
effective uid 0
gid 0
uptime 0m
threads 31
children 0
cpu 0.0%
cpu total 0.0%
memory 1.2% [197.4 MB]
memory total 1.2% [197.4 MB]
security attribute -
disk read 0 B/s [112 kB total]
disk write 0 B/s [60.2 MB total]
port response time -
data collected Tue, 04 Jan 2022 11:51:04
Feedback