دليل أستكشاف الأخطاء وإصلاحها ووكيل مجموعة CX

المقدمة

يتضمن هذا المستند الأسئلة المتداولة وسيناريوهات أستكشاف الأخطاء وإصلاحها التي قد يواجهها المستخدمون أثناء العمل مع "عميل سحابة CX".

النشر

س. هل إعادة توجيه عنوان URL إلى cloudfront.net هو سلوك متوقع عند الاتصال بمجال الخلفية لسحابة CX؟

ج.  نعم، بالنسبة لبعض سيناريوهات النشر المحددة، تمت إعادة التوجيه إلى موقع الويب cloudfront.net المتوقع. Oيجب السماح بالوصول غير المرتبط مع تمكين إعادة التوجيه على المنفذ 443 لهذه FQDN.

س. باستخدام خيار "إعادة التثبيت"، هل يمكن للمستخدم نشر وكيل سحابة CX الجديد باستخدام عنوان IP جديد؟

أ. نعم

س. ما هي تنسيقات الملفات المتوفرة للتثبيت؟

A. OVA و VHD

س. على أي بيئة يمكن نشر القابل للتثبيت؟

ج.  للحصول على OVA

• VMWare ESXi الإصدار 5.5 أو إصدار أحدث
• Oracle Virtual Box 5.2.30 أو إصدار أحدث

للحصول على دقة فائقة الوضوح (VHD)

• برنامج Windows Hypervisor 2012 إلى 2016

س. يستطيع CX سحابة وكيل كشف عنوان في DHCP بيئة؟

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

س. هل يدعم وكيل سحابة CX كلا من تكوين IPv4 و IPv6؟

أ. لا، يتم دعم IPv4 فقط.

س. أثناء تكوين IP، هل تم التحقق من صحة عنوان IP؟

أ. نعم، تم التحقق من صحة صياغة عنوان IP وتعيين عنوان IP مكرر.

س. كم من الوقت يستغرق نشر OVA وتكوين IP؟

أ. يعتمد نشر OVA على سرعة نسخ الشبكة للبيانات. يستغرق تكوين IP من 8 إلى 10 دقائق تقريبا بما في ذلك Kubernetes وإنشاء الحاوية.

س. هل هناك أية قيود فيما يتعلق بأي أنواع أجهزة؟

أ. يجب أن تستوفي الآلة المضيفة التي يتم نشر OVA عليها المتطلبات المقدمة كجزء من إعداد بوابة CX. يتم إختبار برنامج CX Cloud Agent مع برنامج VMware/Virtual Box الذي يعمل على جهاز مزود بمعالجات Intel Xeon E5 مع تعيين نسبة وحدة المعالجة المركزية (CPU) إلى وحدة المعالجة المركزية (CPU) على 2:1. في حالة إستخدام وحدة معالجة مركزية (CPU) ذات طاقة أقل أو نسبة أكبر، فإن الأداء يمكن أن ينخفض.

س. هل يمكن إنشاء رمز الازدواج في أي وقت؟

أ. لا، يمكن إنشاء رمز الازدواج فقط عندما لا يكون عميل سحابة CX مسجلا.

q. ما هي متطلبات النطاق الترددي بين مراكز Cisco Catalyst (لما يصل إلى 10 مجموعات أو 20 مجموعة غير مجموعات) ووكيل شبكة CX؟

لا يعد النطاق الترددي A.Bandwidth قيدا عندما يكون وكيل سحابة CX ومركز Cisco Catalyst في نفس شبكة LAN/WAN في بيئة العميل. الحد الأدنى للنطاق الترددي للشبكة المطلوب هو 2.7 ميجابت/ثانية لمجموعات المخزون من الأجهزة التي تبلغ 5000 +13000 نقاط وصول لعامل ما إلى اتصال مركز Catalyst من Cisco. إذا تم تجميع syslog لرؤى المستوى 2، فإن الحد الأدنى المطلوب لعرض النطاق الترددي هو 3.5 ميجابت/ثانية لتغطية 5000 جهاز +13000 نقطة وصول للمخزون و 5000 جهاز syslog و 2000 جهاز للمسح - يتم تشغيل جميع هذه الأجهزة بالتوازي من وكيل شبكة CX..

س. كيف يتم إستخدام syslogs للوكيل هل يمكن الوصول إليه لمراقبة الجهاز الظاهري لوكيل سحابة CX (VM)؟

أ. يمكن الوصول إلى Syslogs ل Agent VM من تسجيل الدخول إلى VM المحلي باستخدام المسارين التاليين:

/var/log/syslog.1 (يتم الوصول إليها من خلال عمليات تسجيل الدخول إلى Cxcadmin و cxcroot)

/var/log/syslog (يتم الوصول إليه باستخدام الجذر)

الإصدارات والتصحيحات

س. ما هي الأنواع المختلفة للإصدارات المدرجة لترقية وكيل سحابة CX؟

أ. يظهر هنا مجموعة من الإصدارات الصادرة من CX Cloud Agent المدرجة:

