فحص خدمات الجرد بمركز الدنا والمسائل المشتركة

المقدمة

يصف هذا المستند المفاهيم الأساسية لخدمة جرد مركز بنية الشبكة الرقمية (DNA) من Cisco والمشاكل الشائعة الموجودة في الإنتاج.

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

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

تفاصيل خدمة المخزون

تستند خدمة مخزون مركز بنية الشبكة الرقمية من Cisco إلى Kubernetes (K8s) Pod الذي يمكنك العثور عليه قيد التشغيل في مساحة الاسم "fusion" مع الاسم apic-em-inventory-manager-service-<id>" كنوع بيئة نشر.

بداخل K8s pod، أنت يستطيع وجدت Docker حاوية تسمى apic-em-inventory-manager-service".

تتمثل المهام الرئيسية ل APIC-em-inventory-manager-service" في اكتشاف الأجهزة وإدارة دورة حياة الأجهزة.

وهذا يضمن توفر بيانات الجهاز في Postgres SQL (قاعدة البيانات المستخدمة بواسطة خدمات الاندماج).

توفر مساحة اسم "fusion" (Appstack) المعروفة أيضا باسم النظام الأساسي لوحدة التحكم في الشبكة (NCP) خدمات إطار عمل إمداد الخدمة (SPF) لجميع متطلبات أتمتة الشبكة.

تتضمن هذه المعايير الاكتشاف والجرد والهيكل والسياسة وإدارة صور البرامج (SWIM) وأرشفة التكوين ومبرمج الشبكة والمواقع والتجميع والقياس عن بعد وتكامل Tesseract ومبرمج القوالب والخرائط و iPAM وأجهزة الاستشعار والتزامن/سير العمل/الجدولة وتكامل ISE وما إلى ذلك.

يمكن التحقق من حالة قائمة مكونات التخزين من خلال تشغيل الأمر: 

$ magctl appstack status | grep inventory

يمكن التحقق من حالة خدمة المخزون باستخدام الأمر:

$ magctl service status

يمكن فحص سجلات خدمة المخزون باستخدام الأمر:

$ magctl service logs -r

في هذا المستند، يمكننا التركيز على "إدارة أجهزة المخزون" وحالة المزامنة الأخيرة لمراجعة المشكلات الشائعة:

حالة قابلية الإدارة

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

حالة آخر مزامنة

• مدار: الجهاز في حالة تتم إدارتها بالكامل.

• فشل التحصيل الجزئي: الجهاز في حالة تجميع جزئي ولم يتم تجميع جميع معلومات المخزون. قم بتحريك المؤشر فوق أيقونة المعلومات (i) لعرض معلومات إضافية حول الفشل.

• يتعذر الوصول: يتعذر الوصول إلى الجهاز ولم يتم تجميع معلومات المخزون بسبب مشاكل في اتصال الجهاز. يحدث هذا الشرط عند إجراء عملية جمع دورية.

• بيانات اعتماد غير صحيحة: إذا تم تغيير بيانات اعتماد الجهاز بعد إضافة الجهاز إلى المخزون، فسيتم ملاحظة هذه الحالة.

• قيد التقدم: يتم تنفيذ مجموعة المخزون.

مشاكل

خطأ داخلي

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

"خطأ داخلي: NCIM12024: تعذر تجميع جميع المعلومات من الجهاز بنجاح أو أن مجموعة المخزون لهذا الجهاز لم تبدأ بعد. قد تكون مشكلة مؤقتة يمكن حلها تلقائيا. أعد مزامنة الجهاز، إذا لم يحل ذلك المشكلة، فيرجى الاتصال ب Cisco TAC."

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

• بيانات اعتماد جهاز غير صحيحة ل SNMP و SSH و NetConf.
• مشاكل اتصال الشبكة المتعلقة ب SNMP و SSH و NetConf.
• تتسبب مشكلات تكوين NetConf في الجهاز في عدم عمل NetConf بشكل صحيح.
• قم بتشغيل إعادة مزامنة الجهاز أثناء تنفيذ مزامنة الجهاز بالفعل. 
• تم تلقي العديد من الملائمات من الجهاز مما تسبب في عدة مشغلات إعادة مزامنة في فترة زمنية قصيرة.
• مشاكل النهاية الخلفية مع إدخالات قاعدة بيانات المخزون في جداول متعددة متعلقة بالجهاز.

