Introducción
Este documento describe cómo resolver el problema de generación de unified-engine.log en Cisco Policy Suite (CPS).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
Cisco recomienda que tenga acceso privilegiado al acceso raíz a CPS CLI.
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y 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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
En CPS, los registros del motor de políticas se recopilan de todas las máquinas virtuales (VM) de Quantum Network Suite (QNS) y se separan en la VM de pcrfclient.
El marco de Logback se utiliza para recopilar registros relacionados con el motor de políticas y se guarda/separa en la VM activa pcrfclient.
Logback es un marco de registro para aplicaciones Java, creado como sucesor del popular proyecto log4j.
Esta es la configuración relevante del archivo /etc/broadhop/logback.xml para la generación y recolección de registros del motor.
1. Los logs del motor de políticas se envían a un Appender SOCKET.
<logger name="policy.engine" level="info" additivity="false">
<appender-ref ref="SOCKET" />
</logger>
2. Se hace referencia a SOCKET Appender en SOCKET-BASE Appender.
<appender name="SOCKET" class="com.broadhop.logging.appenders.AsynchAppender">
<appender-ref ref="SOCKET-BASE"/>
3. SOCKET-BASE tiene una configuración, por la cual los registros se envían a un Host Remoto: Puerto.
<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
Si hay algún tipo de inestabilidad de red o errores relacionados con TCP dentro de la configuración del entorno CPS, la VM pcrfclient se detiene para recibir los registros de tipo de apéndice SOCKET de VM individuales.
El puerto 5644, configurado en SOCKET-BASE, muestra 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 ~]#
Si verifica el mismo estado después de unos minutos, no hay entradas relacionadas con el puerto 5644.
[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644
[root@dc1-pcrfclient01 ~]#
Solución
El procedimiento para restaurar la conexión SOCKET es reiniciar los procesos qns-1 en el pcrfclient activo.
[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
Comentarios