• A.x.0 (حيث يكون x هو أحدث إصدار لميزة الإنتاج الرئيسية، مثال: 1.3.0)
• A.x.y (حيث يعتبر A.x.0 ترقية إلزامية وتدريجية ليتم بدؤها، و X هو أحدث إصدار للميزة الرئيسية للإنتاج، و Y هو أحدث حزمة ترقية يتم تثبيتها مباشرة، على سبيل المثال: 1.3.1)
• A.x.y-z (حيث A.x.0 إلزامي وترقية تزايدية أن يكون بدأت، x هو أحدث إصدار للميزة الرئيسية للإنتاج، و Y هو أحدث تصحيح ترقية يكون مباشرا، و Z هو تصحيح التركيز الذي يعد إصلاحا فوريا لفترة قصيرة جدا من الوقت، على سبيل المثال: 1.3.1-1)

حيث A هو إصدار طويل المدى ينتشر عبر 3-5 سنوات.

س. أين يمكن العثور على أحدث إصدار من وكيل سحابة CX الذي تم إصداره وكيف يمكن ترقية وكيل سحابة CX الموجود؟

أ. لتحديد موقع أحدث عميل سحابة CX وترقيته إلى:

1. قم بتسجيل الدخول إلى بوابة سحابة CX وانتقل إلى مركز الإدارة. يظهر إطار مصادر البيانات.
2. حدد وكيل سحابة CX لفتح طريقة العرض التفصيلية وانقر فوق علامة التبويب البرامج.
3. قم بإجراء تحديد من القائمة إختيار إصدار برنامج للترقية إلى القائمة المنسدلة وانقر فوق تثبيت التحديث.

تكوين المصادقة والوكيل

س. ما هو المستخدم الافتراضي لتطبيق عامل سحابة CX؟

أ. cxcadmin.

س. كيف يتم تعيين كلمة المرور للمستخدم الافتراضي؟

أ. كلمات المرور يتم تعيينها أثناء تكوين الشبكة.

س. هل هناك خيار متاح لإعادة تعيين كلمة المرور بعد اليوم 0؟

a. لا يوجد خيار محدد بواسطة عميل سحابة CX لإعادة ضبط كلمة المرور، ولكن يمكنك إستخدام أوامر Linux لإعادة ضبط كلمة المرور ل cxcadmin.

س. ما هي سياسات كلمة المرور لتكوين وكيل سحابة CX؟

أ. سياسات كلمة المرور هي:

