Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Problem

Lösung

Einleitung

In diesem Dokument wird beschrieben, wie Sie das Problem der konsolidierten Engine.log-Generierung in der Cisco Policy Suite (CPS) beheben können.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Linux

- CPS

Cisco empfiehlt, dass Sie über einen privilegierten Zugriff auf die CPS-CLI verfügen müssen.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

- CPS 20,2

- UCS B

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

In CPS werden Richtlinien-Engine-Protokolle von allen Quantum Network Suite (QNS) Virtual Machine (VMs) gesammelt und an der VM von pcrfclient getrennt.

Das Logback-Framework wird zum Erfassen von Richtlinien-Engine-bezogenen Protokollen verwendet und wird bei aktivem pcrfclient VM gespeichert/separiert.

Logback ist ein Protokoll-Framework für Java-Anwendungen, das als Nachfolger des beliebten log4j-Projekts erstellt wurde.

Hier finden Sie die entsprechende Konfiguration aus der /etc/broadhop/logback.xml-Datei für die Erstellung und Erfassung von Motorprotokollen.

1. Richtlinien-Engine-Protokolle werden an einen SOCKET-Appender gesendet.

<logger name="policy.engine" level="info" additivity="false">

<appender-ref ref="SOCKET" />

</logger>

2. SOCKET Appender wird auf SOCKET-BASE Appender verwiesen.

<appender name="SOCKET" class="com.broadhop.logging.appenders.AsynchAppender">

<appender-ref ref="SOCKET-BASE"/>

3. SOCKET-BASE verfügt über eine Konfiguration, mit der die Protokolle an einen Remote-Host gesendet werden: Anschluss.

<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>

Problem

Wenn in der CPS-Umgebungskonfiguration irgendeine Art von Netzwerk-Flapping oder TCP-bezogenen Fehlern vorliegt, wird pcrfclient VM angehalten, SOCKET-Appender-Protokolle von einzelnen VMs zu empfangen.

Port 5644, konfiguriert unter SOCKET-BASE, zeigt TIMEWAIT an.

[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 ~]#

Wenn Sie den gleichen Status nach einigen Minuten überprüfen, gibt es keine Einträge für Port 5644.

[root@dc1-pcrfclient01 ~]# netstat -plan|grep 5644

[root@dc1-pcrfclient01 ~]#

Lösung

Das Verfahren zum Wiederherstellen der SOCKET-Verbindung besteht darin, die qns-1-Prozesse im aktiven pcrfclient neu zu starten.

[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