المحتويات

المقدمة

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

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

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

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

مشاكل

خطأ داخلي

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

نيتكونيف

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

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

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

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

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

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

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

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

المقدمة

يصف هذا المستند المفاهيم الأساسية لخدمة جرد مركز بنية الشبكة الرقمية (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

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

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

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

- تتم إدارته برمز المسطرة الأخضر: يمكن الوصول إلى الجهاز ويتم إدارته بالكامل.

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

- غير مدارة: يتعذر الوصول إلى الجهاز ولم يتم تجميع أي معلومات مخزون بسبب مشاكل في اتصال الجهاز.

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

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

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

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

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

- قيد التقدم: يتم تجميع المخزون.

ملاحظة: لمزيد من المعلومات حول وظائف المخزون في مركز بنية الشبكة الرقمية من Cisco، يرجى مراجعة الدليل الرسمي للإصدار 2.3.5.x: إدارة المخزون الخاص بك

مشاكل

خطأ داخلي

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

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

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

- بيانات اعتماد جهاز غير صحيحة ل SNMP و SSH و NetConf.

- مشاكل اتصال الشبكة المتعلقة ب SNMP و SSH و NetConf.

- تتسبب مشكلات تكوين NetConf في الجهاز في عدم عمل NetConf بشكل صحيح.

- قم بتشغيل إعادة مزامنة الجهاز أثناء تنفيذ مزامنة الجهاز بالفعل.

- تم تلقي العديد من الملائمات من الجهاز مما تسبب في عدة مشغلات إعادة مزامنة في فترة زمنية قصيرة.

- مشاكل النهاية الخلفية مع إدخالات قاعدة بيانات المخزون في جداول متعددة متعلقة بالجهاز.

تلميح: يمكن أن تساعد إزالة جهاز الشبكة وإعادة اكتشافه باستخدام بيانات اعتماد CLI و SNMP و NETconf الصحيحة في إزالة إدخالات قاعدة البيانات القديمة التي قد تتسبب في حدوث خطأ داخلي.

تلميح: يمكن أن تكون مراجعة سجلات خدمة المخزون والتصفية حسب IP للجهاز أو اسم المضيف مساعدة في تحديد السبب الرئيسي للخطأ الداخلي.

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

لمراجعة بيانات اعتماد الجهاز، انتقل إلى قائمة مركز بنية الشبكة الرقمية (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.

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

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

- جهاز الشبكة

- واجهة الإدارة

- عنصر الشبكة

- مورد الشبكة

- ديفيسييف

- عنوان

تحذير: يسمح فقط ل Cisco TAC بتشغيل إظهار الاستعلامات في PostGres Shell ويسمح فقط لفرق BU/DE بإجراء تعديلات على جداول DB.

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

تلميح: يمكنك مراجعة سجلات PostGres باستخدام Kibana في صفحة نظام DNA Center من Cisco رقم 360 والبحث عن مخالفات القيد عندما تحاول خدمة المخزون حفظ الإدخالات في جداول قاعدة بيانات PostGres أو تحديثها.

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

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

ملاحظة: يمكن أن يتسبب هذا النوع من حلقات التكرار المتزامنة بسبب الفخاخ الهائلة في أن يقوم مركز بنية الشبكة الرقمية (DNA) من 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).

تلميح: يمكنك الحصول على معرف الجهاز من عنوان URL الخاص بالمستعرض (deviceId أو id) من صفحة تفاصيل جهاز جرد مركز بنية الشبكة الرقمية (DNA) من Cisco أو صفحة عرض الجهاز 360.

ملاحظة: للحصول على مزيد من المعلومات حول واجهات برمجة التطبيقات (API) في مركز بنية الشبكة الرقمية من Cisco، يرجى مراجعة دليل واجهة برمجة التطبيقات (API) Cisco DevNet

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

إذا إستمرت المشكلة بعد فرض مهمة المزامنة في الجهاز، يمكننا مراجعة ما إذا كان مركز بنية الشبكة الرقمية من 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، ثم تأكد من أن جهاز الشبكة لم يعد موجودا في صفحة المخزون.

تلميح: يمكنك الحصول على معرف الجهاز من عنوان URL الخاص بالمستعرض (deviceId أو id) من صفحة تفاصيل جهاز جرد مركز بنية الشبكة الرقمية (DNA) من Cisco أو صفحة عرض الجهاز 360.

ملاحظة: للحصول على مزيد من المعلومات حول واجهات برمجة التطبيقات (API) في مركز بنية الشبكة الرقمية من Cisco، يرجى مراجعة دليل واجهة برمجة التطبيقات (API) Cisco DevNet