• تم تعيين الحد الأقصى للعمر (الطول) إلى 90 يوما
• الحد الأدنى للعمر (الطول) تم تعيينه إلى 8 أيام
• الحد الأقصى للطول 127 حرفا
• يجب تضمين حرف كبير واحد على الأقل وحرف حالة أقل واحد
• يجب أن تحتوي على حرف خاص واحد على الأقل (على سبيل المثال، !$٪^&*()_+|~-=\{}[]:؛'<>؟،/)
• غير مسموح بالحروف التالية
• √ أحرف خاصة ذات 8 بت (مثل ¬، √Termination، √¥، √É، Ho، √u)
• المسافات
• يجب ألا تكون آخر 10 كلمات مرور تم إستخدامها مؤخرا
• يجب ألا يحتوي على تعبير عادي
• يجب ألا تحتوي على الكلمات أو المشتقات التالية: Cisco و Sanjose و Sanfran

Q. كيف يمكنني تأكيد إمكانية الوصول إلى طبقة الأمان (SSH) إلى جهاز من وكيل سحابة CX؟

أ. لتأكيد إمكانية الوصول إلى SSH:

1. قم بتسجيل الدخول كمستخدم cxcroot.
2. قم بتنفيذ الأمر التالي لتمكين منفذ SSH في Iptables:

     IPTABLES -a إخراج -p tcp -m tcp — dport 22 -j قبول

3. قم بتنفيذ الأمر التالي لتأكيد إمكانية الوصول إلى SSH:

     SSH user@ip-address:Port

لتعطيل منافذ SSH التي تم تمكينها أعلاه في وكيل سحابة CX:

1. قم بتنفيذ الأمر التالي للحصول على رقم سطر منفذ SSH الذي تم تمكينه في الجداول:

     IPTABLES -L الإخراج —رقم الخط | GREP DPT | غروب ssh | AWK '{print$1}'

2. قم بتنفيذ الأمر التالي لحذف رقم السطر الذي تم الحصول عليه:

     IPTABLES -L إخراج <رقم السطر>

Q. كيف يمكنني تأكيد إمكانية الوصول إلى بروتوكول SNMP على جهاز من وكيل سحابة CX؟

أ. لتأكيد إمكانية الوصول إلى SNMP:

1. قم بتسجيل الدخول كمستخدم cxcroot.
2. قم بتنفيذ الأمر التالي لتمكين منافذ SNMP في Iptables:

      IPTABLES -A Output -p udp -m udp — Dport 161 -j ACCEPT

      IPTABLES -A Output -p udp -m udp — Dport 161 -j ACCEPT

3. قم بتنفيذ الأمر التالي snmpwalk/snmpget لتأكيد إمكانية الوصول إلى SNMP :

      snmpwalk -v2c -c IPADDRESS من Cisco

لتعطيل منافذ SNMP التي تم تمكينها أعلاه في وكيل سحابة CX:

1. قم بتنفيذ الأمر التالي للحصول على أرقام أسطر منافذ SNMP الممكنة (يتم إنشاء رقمي أسطر كاستجابة):

IPTABLES -L الإخراج —رقم الخط | GREP DPT | غروب ssh | AWK '{print$1}'

2. قم بتنفيذ الأمر التالي لحذف أرقام البنود (بترتيب تنازلي):

IPTABLES -L إخراج <رقم السطررقمان>

IPTABLES -L إخراج <رقم السطررقم واحد>

س. كيف يمكنني تعيين كلمة مرور المجموعة؟

أ. لتعيين كلمة مرور المجموعة:

1. قم بتشغيل .ssh ك cxcroot وتقديم الرمز المميز [اتصل بفريق الدعم للحصول على رمز cxcroot المميز].
2. قم بتنفيذ الأمر su، لتوفير نفس الرمز المميز.
3. قم بتنفيذ الأمر grub-mkpasswd-pbkdf2 وقم بتعيين كلمة مرور المجموعة. ستتم طباعة تجزئة كلمة المرور التي تم تقديمها، ونسخ المحتوى.
4. vi to the file /etc/grub.d/00_header. 
5. انتقل إلى نهاية الملف واستبدل إخراج التجزئة الذي يتبعه المحتوى password_pbkdf2 root **** مع التجزئة التي تم الحصول عليها لكلمة المرور التي تم الحصول عليها في الخطوة 3.
6. احفظ الملف باستخدام الأمر: wq!.
7. قم بتنفيذ الأمر update-group.

س. ما هي فترة انتهاء صلاحية كلمة مرور cxcadmin؟

أ. تنتهي كلمة السر في 90 يوما.

س. هل يقوم النظام بتعطيل الحساب بعد محاولات تسجيل الدخول غير الناجحة المتتالية؟

أ. نعم، يتم تعطيل الحساب بعد خمس (5) محاولات غير ناجحة متتالية. مدة قفل الحساب هي 30 دقيقة.

س. كيف يمكنني إنشاء عبارة مرور؟

أ. لإنشاء عبارة مرور:

1. قم بتشغيل .ssh وتسجيل الدخول كمستخدم cxcadmin.
2. قم بتنفيذ الأمر remoteaccount cleanup -f.
3. قم بتنفيذ الأمر remoteAccount create.

س. هل يدعم المضيف الوكيل كل من اسم المضيف و IP؟

أ. نعم، ولكن لاستخدام اسم المضيف، يجب على المستخدم توفير IP لخادم اسم المجال (DNS) أثناء تكوين الشبكة.

بروتوكول النقل الآمن (SSH)

س. ما هي الشفرات التي تدعمها طبقة ssh؟

أ. التشفير التالي مدعوم:

• chacha20-poly1305@openssh.com
• aes256-gcm@openssh.com
• aes128-gcm@openssh.com
• الطراز aes256-ctr
• الطراز aes192-ctr
• الطراز aes128-ctr

س. كيف يمكنني تسجيل الدخول إلى وحدة التحكم؟

أ. لتسجيل الدخول:

1. تسجيل الدخول كمستخدم cxcadmin
2. توفير كلمة مرور cxcadmin

س. هل تم تسجيل عمليات تسجيل دخول SSH؟

A. نعم، إنها تسجل كجزء من var/logs/audit/audit.log". ملف

س. ما هي مهلة جلسة العمل الخاملة؟

a. تحدث مهلة جلسة SSH إذا كان وكيل سحابة CX خاملا لمدة خمس (5) دقائق.

المنافذ والخدمات

Q. ما المنافذ التي يتم الاحتفاظ بها مفتوحة على وكيل سحابة CX؟

أ. تتوفر هذه المنافذ التالية:

• المنفذ الصادر: يمكن أن يتصل عامل سحابة CX الذي تم نشره بالطرف الخلفي من Cisco كما هو موضح في الجدول على منفذ HTTPS 443 أو عبر وكيل لإرسال البيانات إلى Cisco كما هو موضح في الجدول أدناه. يمكن أن يتصل عميل سحابة CX المنشور بمركز Cisco Catalyst على منفذ HTTPS 443.

الأمريكتين	أوروبا والشرق الأوسط وإفريقيا	أبيك
cloudsso.cisco.com	cloudsso.cisco.com	cloudsso.cisco.com
api-cx.cisco.com	api-cx.cisco.com	api-cx.cisco.com
agent.us.csco.cloud	agent.emea.cisco.cloud	agent.apjc.cisco.cloud
ng.acs.agent.us.csco.cloud	ng.acs.agent.emea.cisco.cloud	ng.acs.agent.apjc.csco.cloud

ملاحظة: بالإضافة إلى المجالات المدرجة، عند قيام عملاء EMEA أو APJC بإعادة تثبيت وكيل سحابة CX، يجب السماح بمجال agent.us.csco.cloud في جدار حماية العميل.
لم يعد مجال agent.us.csco.cloud مطلوبا بعد إعادة التثبيت الناجحة.

ملاحظة: تأكد من أنه يجب السماح بحركة المرور العائدة على المنفذ 443.

• Inbound port: بالنسبة للإدارة المحلية لوكيل سحابة CX، يجب الوصول إلى 514(Syslog) و 22 (SSH). يجب على العملاء السماح بالمنفذ 443 في جدار الحماية الخاص بهم لتلقي البيانات من سحابة CX.

اتصال وكيل سحابة CX ب Cisco Catalyst Center وأصول أخرى

q. ما هو غرض وعلاقة Cisco Catalyst Center بوكيل سحابة CX؟

a. مركز Cisco Catalyst هو وكيل السحابة الذي يدير أجهزة شبكة فرضية العميل. يقوم "عميل سحابة CX" بجمع معلومات مخزون الأجهزة من مركز Cisco Catalyst Center الذي تم تكوينه وتحميل معلومات المخزون المتوفرة في طريقة عرض الأصول ل CX Cloud.

q. أين يمكن للمستخدمين توفير تفاصيل مركز Cisco Catalyst حول وكيل سحابة CX؟

a. أثناء اليوم 0 - إعداد وكيل سحابة CX، يمكن للمستخدمين إضافة تفاصيل مركز Cisco Catalyst من بوابة سحابة CX. أثناء عمليات اليوم N، يمكن للمستخدمين إضافة مراكز Cisco Catalyst إضافية منAdmin Settings > Data Source.

q. كم عدد مراكز Cisco Catalyst التي يمكن إضافتها؟

a. يمكن إضافة عشر (10) مجموعات Cisco Catalyst Center أو 20 مجموعة Cisco Catalyst Center غير مجموعات.

q. كيف يمكنني إزالة مركز Cisco Catalyst Center المتصل من وكيل سحابة CX؟ 

a. لإزالة مركز Catalyst المتصل من وكيل سحابة CX، اتصل بمركز المساعدة التقنية (TAC) لفتح حالة دعم من بوابة سحابة CX.

q. ما الدور الذي يمكن لمستخدم مركز Cisco Catalyst أن يلعبه؟

أ. يمكن أن يكون دور المستخدم إما مسؤول أو مراقب.

q. كيف يتم انعكاس التعديلات في وكيل السحابة CX بسبب التغييرات في بيانات اعتماد Cisco Catalyst Center المتصلة؟

a. قم بتنفيذ الأمر CXCLI Agent ModifyController من وحدة تحكم عميل السحابة CX:

    اتصل بدعم أي مشكلة أثناء تحديث بيانات اعتماد Cisco Catalyst Center.

q. كيف يتم تخزين تفاصيل مركز Cisco Catalyst وأصول الملف الأولي في وكيل سحابة CX؟

أ. يتم تشفير جميع البيانات بما في ذلك بيانات اعتماد وحدات التحكم المتصلة بوكيل السحابة CX (مثل مركز Cisco Catalyst) والأصول المتصلة مباشرة (على سبيل المثال عبر ملف أولي، نطاق IP)، باستخدام AES-256 ويتم تخزينها في قاعدة بيانات وكيل السحابة CXالتي يتم حمايتها بمعرف مستخدم وكلمة مرور مضمون.

س. هل هناك أي قيود على إدخال نطاقات IP عند إضافة أصول أخرى؟

a. نعم، يتعذر على "عميل سحابة CX" معالجة عمليات الاكتشاف لنطاقات IP للشبكات الفرعية الأكبر. توصي Cisco باستخدام نطاقات الشبكات الفرعية الأقل عددا والتي تقتصر على 10000 عنوان IP.

س. هل يمكن إستخدام شبكة فرعية عامة لنشر CX Cloud Agent الإصدار 2.4 للشبكة الفرعية المخصصة للمجموعات والخدمات؟

a. لا توصي Cisco باستخدام شبكة IP فرعية عامة للأسباب التالية:

• المخاطر الأمنية: يعرض عنوان بروتوكول الإنترنت العام المجموعات والخدمات على الإنترنت، مما يزيد من خطر الوصول غير المصرح به والهجمات واختراقات البيانات المحتملة.
• تعارضات عناوين IP: يمكن أن يؤدي إستخدام شبكات IP الفرعية العامة إلى تعارضات IP، وخاصة إذا تم تعيين عناوين IP نفسها في مكان آخر على الإنترنت، مما يؤدي إلى مشاكل في الاتصال والسلوك غير المتوقع.
• تعقد في تكوين الشبكة: إدارة سياسات الشبكة وقواعد جدار الحماية والتوجيه تصبح أكثر تعقيدا عند التعامل مع عناوين IP العامة. وقد يؤدي ذلك إلى حدوث أخطاء في التهيئة وزيادة مصروفات الصيانة.

يمكن إستخدام شبكة IP فرعية عامة إذا تم تعيينها فقط إلى مؤسسة عميل وإعدادها عبر شبكة العميل.

س. كم مرة يمكن فيها بدء عملية إعادة الاكتشاف؟

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

س. ما هو سير العمل لإضافة "أصول أخرى كمصدر بيانات" عند تحميل ملف أولي؟

أ. سير العمل كما يلي:

1. تحميل ملف البداية في سحابة CX.
2. يتم تخزين الملف الأولي مؤقتا في دلو Cisco Cloud AWS S3 (مع تمكين تشفير SSE).
3. يتم دفع ملف البداية إلى عميل سحابة CX ويتم حذف الملف الأولي من دلو S3
4. يعالج "عميل سحابة CX" إدخالات الملف الأولي ويشفر بيانات الاعتماد باستخدام مفتاح AES 256 (هذا المفتاح فريد لكل عميل سحابة CX). يتم تخزين بيانات الاعتماد المشفرة هذه في قاعدة بيانات عامل سحابة CX.
5. يتم حذف الملف الأولي من "عامل سحابة CX" بمجرد معالجة إدخالات الملف الأولي.

q. ما نوع التشفير المستخدم أثناء الوصول إلى واجهة برمجة تطبيقات Cisco Catalyst Center من وكيل سحابة CX؟

يتم إستخدام A. HTTPS عبر TLS 1.2 للاتصالات بين وكيل سحابة Cisco Catalyst Center و CX.

q. ما هي العمليات التي يتم تنفيذها بواسطة وكيل سحابة CX على وكيل سحابة Cisco Catalyst Center المدمج؟

يجمع A. CX Cloud Agent البيانات من Cisco Catalyst Center حول أجهزة الشبكة ويستخدم واجهة مشغل الأمر Cisco Catalyst Center للتحدث عن الأجهزة الطرفية وتنفيذ أوامر CLI (show command). لا يتم تنفيذ أوامر تغيير التكوين.

q. ما هي البيانات الافتراضية التي يتم تجميعها من مركز Cisco Catalyst وتحميلها إلى الطرف الخلفي؟

ج.  

• كيان الشبكة
• الوحدات
• show version
• التكوين
• معلومات صورة الجهاز
• العلامات

q. ما هي البيانات الإضافية التي يتم تجميعها من مركز Cisco Catalyst وتحميلها إلى خلفية Cisco؟

أ. راجع هذا المستند للحصول على مزيد من المعلومات. 

س. كيف يتم تحميل بيانات المخزون إلى الخلفية؟

يقوم عميل سحابة A. CX بتحميل بيانات المخزون عبر بروتوكول TLS 1.2 إلى خادم الخلفية من Cisco.

س. ما هو تكرار تحميل المخزون؟

a. يتم تشغيل التجميع وفقا للجدول المحدد من قبل المستخدم ويتم تحميله إلى الخلفية من Cisco. 

س. هل يمكن للمستخدم إعادة جدولة المخزون؟

أ. نعم، يتوفر خيار من مركز الإدارة > مصادر البيانات لتعديل معلومات الجدول.

q. متى تحدث مهلة الاتصال بين Cisco Catalyst Center ووكيل السحابة؟

ألف- تصنف المهل على النحو التالي:

• بالنسبة للاتصال الأولي، يكون الحد الأقصى للمهلة 300 ثانية. إذا لم يتم إنشاء الاتصال بين Cisco Catalyst Center و Cloud Agent في غضون خمسة (5) دقائق كحد أقصى، فينتهي الاتصال.
• بالنسبة للتكرار أو النموذجي أو التحديثات: مهلة الاستجابة هي 1800 ثانية. في حالة عدم تلقي الاستجابة أو عدم تمكنها من القراءة في غضون 30 دقيقة، ينتهي الاتصال.

المسح الضوئي التشخيصي المُستخدم لصالح CX Cloud Agent (وكيل CX Cloud)

س. ما هي أوامر المسح الضوئي التي يتم تنفيذها على الجهاز؟

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

س. أين يتم تخزين نتائج المسح الضوئي وتقديمها؟

أ. يتم تخزين النتائج التي تم مسحها ضوئيا وبروزها في خلفية Cisco.

q. هل التكرارات (حسب hostname أو IP) في مركز Cisco Catalyst، التي تمت إضافتها إلى الفحص التشخيصي عند توصيل مصدر Cisco Catalyst Center؟

a. لا، تتم تصفية التكرارات بحيث يتم إستخراج الأجهزة الفريدة فقط.

س. ماذا يحدث عندما يفشل أحد فحوص الأوامر؟

أ. توقف فحص الجهاز تماما وتم وضع علامة عليه كغير ناجح.

س. ماذا يحدث عندما تتداخل مسحات ضوئية متعددة؟

أ. يمكن أن يؤدي تنفيذ العديد من عمليات الفحص التشخيصي في نفس الوقت إلى إبطاء عملية الفحص ومن المحتمل أن يؤدي إلى حدوث حالات فشل في المسح الضوئي. توصي Cisco بجدولة عمليات الفحص التشخيصي أو بدء تشغيل عمليات الفحص عند الطلب على الأقل من 6 إلى 7 ساعات بخلاف جداول تحصيل المخزون حتى لا تتداخل.

سجلات نظام CX Cloud Agent (وكيل CX Cloud)

س. ما هي المعلومات الصحية التي يتم إرسالها إلى بوابة سحابة CX؟

أ. سجلات التطبيقات، حالة POD، تفاصيل مركز Cisco Catalyst، سجلات التدقيق، تفاصيل النظام، وتفاصيل الأجهزة.

س - ما تفاصيل النظام وتفاصيل الأجهزة التي يتم جمعها؟

ألف. نموذج الإخراج: 

system_details:{
"os_details":{
"containerRuntimeVersion":"docker://19.3.12"،
"KernelVersion":"5.4.0-47-generic"،
"kubeProxyVersion":"v1.15.12"،
"kubeletVersion":"v1.15.12"،
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f"،
"نظام التشغيل":"Linux"،
"OSimage":"Ubuntu 20.04.1 LTS"،
"systemUID":"42002151-4131-2ad8-4443-8682911bdadb"
},
"hardware_details":{
"total_cpu":"8"،
"cpu_utilization":"12.5٪"،
"total_memory":"16007 ميجابايت"،
"free_memory":"9994 ميجابايت"،
"hdd_size":"214G"،
"free_hdd_size":"202G"
}
}
}