بيانات اعتماد الجهاز

لمراجعة بيانات اعتماد الجهاز، انتقل إلى قائمة مركز بنية الشبكة الرقمية (DNA) من Cisco -> التزويد -> الجرد -> تحديد الجهاز -> الإجراءات -> الجرد -> تحرير الجهاز وانقر فوق "التحقق" وتأكد من أن بيانات الاعتماد الإلزامية (CLI و SNMP) تمر بعملية التحقق من الصحة باستخدام تحقق أخضر (بما في ذلك NetConf إذا كانت تنطبق).

في حالة فشل التحقق من الصحة، الرجاء مراجعة صلاحية اسم المستخدم وكلمة المرور اللذين يستخدمهما مركز بنية الشبكة الرقمية من Cisco لإدارة جهاز الشبكة مباشرة في سطر أوامر الجهاز.

إذا تم تكوينها محليا أو إذا تم تكوينها في خادم AAA (TACACS أو RADIUS)، فيرجى التحقق من تكوين اسم المستخدم وكلمة المرور بشكل صحيح في خادم AAA.

أيضا فحصت إن ال username يتطلب امتياز أن يتلقى ال "enable" كلمة إعداد في الأداة ورقة اعتماد عملية إعداد في cisco dna cإدخال المخزون.

الأخطاء في مسوغات CLI يمكن أن تتسبب في رسالة خطأ قابلية الإدارة في المخزون: فشل مصادقة CLI.

نيتكونيف

NetConf هو بروتوكول لإدارة جهاز شبكة متوافق عن بعد من خلال مكالمات الإجراء البعيد (RPC).

يستخدم مركز بنية الشبكة الرقمية (DNA) من Cisco إمكانات NetConf لدفع التكوين أو إزالته على أجهزة الشبكة لتمكين ميزات مثل المراقبة عبر Assurance.

يمكن أيضا لمخزون مركز بنية الشبكة الرقمية من Cisco التحقق من أن متطلبات NetConf صحيحة، والتي تتضمن:

• NetConf ميناء افتراضي 830 أن يكون مفتوحا ويعمل في الشبكة.
• مستخدم مع الامتياز 15 مع وصول SSH إلى جهاز الشبكة (محليا أو تكوين AAA).
• تمكين NetConf في جهاز الشبكة:

(config)#netconf-yang

• في حالة تمكين نموذج AAA جديد، يلزمك أيضا تكوين متطلبات إعدادات AAA الافتراضية:

(config)#aaa authorization exec default 
     
(config)#aaa authentication login default 
     

قد تؤدي الأخطاء في بيانات اعتماد NetConf إلى ظهور رسالة خطأ في إدارة النظام في المخزون: فشل اتصال NetConf.

تحققات الشبكة

كما يمكننا التحقق من اتصال الشبكة وإعدادات البروتوكولات مثل إعدادات SNMP وفقا للإصدار.

على سبيل المثال، يمكننا التحقق مرتين من إعدادات المجتمع والمستخدم والمجموعة ومعرف المحرك والمصادقة والتشفير وما إلى ذلك اعتمادا على إصدار SNMP. 

كما يمكننا مراجعة اتصال SSH و SNMP باستخدام الأوامر ping وtraceroute في سطر أوامر الجهاز والمنافذ الخاصة ب SSH (22) و SNMP (161 و 162) في جدار الحماية أو الوكيل أو قوائم الوصول.

من مركز بنية الشبكة الرقمية من Cisco، واجهة سطر الأوامر (CLI) التي تستخدم أوامر ip route للتحقق من الاتصال بجهاز الشبكة.

كما يمكن إستخدام المشي عبر بروتوكول SNMP لاستكشاف الأخطاء وإصلاحها.

قد تؤدي الأخطاء في بيانات اعتماد SNMP إلى ظهور رسالة خطأ في إدارة المخزون: فشل مصادقة SNMP أو يتعذر الوصول إلى الجهاز.

جداول قاعدة البيانات

