المقدمة
يصف هذا المستند المشاكل المتعلقة بحالات عدم تطابق UPF في RCM.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- مدير تكوين التكرار (RCM)
- وظيفة مستوى المستخدم (UPF/UP)
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
تجميع السجلات
RCM
الخطوة 1. التقاط بعض مخرجات الأوامر
أولا: يجب أن تحدد أولا ما هي المشكلة وما هو نمط المشكلة. من أجل تحديد وحدات UP التي شهدت عملية تحويل وتحديد مكان المشكلة الحالية، فمن الضروري توثيق أسباب المحولات.
rcm show-statistics switchover
rcm show-statistics switchover-verbose
rcm show-statistics configmgr --------------- to check how many UPs are registered for config push
rcm show-statistics controller --------------- to check no of UPs and its states registered with controller
الخطوة 2. تجميع سجلات وحدة التحكم والتكوين
ما إن يعين أنت بين أي UPs المشكلة يقع، أنت يستطيع جمعت جهاز تحكم سجل وشكلت سجل in order to حددت ما كان السبب من ال switchover وما الخطأ ل UPs أن يعلق في حالة معلقة.
ارجع إلى إرتباط مجموعة سجلات RCM لإجراء مجموعة السجلات.
يعمل
تغطي SSD، Syslogs، و SNMP ملائمات الطابع الزمني المثير للمشاكل، الإطار الزمني قبل ساعتين على الأقل من بدء الإصدار.
استكشاف الأخطاء وإصلاحها
سيناريو تثبيت UPs في حالة التعليق
- بصفة عامة، يقوم كل عنصر من عناصر UP بتسجيل نفسه في RCM عبر وحدة التحكم
- المراقب المالي مسؤول عن المحافظة على الولايات التي يتلقاها من الشركة ومن تلك التي يكلفه بها مدير نظم الإدارة وتجميعها
rcm show-statistics controller
message :
{
"keepalive_version": "f1ab207c5d3120f8a4286b999b9f4cd207034e7c61e204d74e41f48578c476de",
"keepalive_timeout": "20s",
"num_groups": 2,
"groups": [
{
"groupid": 1,
"endpoints_configured": 7,
"standby_configured": 1,
"pause_switchover": false,
"active": 2,
"standby": 0,
"endpoints": [
{
"endpoint": "X.X.X.X", -------- UP IP
"bfd_status": "STATE_UP",
"upf_registered": true,
"upf_connected": true,
"upf_state_received": "UpfMsgState_Active",
"bfd_state": "BFDState_UP",
"upf_state": "UPFState_PendActive",
"route_modifier": 32,
"pool_received": false,
"echo_received": 253,
"management_ip": "X.X.X.X",
"host_id": "SEUD2413",
"ssh_ip": "Y.Y.Y.Y",
"force_nso_registration": false
},
وفي إحصاءات المراقب المالي، إذا لوحظ وجود حالات مختلفة يحتفظ بها المراقب، ولكل دولة UP معناها الخاص.
حالة BFD - تشير إلى حالة BFD بين RCM و UP (لا تشير إليها على أنها حالة UF، فهي حالة BFD فقط)
حالة الاتحاد البريدي العالمي - الحالة الراهنة للإطار البرنامجي الشامل في آلية التنسيق الإقليمي
تم إستلام حالة UPF - تم إرسال UP من قبل UP إلى RCM
- وفقا للتدفق بشكل عام، في أي وقت يتم فيه التحويل من وضع الاستعداد إلى وضع الاستعداد، يجب أن يخضع RCM لإجراءات معينة لنقل البيانات بسلاسة والمذكورة هنا:
1. تدفق CheckPointMgr من مزامنة نقطة التفتيش و UP القديمة مع Active UP
2. تكوين تدفق البيانات
3. ضغط التهيئة
4 - إدارة الولايات الخاصة
ضع في اعتبارك مثال زوج UP ك UP-A (نشط UP) و UP-B (إستعداد-up) وعندما يكون هناك تبديل قبل أن يدخل في الحالات النشطة أو الاحتياطية فيدخل أولا في حالة الانتظار.
UP-A (نشط UP) — PendStandby — إستعداد
UP-B (وضع الاستعداد للأعلى) — PendActive — نشط
وكما يمكن ملاحظته قبل أن تصبح نشطة/جاهزة، فإن المعاملات الإجرائية المذكورة تحدث بين آلية التنسيق الإقليمي ووحدة التحكم في الوصول من أجل إجراء تبديل سلس.
- عند وجود محول من وضع الاستعداد النشط إلى وضع الاستعداد والعكس، يجب أن يقوم RCM بضغط تكوين حيث يدفع تكوين UP النشط في وضع الاستعداد الذي يصبح نشطا، ويدفع تكوين وضع الاستعداد لأعلى في وضع الاستعداد الذي يصبح في وضع الاستعداد.
Note :: In Standby UP normally RCM push all the UP config which are currently active so that whenever this UP becomes active it removes all the unwanted config
- بمجرد بدء تشغيل المحول، يكون ل RCM قيمة مؤقت مقدارها 15 دقيقة (تختلف حسب القيمة التي تم تكوينها) وضمن قيمة المؤقت هذه، يجب عليها إكمال المحول الذي يتم إنهاؤه بمجرد اكتمال عملية دفع التكوين.
- الآن في الحالة، لسبب ما إذا لم يتم إكمال الدفع config خلال وقت انتهاء صلاحية المؤقت وبدء RCM لإعادة التحميل إلى UP. ويستمر الحال هكذا حتى تكتمل عملية دفع التكوين.
- لذلك، عندما يدفع RCM التكوين إلى أعلى، فإنه يتوقع إشارة تكوين كاملة من UP بناء على أي RCM يفهم أن دفعة التكوين اكتملت ويعتبرها عملية تحويل ناجحة.
هذا هو السجل الذي يمكن رؤيته من syslogs و SNMP traps عند اكتمال دفع config.
Syslogs
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete
Nov 13 12:01:09 INVIGJ02GNR1D1UP12CO evlogd: [local-60sec9.041] [cli 30000 debug] [1/0/10935 <cli:1010935> cliparse.c:571] [context: local, contextID: 1] [software internal system syslog] CLI command [user rcmadmin, mode [local]INVIGJ02GNR1D1UP12CO]: rcm-config-push-complete end-of-config
SNMP
Fri Mar 24 09:59:01 2023 Internal trap notification 1425 (RCMTCPConnect) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1421 (RCMConfigPushCompleteSent) Context Name: rcm
Fri Mar 24 09:59:01 2023 Internal trap notification 1426 (RCMChassisState) RCM Chassis State: (2) Chassis State Standby
Fri Mar 24 09:59:04 2023 Internal trap notification 1276 (BFDSessionUp) vpn n6 OurAddr fc00:10:5:132::10 NeighborAddr fc00:10:5:132::254 Session(6/1090552866), Diagnostic code 0 PhyPortId 0
- ولكن في حالة وجود أي إصدار يتطلب اكتمال دفع التكوين وقتا يؤدي إلى انتهاء صلاحية قيمة المؤقت، تحدث مثل هذه المشاكل من UP العالق في حالة التعليق.
- نظرا لأن RCM لم يحصل على حالة إكمال دفع التكوين، فإنه يعتبر أن المحول غير مكتمل ويواصل المتابعة في حالة التعليق.
- يتم شرح الأسباب المختلفة لتكوين مشاكل الدفع في أسباب إعادة تحميل UP.
الحل
1. بشكل مؤقت، يمكنك فرض إشارة دفع التهيئة الكاملة من الأعلى باتجاه RCM باستخدام الأمر المذكور لإعادة التشغيل في حالة الاستعداد/النشط:
rcm-config-push-complete end-of-config
2. هذا الحل المذكور مؤقت فقط من أجل تحديد المشكلة التي تأخذ وقتا لضغط التهيئة والموضحة في أسباب إعادة تحميل UP.
التعليقات