س. كيف يتم إرسال البيانات الصحية إلى الخلفية؟

a. باستخدام وكيل سحابة CX، تعمل خدمة الصحة (إمكانية الخدمة) على تدفق البيانات إلى الخلفية من Cisco.

س. ما هو نهج الاحتفاظ بسجل البيانات الصحية لعامل السحابة CX في الخلفية؟

أ. يكون نهج الاحتفاظ بسجل البيانات الصحية لعامل السحابة CX في الخلفية 120 يوما.

س. ما أنواع التحميلات المتوفرة؟

ج.  

1. تحميل المخزون
2. تحميل Syslog
3. تحميل حماية العميل، بما في ذلك تحميل الصحة
   1. حالة الخدمات - كل خمس (5) دقائق
   2. Podlog - كل (1) ساعة
   3. سجل التدقيق - كل (1) ساعة

استكشاف الأخطاء وإصلاحها

المشكلة: لا يمكن الوصول إلى IP الذي تم تكوينه.

الحل: قم بتنفيذ SSH باستخدام IP الذي تم تكوينه. إذا انتهت مهلة الاتصال، فإن السبب المحتمل هو تكوين IP بشكل خاطئ. في هذه الحالة، أعِد التثبيت من خلال تكوين عنوان IP صالح. يمكن القيام بذلك من خلال المدخل مع توفير خيار إعادة التثبيت فيAdmin Centerالصفحة.