كمستخدم نهائي، يمكنك إستخدام واجهة المستخدم الرسومية (GUI) لمركز بنية الشبكة الرقمية (DNA) من Cisco مع Grafana لتنفيذ استعلامات SQL حتى لا تحتاج إلى الوصول إلى طبقة Postgres عبر واجهة سطر الأوامر (CLI) باستخدام Maglev.

بعض جداول قواعد بيانات ترحيل الصفحات التي يجب مراجعتها عند وجود مشاكل مع أجهزة الشبكة في المخزون هي:

• جهاز الشبكة
• واجهة الإدارة
• عنصر الشبكة
• مورد الشبكة
• ديفيسييف
• عنوان

حلقة المزامنة والفخاخ

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

API لفرض مزامنة الجهاز

إذا استمر جهاز الشبكة في مزامنة الحالة لمدة أطول من اللازم، بل ولأيام، راجع أولا عمليات التحقق الأساسية من إمكانية الوصول والاتصال. ثم فرض إعادة مزامنة الجهاز عبر مكالمة API:

1.- فتح جلسة واجهة سطر الأوامر الخاصة بمركز بنية الشبكة الرقمية (CLI) من Cisco.

2.- الحصول على رمز مصادقة مركز بنية الشبكة الرقمية (DNA) من Cisco عبر API:

curl -s -X POST -u admin  https://kong-frontend.maglev-system.svc.cluster.local/api/system/v1/identitymgmt/token

3.- أستخدم الرمز المميز من الخطوة السابقة لتشغيل واجهة برمجة التطبيقات (API) لفرض مزامنة الجهاز:

curl -X PUT -H "X-AUTH-TOKEN: 
     
       " -H "content-type: application/json" -d ' 
      
        ' https:// 
       
         /api/v1/network-device/sync-with-cleanup?forceSync=true --insecure 
        
       
     

4.- يمكنك رؤية الجهاز في المزامنة مرة أخرى ولكن هذه المرة باستخدام خيار فرض المزامنة عبر واجهة برمجة التطبيقات (API).

مراجعة الأفخاخ

إذا إستمرت المشكلة بعد فرض مهمة المزامنة في الجهاز، يمكننا مراجعة ما إذا كان مركز بنية الشبكة الرقمية من Cisco"خدمة الحدث" يتلقى العديد من الملائمات ومراجعة أي نوع من الملائمات من خلال قراءة سجلات خدمة الأحداث:

1.- قبل أن نقرأ السجلات، يمكننا فقط التحقق من إجمالي الملائمات باستخدام الأمر:

$ echo;echo;eventsId=$(docker ps | awk '/k8s_apic-em-event/ {print $1}'); docker cp $eventsId:/opt/CSCOlumos/logs/ /tmp/;for ip in $(awk -F\: '/ipAddress / {print $4}' /tmp/logs/ncs* | sort | uniq);do for trap in $(grep -A10 $ip /tmp/logs/ncs* | awk -F\= '/trapType/ {print $2}');do tStamp=$(grep -A10 $ip /tmp/logs/ncs* | awk '/trapType/ {print $2,$3}'); echo "$ip - $trap "| grep -E "^([0-9]{1,3}[\.]){3}[0-9]{1,3}" | awk -F\. '{print $1,$2,$3,$4}';done;done | sort | uniq -c | grep -v address| sort -bgr > /home/maglev/trapCounter.log &

2- ثم نرفق بحاوية خدمة الأحداث:

$ magctl service attach -D event-service

3.- بمجرد الدخول إلى حاوية خدمة الأحداث، قم بتغيير الدليل إلى مجلد السجلات:

 $ cd /opt/CSCOlumos/logs/

4.- إذا قمت بمراجعة الملفات الموجودة داخل الدليل، يمكنك مشاهدة بعض ملفات السجلات التي يبدأ اسمها ب "ncs".

