المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

معلومات أساسية

المشكلة

الحل

المقدمة

يوضح هذا المستند كيفية أستكشاف أخطاء إنشاء المحرك المدمج وإصلاحها.log في مجموعة سياسات Cisco (CPS).

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- لينكس

- CPS

cisco يوصي أن أنت ينبغي يتلقى امتياز وصول إلى الجذر إلى CPS CLI.

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

- CPS 20.2

- UCS-B

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

في CPS، يتم تجميع سجلات محركات السياسات من جميع الأجهزة الظاهرية لمجموعة شبكة الكم (QNS) ويتم فصلها في الجهاز الظاهري PCRFCLIENT.

يتم إستخدام إطار عمل تسجيل الدخول السابق لجمع السجلات المتعلقة بمحرك السياسة ويتم حفظه/فصله في VM نشط ل pcrfclient.

Logback هو إطار عمل تسجيل لتطبيقات Java، تم إنشاؤه كخلف لمشروع Popular Log4j.

وفيما يلي التكوين ذي الصلة من ملف /etc/broadhop/logback.xml لإنشاء سجلات المحركات وتجميعها.

1. يتم إرسال سجلات محرك النهج إلى ملحق مأخذ التوصيل.

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

<appender-ref ref="SOCKET" />

</logger>

2. تتم الإشارة إلى ملقم مأخذ التوصيل إلى ملقم قاعدة مأخذ التوصيل.

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

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

3. تحتوي قاعدة مأخذ التوصيل على تكوين يتم من خلاله إرسال السجلات إلى مضيف بعيد: المنفذ.

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

المشكلة

إن هناك أي نوع من رفرفة الشبكة أو TCP خطأ متصل ضمن ال CPS بيئة setup، PCRFCLIENT VM يتوقف أن يستلم ال مقبس ملحق نوع سجل من VMs فرد.

يظهر المنفذ 5644، الذي تم تكوينه تحت Socket-Base وقت الانتظار.

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

إذا قمت بالتحقق من نفس الحالة بعد بضع دقائق، فلا توجد إدخالات متعلقة بالمنفذ 5644.

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

[root@dc1-pcrfclient01 ~]#

الحل

الإجراء الخاص باستعادة اتصال مأخذ التوصيل هو إعادة تشغيل عمليات QNS-1 في PCRFclient النشط.

[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