المشكلة: كيف يمكنني التحقق من تشغيل الخدمات بعد التسجيل؟

الحل: اتبع الخطوات التالية للتأكد من تشغيل أجهزة الكمبيوتر المحمولة:

1. ssh لعنوان IP الذي تم تكوينه كـ cxcadmin
2. قم بإدخال كلمة المرور
3. تنفيذ الأمر kubectl get pods

يمكن أن تكون PODS في أي حالة (تشغيل، تهيئة، أو إنشاء الحاوية). بعد 20 دقيقة، يجب أن تكون نقاط الوصول في حالة تشغيل.

إذا لم تكن الحالة قيد التشغيل أو تهيئة Pod، فتحقق من وصف Pod باستخدام الأمر kubectl description pod <podname>.

يحتوي الإخراج على معلومات حول حالة POD.

المشكلة: كيفية التحقق من تعطيل اعتراض SSL في وكيل العميل؟
الحل: قم بتنفيذ الأمر curl الموضح هنا للتحقق من قسم شهادة الخادم. تحتوي الاستجابة على تفاصيل الشهادة الخاصة بخادم الويب المجمع.

curl -v — العنوان 'Authorization: Basic xxxxx' https://concsoweb-prd.cisco.com/

* شهادة الخادم:

* الموضوع: C=US؛ St=California؛ L=San Jose؛ O=Cisco Systems، Inc.؛ CN=concsoweb-prd.cisco.com