مثال:

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# ls -l
total 90852
drwxr-xr-x 1 maglev maglev     4096 May  9 21:33 ./
drwxr-xr-x 1 maglev maglev     4096 Apr 29 17:56 ../
-rw-r--r-- 1 root root 2937478 May 9 21:37 ncs-0-0.log -rw-r--r-- 1 root root 0 Apr 29 23:59 ncs-0-0.log.lck -rw-r--r-- 1 root root 10002771 May 9 21:33 ncs-1-0.log -rw-r--r-- 1 root root 10001432 May 9 21:16 ncs-2-0.log -rw-r--r-- 1 root root 10005631 May 9 21:01 ncs-3-0.log -rw-r--r-- 1 root root 10000445 May 9 20:47 ncs-4-0.log -rw-r--r-- 1 root root 10000507 May 9 20:33 ncs-5-0.log -rw-r--r-- 1 root root 10003091 May 9 20:21 ncs-6-0.log -rw-r--r-- 1 root root 10001058 May 9 20:06 ncs-7-0.log -rw-r--r-- 1 root root 10001064 May 9 19:53 ncs-8-0.log -rw-r--r-- 1 root root 10000572 May 9 19:39 ncs-9-0.log
-rw-r--r-- 1 root   root        424 Apr 30 00:01 nms_launchout.log
-rw-r--r-- 1 root   root        104 Apr 30 00:01 serverStatus.log

5.- ملفات "ncs" تلك هي التي نحتاج لتحليل أي نوع من الأفخاخ نحن نتلقاها وكم منها. يمكننا مراجعة ملفات السجلات التي تتم تصفيتها حسب اسم المضيف للجهاز أو الكلمة الأساسية "trapType":

root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep trapType ncs*.log
root@apic-em-event-service-586df7d4b8-f9c74:/opt/CSCOlumos/logs# grep 
     
       ncs*.log 
     

هناك العديد من أنواع الملائمات، بعضها يمكن أن يؤدي إلى إعادة مزامنة الجهاز وإذا جاءت بشكل متكرر جدا يمكن أن تؤدي إلى حلقة المزامنة.

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

يمكنك حفظ مخرجات الملائمات في ملف ومشاركتهم مع فريق التصعيد إذا لزم الأمر. 

حالة تعطيل الخدمة

إذا كنت تشك في أن Pod المخزون يتعطل بسبب سلوك فردي في صفحة جرد مركز بنية الشبكة الرقمية من Cisco أثناء إدارة أجهزة الشبكة، ثم يمكنك التحقق من حالة Pod أولا:

$ magctl appstack status | grep inventory

$ magctl service status 
     
         
     

عند مراجعة مخرجات حالة POD، إذا رأيت عددا كبيرا من عمليات إعادة التشغيل أو حالة خطأ، يمكنك إرفاق حاوية المخزون وتجميع ملف تفريغ الحرارة الذي يمكن أن يحتوي على البيانات التي يمكن أن تساعد فريق التصعيد على تحليل السبب الجذري لحالة التلف وتعريفه:

$ magctl service attach -D 
     

root@apic-em-inventory-manager-service-76f7f8d7f5-427m5:/# ll /opt/maglev/srv/diagnostics/ | grep heapdump
-rw-r--r-- 1 root root 1804109 Jul 20 21:16 apic-em-inventory-manager-service-76f7f8d7f5-427m5.heapdump

يتعذر حذف جهاز

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

API لفرض حذف الجهاز

إذا لم تكن قادرا على حذف الجهاز من المخزون باستخدام واجهة المستخدم الرسومية (GUI) لمركز بنية الشبكة الرقمية من Cisco، فيمكنك إستخدام واجهة برمجة التطبيقات (API) لحذف الجهاز حسب المعرف:

1.- انتقل إلى قائمة مركز بنية الشبكة الرقمية من Cisco -> النظام الأساسي -> Developer Toolkit -> علامة التبويب API والبحث عن الأجهزة في شريط البحث، من النتائج انقر في الأجهزة من قسم معرفة الشبكة والبحث عن حذف حسب معرف الجهاز API.

2.- انقر في واجهة برمجة تطبيقات DELETE by Device Id، وانقر في Try وقم بتوفير معرف الجهاز من مخزون النموذج المطلوب إزالته.

3.- انتظر حتى يتم تشغيل واجهة برمجة التطبيقات (API) والحصول على إستجابة 200 OK، ثم تأكد من أن جهاز الشبكة لم يعد موجودا في صفحة المخزون.