* تاريخ البدء: 16 فبراير: 11:55:11 2021 بتوقيت جرينتش

* تاريخ انتهاء الصلاحية: 16 فبراير الساعة 12:05:00 2022 بتوقيت جرينتش

* subjectAltName: المضيف "consoweb-prd.cisco.com" مطابقة للمرجع "concsoweb-prd.cisco.com"

* المصدر: C=US؛ O=HydrantID (Avalanche Cloud Corporation)؛ CN=HydrantID SSL CA G3

* التحقق من صحة شهادة SSL.

> GET / HTTP/1.1

الإصدار: فشلت أوامر kubectl وتظهر الخطأ حيث "تم رفض الاتصال بالخادم X.X.X.X:6443 - هل حددت المضيف أو المنفذ الأيمن"
الحل:

• تحقّق من توفر الموارد. [مثال: وحدة المعالجة المركزية، الذاكرة].
• انتظر حتى تبدأ خدمة Kubernetes.

المشكلة: كيف يمكنك الحصول على تفاصيل فشل التجميع لأمر/جهاز؟

الحل:

• قم بتنفيذ Kubectl احصل على مجموعة البيانات واحصل على اسم مجموعة البيانات.
• قم بتنفيذ سجلات Kubectl <collectionPodName> للحصول على تفاصيل الأمر/الجهاز المحددة.

الإصدار: الأمر kubectl لا يعمل مع الخطأ "[authentication.go:64] غير قادر على مصادقة الطلب بسبب خطأ: [x509: انتهت صلاحية الشهادة أو لم تعد صالحة بعد، x509: انتهت صلاحية الشهادة أو لم تصبح صالحة بعد]"

الحل:قم بتشغيل الأوامر المعروضة هنا كمستخدم Cxcroot

RM /var/lib/rancher/k3s/server/tls/dynamic-cert.json
إعادة تشغيل النظام K3s
kubectl — insecure-skip-tls-verify=true delete secret -n kube-system k3s-serving
إعادة تشغيل النظام K3s

الاستجابات لفشل المجموعة

ويمكن أن يكون سبب فشل المجموعة أي قيود أو مشكلات تظهر مع وحدة التحكُّم المُضافة أو الأجهزة الموجودة في وحدة التحكُّم.

يحتوي الجدول الموضح هنا على قصاصة الخطأ للاستخدام الحالات التي تم رؤيتها ضمن خدمة Collection الدقيقة أثناء عملية التجميع.

حالة الاستخدام	تسجيل المقتطف في الخدمة المصغّرة للمجموعة
إذا لم يتم العثور على الجهاز المطلوب في مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "errorMessage": " لم يتم العثور على جهاز بالمعرف 02eb08be-b13f-4d25-9d63-eaf4e882f71a " }
إذا لم يكن الجهاز المطلوب يمكن الوصول إليه من مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "حدث خطأ أثناء تنفيذ الأمر: show version\nError المتصل بالجهاز [المضيف: 172.21.137.221:22]لا يوجد مسار إلى المضيف: لا يوجد مسار إلى المضيف " }
إذا لم يكن الجهاز المطلوب يمكن الوصول إليه من مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "حدث خطأ أثناء تنفيذ الأمر: show version\nError المتصل بالجهاز [المضيف: X.X.X.X]انتهت مهلة الاتصال: /X.X.X.X:22: انتهت مهلة الاتصال: /X.X.X.X:22" }
إذا كان الأمر المطلوب غير متوفر في الجهاز	{   "command": "show run-config"،   "الحالة": "النجاح"،   "commandResponse": " حدث خطأ أثناء تنفيذ الأمر: show running-config\n\nshow run-config\n ^\n٪ تم اكتشاف إدخال غير صالح في \u0027^\u0027 mark.\n\nXXCT5760#"،   "رسالة الخطأ": "" }
إذا كان الجهاز المطلوب لا يحتوي على SSHv2 ويحاول مركز Cisco Catalyst Center توصيل الجهاز باستخدام SSHv2	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "errorMessage": "حدث خطأ أثناء تنفيذ الأمر: show version\nSSH2 channel المغلقة: يستخدم الطرف البعيد بروتوكولا غير متوافق، وهو غير متوافق مع SSH-2." }
في حال يتم تعطيل الأمر في الخدمة المصغّرة للمجموعة	{   "command": "config paging disable"،   "status": "command_disabled"،   "commandResponse": "مجموعة الأوامر معطلة"،   "رسالة الخطأ": "" }
إذا فشلت مهمة مشغل الأوامر ولم يتم إرجاع عنوان URL للمهمة بواسطة مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "errorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s. عنوان URL للمهمة فارغ. }
إذا فشلت مهمة مشغل الأوامر في الإنشاء في مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s. لا توجد تفاصيل مهمة. }
إذا لم تكن Collection MicroService تتلقى إستجابة لطلب تشغيل الأوامر من Cisco Catalyst Center	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s." }
إذا لم يقم مركز Cisco Catalyst بإكمال المهمة ضمن المهلة التي تم تكوينها (5 دقائق لكل أمر في Collection MicroService)	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "Operation Timedout. فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s. لا توجد تفاصيل عن التقدم. }
إذا فشلت مهمة مشغل الأوامر وكان معرف الملف فارغا للمهمة المرسلة بواسطة مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s. معرف الملف فارغ. }
إذا فشلت مهمة مشغل الأوامر ولم يتم إرجاع علامة معرف الملف بواسطة مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s. لا توجد تفاصيل حول معرف الملف. }
إذا كان الجهاز غير مؤهل لتنفيذ مشغّل الأوامر	{     "command": "config paging disable"،     "الحالة": "فشل"،     "إستجابة الأوامر": "،"     "ErrorMessage": "الأجهزة المطلوبة غير موجودة في المخزون، جرب مع الأجهزة الأخرى المتوفرة في المخزون"   }
في حال يتم تعطيل مشغّل الأوامر للمستخدم	{ أمر: "show version"، "الحالة": "فشل"، "إستجابة الأوامر": "،" "ErrorMessage": "{\"message\":\"لا يحتوي الدور على أذونات صالحة للوصول إلى API\"}\n" }

الاستجابات لفشل المسح الضوئي التشخيصي

يمكن أن تكون حالات فشل المسح الضوئي والأسباب من أي من المكونات المدرجة.

عندما يبدأ المستخدمون الفحص من البوابة، قد ينتج عن ذلك أحيانا "خطأ خادم داخلي".

سبب المشكلة هو أحد المكونات المدرجة

• نقطة التحكم
• عبّارة بيانات الشبكة
• الموصل
• المسح الضوئي التشخيصي
• خدمات CX Cloud Agent المصغّرة [devicemanager (مدير الجهاز) وcollection (المجموعة)]
• مركز Catalyst من Cisco
• APIX
• Mashery
• الوصول إلى الأمر Ping
• IRONBANK
• IRONBANK GW
• وسيط البيانات الكبير (BDB) 

لمشاهدة السجلات:

1. قم بتسجيل الدخول إلى وحدة تحكم عميل سحابة CX.
2. تنفيذ Kubectl الحصول على بودز. 
3. الحصول على اسم POD الخاص بالمجموعة والوصل وقابلية الخدمة.
4. للتحقق من سجلات خدمة microService الخاصة بالجمع والوصل وقابلية الخدمة.

• تنفيذ سجلات Kubectl <collectionpodname>  
• تنفيذ سجلات Kubectl <connector>
• تنفيذ سجلات Kubectl <service>

يعرض الجدول أدناه قصاصة الخطأ التي تم رؤيتها ضمن سجلات خدمة المجموعة الدقيقة وإمكانية الخدمة الدقيقة التي تحدث بسبب المشاكل/القيود المتعلقة بالمكونات.

حالة الاستخدام	تسجيل المقتطف في الخدمة المصغّرة للمجموعة
يمكن الوصول إلى الجهاز ودعمه، ولكن الأوامر التي يتم تنفيذها على هذا الجهاز موجودة في مجموعة الخدمات الدقيقة	{   "command": "config paging disable"،   "status": "command_disabled"،   "commandResponse": "مجموعة الأوامر معطلة"، }
إذا كان جهاز الفحص غير متوفر. يحدث في سيناريو، عند وجود مشكلة مزامنة بين المكونات مثل البوابة والمسح التشخيصي ومكونات CX ومركز Cisco Catalyst	لم يتم العثور على جهاز مع id 02eb08be-b13f-4d25-9d63-eaf4e882f71a
إذا كان الجهاز الذي تتم محاولة فحصه مشغولا، (في سيناريو) حيث كان نفس الجهاز جزءا من مهمة أخرى ولا تتم معالجة أي طلبات متوازية من Cisco Catalyst Center للجهاز	يتم الآن بالفعل الاستعلام عن جميع الأجهزة المطلوبة بواسطة مشغل الأوامر في جلسة عمل أخرى. يرجى تجربة أجهزة أخرى
إذا كان الجهاز غير مدعوم للمسح الضوئي	الأجهزة المطلوبة غير موجودة في المخزون، جرب مع الأجهزة الأخرى المتوفرة في المخزون
إذا كان الجهاز الذي تمت محاولة فحصه غير قابل للوصول إليه	"حدث خطأ أثناء تنفيذ الأمر: show udi\nError الاتصال بالجهاز [المضيف: x.x.x.22] لا يوجد مسار إلى المضيف: لا يوجد مسار إلى المضيف
إذا لم يكن مركز Cisco Catalyst قابلا للوصول إليه من وكيل السحابة أو خدمة التجميع الدقيقة لعامل السحابة لا يستقبل إستجابة لطلب مشغل الأوامر من مركز Cisco Catalyst	{   أمر: "show version"،   "الحالة": "فشل"،   "إستجابة الأوامر": "،"   "ErrorMessage": "فشلت مهمة مشغل الأمر للجهاز ٪s، RequestURL: ٪s." }

حالة الاستخدام	مقتطف السجل في الخدمة المصغّرة لوكيل نقطة التحكم
إذا كان طلب المسح الضوئي يحتوي به تفاصيل جدول مفقودة	فشل تنفيذ الطلب {"رسالة":"23502: القيمة الخالية في العمود \"schedule\" تخالف القيد غير الفارغ"}
إذا كان طلب المسح الضوئي يحتوي به تفاصيل أجهزة مفقودة	فشل إنشاء نهج المسح الضوئي. لا توجد أجهزة صالحة في الطلب
إذا كان الاتصال بين CPA والاتصال معطلاً	فشل تنفيذ الطلب
إذا لم يكن الجهاز المطلوب للمسح الضوئي متوفرًا في عمليات المسح الضوئي التشخيصية	فشل إرسال الطلب لإجراء الفحص. السبب = {\"الرسالة\":\"لم يتم العثور على الجهاز الذي يحمل اسم المضيف=x.x.x'\"}