أستكشاف أخطاء SNMP وإصلاحها في بنية واجهة التحكم في الوصول (ACI) من Cisco

المقدمة

يصف هذا المستند كيفية تكوين SNMP في Cisco ACI ل ACI الإصدار 5.x والإصدارات الأحدث والتحقق من صحته واستكشاف أخطائه وإصلاحها. وهو يغطي نموذج سياسة بروتوكول إدارة الشبكات البسيط (SNMP) وعقود الإدارة المطلوبة وتكوين الملائمة والتحقق من صحة التشغيل باستخدام استعلامات واجهة سطر الأوامر (CLI) والكائنات المدارة (MO) وتدفقات عمل أستكشاف الأخطاء وإصلاحها المنظمة لسيناريوهات الفشل الأكثر شيوعا عبر محولات الورق/العمود الفقري ووحدات التحكم في واجهة برمجة التطبيقات (APIC).

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

يتم سحب المواد الواردة في هذا المستند من الملاحظة الفنية الداخلية ل SNMP الخاصة بفريق تقديم حلول Cisco ACI في ACI: نظرة عامة على المشاكل والتكوين واستكشاف الأخطاء وإصلاحها والتحذيرات/المشاكل التي أعدها Tomas de Leon، المكملة بدليل تكوين إدارة نظام APIC من Cisco (الإصدار 5.x) والدليل المرجعي السريع ل Cisco ACI MIB.

نظرة عامة

بنية SNMP في ACI

SNMP (بروتوكول إدارة الشبكة البسيط) هو بروتوكول يستند إلى UDP يحكم إدارة الشبكة ومراقبتها. في واجهة التحكم في الوصول (ACI)، يعمل بروتوكول SNMP بشكل مستقل على كل كيان مدار. كل مفتاح أوراق، محول العمود الفقري، ووحدة تحكم APIC هي وكيلة SNMP خاصة بها — يجب مسح كل منها أو مراقبته بشكل مستقل.

تدعم واجهة التحكم في الوصول (ACI) إمكانات بروتوكول SNMP التالية:

• عمليات القراءة (الحصول، الحصول على التالي، BulkGet، المشي) — مدعومة على المحولات الطرفية/العمود الفقري ووحدات التحكم في APIC.
• الإعلامات (TRAPS) — إختبارات SNMPv1 و v2c و v3 المدعومة على المحولات الطرفية/العمود الفقري ووحدات التحكم في واجهة برمجة التطبيقات (APIC).
• SNMPv3 — مدعوم على المحولات الطرفية/الخلفي ووحدات التحكم في واجهة برمجة التطبيقات (APIC).
• عمليات الكتابة (مجموعة) — غير مدعومة على أي جهاز قائمة تحكم في الوصول (ACI).
• IPv6 — يتم دعم بروتوكول SNMP عبر IPv4 فقط.

ملاحظة: في نظام مجموعة APIC، توفر كل APIC كائنات MIB محلية لنفسها. يجب إستطلاع كل APIC بشكل مستقل؛ لا يوجد تجميع SNMP على مستوى المجموعة. وبالمثل، يجب الاستعلام عن كل محول من محولات الأوراق والعمود الفقري بشكل مستقل.

بنية SNMPd على APIC

تقوم واجهة برمجة التطبيقات (APIC) بتشغيل عملية SNMPd، والتي تحتوي على مكونين داخليين:

• وكيل — وكيل شبكة-SNMP مفتوح المصدر (الإصدار 5.7.6 أو إصدار أحدث) يعالج معالجة بروتوكول SNMP وإدارة الجلسات.
• DME (محرك نموذج البيانات) — واجهات باستخدام شجرة معلومات إدارة APIC (MIT) لقراءة الكائنات المدارة (MOs) وترجمة سمات MO إلى تنسيق كائن SNMP. يتم إنشاء إختبارات SNMP من الأحداث والأخطاء التي يتم رفعها على أنظمة التشغيل MOs.

نموذج سياسة SNMP وسلسلة النشر

يستخدم ACI نموذجا قائما على السياسة لبروتوكول SNMP. يتم تجريد تكوين SNMP ككائن مدار ل SNMPpol ويجب أن يكون مرتبطا بمجموعة نهج POD الخاصة بالنسيج قبل نشره إلى أي عقدة. سلسلة النشر الكاملة هي:

1. سياسة SNMP (SNMPpol) — يحدد حالة المسؤول، سلاسل المجتمع، سياسات مجموعة العملاء (ACLs)، ومستخدمي SNMPv3.
2. مجموعة سياسات POD — تشير إلى سياسة SNMP إلى جانب سياسات أخرى على مستوى POD (BGP، ISIS، NTP، وما إلى ذلك).
3. محدد ملف تعريف POD — يطبق مجموعة نهج POD على مجموعات PODS الخاصة بالقنوات الليفية.

وبالإضافة إلى ذلك، يتطلب تكوين ملائمة SNMP:

1. مجموعة وجهة مراقبة SNMP (SNMPgroup) — تحدد مضيفي وجهة الفخ، المنفذ، إصدار SNMP، والمجتمع.
2. مصادر المراقبة (SNMPsrc) — ربط المجموعة الوجهة بثلاث نطاقات سياسة مراقبة مميزة: الوضع الافتراضي للنسيج ونهج البنية المشتركة ونهج الوصول.

يلزم وجود عقود إدارة تسمح بمنفذ UDP 161 (طلبات SNMP) ومنفذ UDP 162 (إختبارات SNMP) لعقد APIC. تتطلب العقد الطرفية والعقدة الأساسية أيضا قواعد IPTABLES صحيحة، والتي تتم برمجتها تلقائيا عند تكوين نهج مجموعة العملاء.

قواعد معلومات الإدارة (MIB) المدعومة

تتضمن قواعد معلومات الإدارة (MIB) المدعومة في APIC ما يلي:

• MIB للكيان — PhysicalTable
• Cisco Entity Ext MIB — PhysicalProcessorTable، LEDable
• Cisco Entity FRU Control MIB — PowerSupplyGroupTable، PowerStatusTable، FanTrayStatusTable، PhysicalTable
• قاعدة معلومات الإدارة (MIB) لمستشعر الكيان من Cisco — SensorValueTable و SensorThresholdTable
• Cisco Process MIB — CPUTotalTable، ProcessTable، ProcessExtRevTable، ThreadTable

تكشف المحولات الطرفية والخلفية قواعد معلومات الإدارة (MIB) القياسية لنظام التشغيل NX، بما في ذلك IF-MIB و IP-MIB و Cisco-CDP-MIB و Cisco-ENTITY-QFP-MIB ومجموعة MIB الكاملة من Cisco-ENTITY-FRU-Control-MIB.

تتضمن إختبارات SNMP التي تم إنشاؤها على APIC ما يلي: CefcFRUIserted، cefcFRURemoved، cefcFanTrayStatusChange، cefcModuleStatusChange، entSensorThresholdNotification، cefcPowerStatusChange، cpmCPURisingThreshold، cpmCPUFallingThresholdThreshold.

تكوين SNMP في ACI

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

الخطوة 1: تكوين سياسة SNMP

انتقل إلى البنية > سياسات البنية > السياسات > Pod > SNMP. حدد (أو قم بإنشاء) سياسة SNMP، والتي تسمى عادة الافتراضي. التكوين:

• حالة المسؤول — تم تعيينها إلى ممكن.
• سياسات المجتمع — أضف سلسلة المجتمع التي تستخدمها إدارة الشبكة (NMS) لديك.
• سياسات مجموعة العملاء — قم بتحديد ملف تعريف واحد أو أكثر لمجموعة العملاء، يحدد كل منها عناوين IP لعميل SNMP المسموح بها وبيانات EPG الإدارية المرتبطة (خارج النطاق أو داخل النطاق).
• مستخدمو SNMPv3 — إذا كنت تستخدم SNMPv3، فقم بإضافة مستخدمين هنا مع معلمات المصادقة والخصوصية.

الخطوة 2: إقران سياسة SNMP بمجموعة نهج Pod

انتقل إلى البنية > سياسات البنية > Pods > مجموعات السياسات. حدد مجموعة نهج Pod النشطة (التي تسمى عادة الافتراضي). قم بتعيين حقل نهج SNMP للإشارة إلى سياسة SNMP التي تم إنشاؤها في الخطوة 1. تحقق من أن حقل نهج SNMP الذي تم حله يظهر اسم النهج الصحيح.

ثم انتقل إلى البنية > سياسات البنية > PODS > ملفات التخصيص، وقم بتوسيع ملف تخصيص POD الافتراضي، وتأكيد المراجع النشطة لمجموعة سياسات POD الصحيحة.

الخطوة 3: تكوين عقود الإدارة لمنفذ UDP 161

انتقل إلى المستأجرين > الإدارة > العقود > العقود خارج النطاق. تحقق من أن موضوع عقد OOB النشط يشير إلى إدخال عامل تصفية يسمح بمنفذ UDP 161 (طلبات SNMP). بدون هذا العقد على APIC، سيتم إسقاط جميع حزم الوصول/السير لبروتوكول SNMP بشكل صامت.

يجب أن تتضمن إدخالات التصفية المرفقة بموضوع العقد إدخالا باستخدام EtherType IP، وUDP، ومنفذ الوجهة 161. يوضح المثال أعلاه عامل تصفية Allow-All (بروتوكول غير محدد) — وهذا يسمح ب SNMP ولكنه أوسع من الموصى به للإنتاج. ويفضل إدخال مرشح SNMP مخصص بإدخالات UDP/161 و UDP/162 معينة.

ملاحظة: في إصدارات البرامج الثابتة المرتكزة على التطبيقات (ACI) السابقة، كانت بعض المنافذ مفتوحة دائما على العقد الطرفية والعمود الفقري ولم يكن عقد الإدارة مطلوبا لبروتوكول SNMP. في ACI 5.x، يكون العقد مطلوبا لعقد APIC. تستخدم العقد الطرفية والعمود الرئيسي قواعد جداول البيانات المستمدة من "سياسات مجموعة العملاء" بدلا من عقود الإدارة.

الخطوة 4: تكوين وجهات SNMP الملائمة

انتقل إلى Admin > أدوات تجميع البيانات الخارجية > مراقبة الوجهات > SNMP. انقر بزر الماوس الأيمن وحدد إنشاء مجموعة وجهة مراقبة SNMP. تعرض علامة تبويب SNMP جميع مجموعات الوجهة التي تم تكوينها. الجدول الفارغ يعني أنه لم يتم تكوين وجهات الملائمة بعد.

تعريف:

• اسم المجموعة
• وجهات الملائمة: hostname/ip، منفذ UDP (الافتراضي 162)، إصدار SNMP، سلسلة المجتمع، و EPG الإدارة

الخطوة 5: تكوين مصادر المراقبة

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

• البنية > سياسات البنية الأساسية > السياسات > المراقبة > الافتراضية > CallHome/Smart CallHome/SNMP/Syslog/TACACS (يغطي أحداث البنية الأساسية للبنية الأساسية الليفية)
• البنية > سياسات البنية > السياسات > المراقبة > السياسة العامة > الاتصال بالمنزل/Smart CallHome/SNMP/Syslog/TACACS (يغطي الأحداث المشتركة على مستوى البنية)
• البنية > سياسات الوصول > السياسات > المراقبة > الافتراضية > CallHome/Smart CallHome/SNMP/Syslog (يغطي أحداث الوصول/البنية الأساسية)

في كل موقع، حدد SNMP كنوع مصدر وقم بإنشاء مصدر SNMP جديد يشير إلى المجموعة الوجهة التي تم إنشاؤها في الخطوة 4.

التحقق من التكوين

التحقق من نشر سياسة SNMP

انتقل إلى البنية > سياسات البنية > السياسات > Pod > SNMP وأكد وجود سياسة SNMP الافتراضية وتم تعيين حالة الإدارة الخاصة بها على التمكين. تعرض قائمة مجموعات النهج جميع سياسات SNMP التي تم تكوينها مع ظهور حالة المسؤول الخاصة بها في لمحة.

للتحقق التفصيلي، انقر فوق اسم النهج لفتحه. تأكد من تعيين تبديل حالة المسؤول إلى ممكن، وأن نهج مجموعة العملاء تسرد جميع مضيفي NMS المسموح بهم مع EPG الخاص بالإدارة المقترنة بهم.

قم بتشغيل استعلام MO التالي على أي APIC لتأكيد وجود نهج SNMP وتمكينه في البنية:

apic1# moquery -c snmpPol
Total Objects shown: 1

# snmp.Pol
name         : default
adminSt      : enabled                    <--- must be "enabled"
contact      : NOC Team
descr        : ACI Fabric SNMP Policy
dn           : uni/fabric/snmppol-default
loc          : DC1 ACI Fabric
monPolDn     : uni/fabric/monfab-default

إذا كان adminSt معطلا، فلن يعمل بروتوكول SNMP على أي عقدة. قم بتمكينها في واجهة المستخدم الرسومية APIC تحت البنية > سياسات البنية > السياسات > Pod > SNMP > الافتراضي.

التحقق من تكوين سلسلة المجتمع

apic1# moquery -c snmpCommunityP
Total Objects shown: 1

# snmp.CommunityP
name         : public                     <--- confirm this matches your NMS community string
dn           : uni/fabric/snmppol-default/community-public
descr        : SNMP Community String

إذا لم يتم إرجاع أي مجتمع، أو لم يتطابق الاسم مع ما تستخدمه NMS، فقم بإضافة سلسلة المجتمع ضمن نهج SNMP أو تصحيحها.

التحقق من سياسات مجموعة العملاء (التحكم في الوصول إلى SNMP)

تعمل سياسات مجموعة العملاء كقائمة تحكم في الوصول إلى SNMP للوصول إلى/السير. يحدد كل نهج عناوين IP للعميل المسموح به لاستطلاع عقد الأوراق/العمود الفقري التي يتم من خلالها إدارة VRF. في العقد الطرفية/الأساسية، تتم ترجمة هذه السياسات إلى قواعد IPTABLES.

apic1# moquery -c snmpClientGrpP -x query-target=children
Total Objects shown: 3

# snmp.ClientP
addr         : 10.1.1.50                  <--- NMS server IP
dn           : uni/fabric/snmppol-default/clgrp-NMS-Clients/client-[10.1.1.50]
name         : nms-server1

# snmp.ClientP
addr         : 10.1.1.51
dn           : uni/fabric/snmppol-default/clgrp-NMS-Clients/client-[10.1.1.51]
name         : nms-server2

# snmp.ClientGrpP
name         : NMS-Clients
dn           : uni/fabric/snmppol-default/clgrp-NMS-Clients

تأكد من وجود IP لخادم NMS في إدخالات العميل. إذا كان عنوان IP العميل مفقود، سيتم إسقاط طلبات SNMP GET/WALK من ذلك المضيف بواسطة قوائم التحكم على العقد الطرفية/العمود الفقري.

ملاحظة: تحذير SNMPv3 — لا يتم فرض سياسات مجموعة العملاء على APIC عند إستخدام SNMPv3. يتم السماح بأي SNMPv3 GET/WALK إلى APIC بغض النظر عن تكوين مجموعة العملاء. يعد فرض مجموعة العملاء ل SNMPv3 على APIC قيدا معروفا. في المحولات الطرفية والمحولات الأساسية، يتصرف فرض مجموعة العملاء بنفس الطريقة لكل من SNMPv2c و SNMPv3.

التحقق من مرجع نهج SNMP لمراجع مجموعة نهج POD

انتقل إلى البنية > سياسات البنية > PODS > مجموعات السياسات وافتح مجموعة نهج POD النشطة. تأكد من تعيين حقل قائمة منسدلة سياسة SNMP إلى نهج SNMP المطلوب ويظهر حقل نهج SNMP الذي تم حله نفس الاسم. يعني النهج المفقود أو غير المحلول أنه لا يتم دفع تكوين SNMP أبدا إلى المحولات.

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

التحقق من خلال REST API:

apic1# moquery -c fabricPodPGrp -x rsp-subtree=full
# fabric.PodPGrp
name          : default
dn            : uni/fabric/funcprof/podpgrp-default

  # fabric.RsSnmpPol
  tnSnmpPolName : default                  <--- must reference the SNMP policy
  state         : formed                   <--- must be "formed"

إذا لم يتم تكوين الحالة، يتم قطع علاقة سياسة SNMP. إعادة تحديد نهج SNMP في مجموعة نهج Pod وإرسالها.

التحقق من عقد الإدارة ل UDP 161 (عقد APIC)

انتقل إلى المستأجرين > الإدارة > العقود > العقود خارج النطاق (والعقود داخل النطاق إذا كنت تستخدم إدارة INB). افتح عقد OOB النشط وانقر فوق علامة التبويب نهج. تحقق من أن الموضوع يشير إلى عامل تصفية يسمح بمنفذ UDP 161.

قم بتوسيع عامل التصفية الذي تمت الإشارة إليه بواسطة الموضوع وتأكيد الإدخالات الخاصة به تتضمن إدخالا باستخدام EtherType IP، وUDP، ومنفذ الوجهة 161. تحدد إدخالات التصفية حركة المرور المسموح بها من خلال عقد إدارة OOB إلى APIC.

يجب أن يظهر عامل التصفية:

• EtherType: IP
• بروتوكول IP: UDP
• غاية ميناء من: 161
• غاية ميناء إلى: 161

تحقق أيضا من أن منفذ UDP 162 مسموح به إذا كنت تريد أن تقوم APIC بإرسال رسائل SNMP صادرة عبر واجهة OOB.

تحقق من خلال استعلام MO:

apic1# moquery -c vzEntry -x query-target-filter='and(eq(vzEntry.dFromPort,"161"),eq(vzEntry.prot,"17"))'
Total Objects shown: 2

# vz.Entry
name         : snmp-get
dn           : uni/tn-mgmt/flt-snmp-filter/e-snmp-get
dFromPort    : 161                        <--- destination port 161
dToPort      : 161
prot         : 17                         <--- UDP
stateful     : no

إذا لم يتم إرجاع أية نتائج، فلن يكون هناك عامل تصفية ل UDP 161. أضف واحدا إلى عقد الإدارة.

التحقق من تكوين وجهة مصيدة SNMP

انتقل إلى Admin > أدوات تجميع البيانات الخارجية > مراقبة الوجهات > SNMP للاطلاع على جميع مجموعات وجهة SNMP التي تم تكوينها. القائمة الفارغة تعني عدم تكوين وجهات الملائمة ولن يتم إرسال أي ملائمات من أي عقدة.

apic1# moquery -c snmpTrapDest
Total Objects shown: 1

# snmp.TrapDest
host         : 10.1.1.50                  <--- NMS trap receiver IP
port         : 162                         <--- trap UDP port
ver          : v2c                         <--- SNMP version
secName      : public                      <--- community string (v2c) or username (v3)
v3SecLvl     : noauth
notifT       : traps
vrfName      : mgmt:inb                    <--- VRF used to reach the trap receiver
epgDn        : uni/tn-mgmt/mgmtp-default/inb-default
dn           : uni/fabric/snmpgroup-NMS-DestGrp/trapdest-10.1.1.50-port-162

تأكد من أن عنوان IP لوجهة الملائمة والمنفذ والإصدار وسلسلة المجتمع وملف VRF للإدارة (إما mgmt:inb أو الإدارة ل OOB) تطابق بيئتك. يجب أن يتطابق VRF مع إدارة EPG التي تم تعيينها للوجهة.

التحقق من تكوين مصادر المراقبة في النطاقات الثلاثة جميعها

يجب أن تكون مصادر SNMP موجودة في نطاقات نهج المراقبة الثلاثة جميعها. يؤدي عدم وجود مصدر في أي نطاق إلى عدم إعادة توجيه الملائمات من الأحداث ذات الصلة.

apic1# moquery -c snmpSrc | egrep "snmp.Src|name|dn|incl|minSev|monPolDn"
# snmp.Src
name         : NMS-snmpSrc
dn           : uni/fabric/monfab-default/snmpsrc-NMS-snmpSrc        <--- Fabric Default
incl         : audits,events,faults
minSev       : info
monPolDn     : uni/fabric/monfab-default

# snmp.Src
name         : NMS-snmpSrc
dn           : uni/fabric/moncommon/snmpsrc-NMS-snmpSrc              <--- Fabric Common
incl         : audits,events,faults
minSev       : info
monPolDn     : uni/fabric/moncommon

# snmp.Src
name         : NMS-snmpSrc
dn           : uni/infra/moninfra-default/snmpsrc-NMS-snmpSrc        <--- Access Default
incl         : audits,events,faults
minSev       : info
monPolDn     : uni/infra/moninfra-default

إذا كان أي من العناصر الثلاثة مفقود، فقم بإنشاء مصدر SNMP المفقود في سياسة المراقبة المقابلة باستخدام واجهة المستخدم الرسومية (GUI).

التحقق العملي

التحقق من حالة SNMP باستخدام show snmp summary (APIC)

قم بتشغيل هذا الأمر مباشرة على كل APIC لتأكيد تشغيل عميل SNMP وتم تطبيق التكوين:

apic1# show snmp summary
Active Policy:
default, Admin State: enabled             <--- admin state must be "enabled"

Local SNMP engineID: [Hex] 0x8000000980e2b692088976c75600000000

----------------------------------------
Community           Description
----------------------------------------
public              SNMP Community String  <--- community must be present

------------------------------------------------------------
User                Authentication   Privacy
------------------------------------------------------------
                                            <--- empty if using v2c only

------------------------------------------------------------
Client-Group        Mgmt-Epg              Clients
------------------------------------------------------------
NMS-Clients         default (In-Band)     10.1.1.50,10.1.1.51  <--- verify client IPs

------------------------------------------------------------
Host                Port    Version   Level       SecName
------------------------------------------------------------
10.1.1.50           162     v2c       noauth      public        <--- trap destination

ما الذي يجب التحقق منه في الإخراج:

• يجب تمكين حالة المسؤول.
• يجب أن يتطابق المجتمع مع ما تم تكوين NMS لاستخدامه.
• يجب أن يسرد العميل-المجموعة جميع بروتوكولات NMS IP المسموح بها مع EPG الإدارة الصحيحة.
• المضيف (وجهة الملائمة) يجب أن يسرد مستقبل مصيدة NMS بالمنفذ والإصدار الصحيحين.

التحقق من حالة SNMP باستخدام ملخص show snmp (ورقة/عمود فقري)

leaf101# show snmp summary
Admin State : enabled, running (pid:8192)  <--- must show "enabled, running" with a PID

Local SNMP engineID: [Hex] 80000009037C69F6105BF9

----------------------------------------------------------------------
Community       Context         Status
----------------------------------------------------------------------
public                          ok                                     <--- community status must be "ok"

----------------------------------------------------------------------
Client          VRF             Status
----------------------------------------------------------------------
10.1.1.50       mgmt:inb        ok                                     <--- client entry must be "ok"
10.1.1.51       mgmt:inb        ok

-------------------------------------------------------------------------------
Host            Port    Ver     Level   SecName         VRF
-------------------------------------------------------------------------------
10.1.1.50       162     v2c     noauth  public          mgmt:inb       <--- trap destination

ما الذي يجب التحقق منه في الإخراج:

• يجب تمكين حالة المسؤول، التي تعمل باستخدام معرف شخصي. في حالة إظهار معطل، لا يتم تطبيق نهج SNMP أو أن سلسلة نهج pod مقطوعة.
• يجب أن تكون حالة المجتمع موافق. تشير حالة الخطأ إلى مشكلة في نشر النهج.
• يجب أن يتطابق VRF الخاص بالعميل لكل مضيف NMS مع VRF الخاص بالإدارة الخاص ب EPG (mgmt:inb ل In-Band، Management ل OOB).
• يجب أن يسرد مضيف الملائمة الوجهة ذات سياق VRF الصحيح.

التحقق من تشغيل عملية SNMPd

على ورقة أو عمود فقري:

leaf101# ps aux | grep snmp
root      5881  2.5 1907404  411444 ?    Ssl  Apr05   /isan/bin/snmpd -f -s -d udp:161 udp6:161 tcp:161

leaf101# pidof snmpd
5881

في APIC:

apic1# ps aux | grep snmp
ifc   32182  1.4   0.1  641196  239716  ?   Ssl  Apr10   /mgmt//bin/snmpd.bin \
  -f -p /tmp/snmpd2.pid -a -A -LE 0-2 -c /data//snmp/snmpd.conf

إذا لم يتم العثور على أي عملية SNMPd على ورقة أو عمود فقري، فإن SNMP لا يعمل على تلك العقدة. تحقق من تمكين حالة "مسؤول نهج SNMP" ومن تكوين سلسلة نهج pod بشكل صحيح.

leaf101# netstat -lutn | grep 161
Active Internet connections (only servers)
Proto  Recv-Q  Send-Q  Local Address    Foreign Address  State
tcp         0       0  0.0.0.0:161      0.0.0.0:*        LISTEN   <--- SNMP agent is accepting requests
udp         0       0  0.0.0.0:161      0.0.0.0:*
udp6        0       0  :::161           :::*

leaf101# iptables -S | grep -i snmp
-N snmp_rules
-N vrf_2_snmp_rules
-N vrf_9_snmp_rules
-A INPUT -p udp -m udp --dport 161 -j snmp_rules    <--- SNMP port 161 redirects to snmp_rules chain
-A snmp_rules -m vrf --vrf 2 -j vrf_2_snmp_rules    <--- VRF 2 = OOB management
-A snmp_rules -m vrf --vrf 9 -j vrf_9_snmp_rules    <--- VRF 9 = In-Band management
-A snmp_rules -j DROP                                <--- default drop; only permitted clients pass
-A vrf_2_snmp_rules -s 10.1.1.50/32 -j ACCEPT       <--- permitted NMS client (OOB VRF)
-A vrf_9_snmp_rules -s 10.1.1.50/32 -j ACCEPT       <--- permitted NMS client (INB VRF)

leaf101# show vrf
VRF-Name                VRF-ID  State   Reason
management              2       Up      --
mgmt:inb                9       Up      --

leaf101# iptables -nvL | grep -A 20 "Chain snmp_rules"
Chain snmp_rules (1 references)
 pkts bytes target         prot opt in     out    source       destination
    1    73 vrf_9_snmp_rules all -- *      *      0.0.0.0/0    0.0.0.0/0    vrf 9
    0     0 DROP            all -- *      *      0.0.0.0/0    0.0.0.0/0    <--- if pkts>0 here, client IPs are missing

التحقق من اتصال الشبكة بمنافذ SNMP

leaf101# netstat -ai | grep eth0
Iface  MTU  Met  RX-OK  RX-ERR  RX-DRP  RX-OVR  TX-OK  TX-ERR  TX-DRP  TX-OVR  Flg
eth0   1500   0  501277      0       0       0  633546      0       0       0  BMRU

leaf101# netstat -ai | grep kpm_inb
Iface     MTU  Met    RX-OK  RX-ERR  RX-DRP  RX-OVR    TX-OK  TX-ERR  TX-DRP  TX-OVR  Flg
kpm_inb  9300   0  10361421     0       0       0   8958506      0     126       0  BMRU

تأكد من أن واجهات الإدارة نشطة (لا توجد زيادات في RX-ERR) وحركة مرور البيانات العابرة. يمثل ETH0 واجهة إدارة OOB؛ KPM_inb هو واجهة الإدارة داخل النطاق على المحول.

التحقق من إرسال ملائمة SNMP باستخدام تفريغ TCPDUMP

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

leaf101# tcpdump -i kpm_inb -f port 162 -vv
tcpdump: listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes
17:21:49.810052 IP (tos 0x0, ttl 64, id 63116, proto UDP, length 218)
    172.18.242.14.35582 > 10.1.1.50.snmp-trap: { SNMPv2c C=public
    { V2Trap(171) R=253 system.sysUpTime.0=5888267
      S:1.1.4.1.0=E:cisco.9.276.0.1
      interfaces.ifTable.ifEntry.ifIndex.436224000=436224000
      interfaces.ifTable.ifEntry.ifOperStatus.436224000=2 }}        <--- verify trap is being sent to NMS

لخارج النطاق الترددي:

leaf101# tcpdump -i eth0 -f port 162 -vv

apic1# tcpdump -i bond0.1100 -f port 162
20:01:08.453473 IP apic1-inb.cisco.com.59417 > 10.1.1.50.snmptrap: C=public V2Trap(85) S:
1.1.4.1.0=E:cisco.9.117.2.0.2 E:cisco.9.117.1.1.2.1.1.10548=1 E:cisco.9.117.1.1.2.1.2.10548=2

التحقق من طلبات SNMP Get/Walk مع tcpdump

leaf101# tcpdump -i kpm_inb -f port 161 -vv
17:26:08.548149 IP 10.1.1.50.64245 > leaf101.cisco.com.snmp: { SNMPv2c C=public
  { GetRequest(28) R=949769396 system.sysDescr.0 }}              <--- GET request received
17:26:08.552290 IP leaf101.cisco.com.snmp > 10.1.1.50.64245: { SNMPv2c C=public
  { GetResponse(191) R=949769396
    system.sysDescr.0="Cisco NX-OS(tm) aci, Software (aci-n9000-system), \
Version 15.0(1k), RELEASE SOFTWARE" }}                           <--- response returned; SNMP working

إذا كنت ترى GetRequest ولكن لا GetResponse، يتم تلقي الطلب ولكن لا يتم الرد عليه. تحقق من عملية SNMPd وسلسلة المجتمع. إذا لم يظهر لديك طلب أو إستجابة، يتم حظر الطلب قبل الوصول إلى العقدة (فحص التوجيه وجداول المستندات).

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

شجرة قرارات الفرز

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

العرض: لا توجد إستجابة لطلبات SNMP للإحضار/المشي

1. تحقق من حالة مسؤول SNMP على APIC. قم بتشغيل moquery -c snmpPol. إذا كان adminSt معطلا، فقم بتمكينه ومتابعه إلى الخطوة 7.
2. فحص عملية SNMPd. على العقدة المتأثرة، قم بتشغيل PS AUX | GREP SNMP أو pidof SNMPD. إذا لم تكن هناك عملية قيد التشغيل، فلن يتم نشر سياسة SNMP. تحقق من سلسلة نهج pod (ملف تعريف Pod الخاص بمجموعة نهج → SNMP ل POD →).
3. تحقق من أن المنفذ 161 يعمل على الاستماع. تشغيل netstat -lutn | GREP 161. إذا لم يكن المنفذ 161 في حالة LISTEN، فقد فشلت عملية SNMPd؛ قم بجمع السجلات من /var/log/dme/log/svc_ifc_dbgrelem.log* ثم أعد تشغيل العملية.
4. تحقق من التوجيه. قم بتشغيل show ip route vrf management وshow ip route vrf mgmt:inb. قم بالتأكيد على توجيه إلى مضيف NMS موجود في VRF الصحيح.
5. التحقق من عقد الإدارة على APIC. إذا كان الهدف APIC (ليس ورقة/عمود فقري)، فتحقق من أن UDP 161 مسموح به في عقد الإدارة OOB أو INB. 
6. تنفيذ tcpdump على العقدة. قم بتشغيل tcpdump -i kpm_inb -f port 161 -vv (أو th0 ل OOB). إذا ظهر GetRequest ولكن لم يتم اتباع GetResponse، يصل الطلب إلى العقدة ولكن SNMPD لا يستجيب — تحقق من سلسلة المجتمع. إذا لم يظهر أي طلب على الإطلاق، فإن المشكلة هي upStream (توجيه أو عقد).
7. إختبار من عميل مسموح به. قم بتشغيل snmpget -v2c -c [community] [node-ip] SNMPv2-MIB::sysDescr.0 من مضيف NMS المدرج في مجموعة العملاء. تؤكد الاستجابة الناجحة أن بروتوكول SNMP يعمل بشكل كامل.

العرض: لم يتم تلقي أي ملائمات SNMP في NMS

1. تحقق من تكوين وجهة الملائمة. تشغيل moquery -c snmpTrapDest. قم بتأكيد تطابق NMS IP والمنفذ والإصدار والمجتمع مع القيم المتوقعة ل NMS.
2. تحقق من وجود مصادر المراقبة في النطاقات الثلاثة جميعها. تشغيل moquery -c snmpSrc | egrep "snmp.src|name|dn". قم بتأكيد الإدخالات باستخدام قيم monPolDn ل uni/fabric/monfab-default، وuni/fabric/moncommon، وuni/infra/moninfra-default. إذا كان أي منها مفقودا، فقم بإضافة مصدر SNMP في سياسة المراقبة المطابقة.
3. فحص عملية SNMPd. تحقق من تشغيل SNMPd على العقدة التي يجب أن ترسل الملائمة.
4. قم بإنشاء حدث إختبار والتقاط باستخدام tcpdump. رفرفة واجهة أو تغيير حالة لإنشاء حدث. على العقدة، قم بتشغيل tcpdump -i kpm_inb -f منفذ 162 -vv. إذا لم تظهر أي حركة مرور ملائمة على السلك، فإن الحدث لا يقوم بإنشاء الملائمة — أعد التحقق من سمة مصدر المراقبة (يجب أن تتضمن أخطاء أو أحداث).
5. تحقق من الاتصال بمستقبل الملائمة. تأكيد إمكانية الوصول إلى مستقبل الملائمة من VRF الخاص بالإدارة: show ip route vrf mgmt:inb يجب أن يعرض مسارا لمضيف NMS.
6. إذا ظهرت الملائمات على tcpdump ولكن ليس في NMS، المشكلة يكون على جانب الشبكة: جدار الحماية أو التوجيه أو تكوين NMS. تحقق من أن NMS تستمع إلى UDP 162 من مصدر إدارة IP لعقدة ACI.

السيناريوهات الشائعة

السيناريو 1: تم تمكين نهج SNMP ولكن لم يتم إرجاع أية بيانات من الورقة/العمود الفقري

المشكلة: يظهر نهج SNMP على APIC حالة المسؤول الممكنة. يمكن أن تصل NMS إلى عنوان IP الخاص بإدارة الورقة. احصل على أوقات قصيرة بدون إستجابة.

فحص التكوين: تحقق من أن "مجموعة نهج Pod" تشير إلى نهج SNMP ويظهر نهج SNMP الذي تم حله الاسم الصحيح. إذا كان حقل نهج SNMP الخاص بمجموعة نهج Pod فارغا أو لم يتم تكوين العلاقة، فقد لا تبدأ عملية SNMP على المحولات.

فحص عملياتي: SSH إلى الورقة المتأثرة وقم بتشغيل ملخص show snmp. إذا عرض الإخراج حالة المسؤول: معطل حتى على الرغم من تمكين APIC، لم يتم نشر النهج. تحقق من سلسلة نهج Pod لمجموعة نهج Pod مفقودة أو مشار إليها بشكل غير صحيح.

السبب الجذري: لا يتم ربط نهج SNMP بمجموعة نهج Pod، أو أن محدد ملف تعريف Pod لا يطبق مجموعة نهج Pod الصحيحة على هذا Pod.

الحل:

1. انتقل إلى البنية > سياسات البنية > PODS > مجموعات السياسات > الافتراضية.
2. تأكيد حقل سياسة SNMP يشير إلى نهج SNMP الذي تم تمكينه.
3. انتقل إلى البنية > سياسات البنية > PODS > ملفات التعريف وتأكد من مراجع المحدد النشط لمجموعة نهج POD هذه.
4. بعد الحفظ، أعد التحقق من عرض ملخص SNMP على الورقة في غضون دقيقتين.

السيناريو الثاني: تعمل ميزة الحصول على/السير عبر بروتوكول SNMP لبعض الأجهزة المضيفة من NMS ولا تعمل مع الآخرين

المشكلة: يمكن لخادم NMS واحد إستطلاع عقد ACI بنجاح. لا يحصل خادم NMS ثان على شبكة فرعية مختلفة على أية إستجابة.

فحص التكوين: تشغيل moquery -c snmpClientGrpP -x query-target=children على APIC. تأكيد إدراج IP الخاص بخادم NMS الثاني كإدخال عميل. إذا كان مفقودا، فسيتم حظر IP هذا بواسطة قاعدة DROP الخاصة بالجداول في أسفل سلسلة snmp_rules.

التحقق من التشغيل: في الورقة المتأثرة، تأكد من أن بروتوكول UDP 161 مسموح به في عقد الإدارة خارج النطاق (OOB) أو INB. إذا لم يكن لأي عقد أو عامل تصفية منافذ SNMP، يتم إسقاط الطلب.

السبب الجذري: NMS Server IP الثاني غير موجود في نهج مجموعة العملاء.

الحل: أضف عنوان IP الخاص ب NMS المفقود كإدخال عميل في نهج مجموعة عملاء SNMP ضمن البنية > سياسات البنية > السياسات > Pod > SNMP > الافتراضي > سياسات مجموعة العملاء. سيتم تحديث قواعد IPTABLES على كافة العقد في غضون دقائق من حفظ النهج.

السيناريو 3: لم يتم تلقي إختبارات SNMP — يتم إنشاء إختبارات SNMP ولكن لا يتم تسليمها

المشكلة: الأخطاء مرئية في جدول أخطاء APIC. moquery -c snmpTrapDest يعرض NMS IP الصحيح. لا تتلقى NMS أية فخاخ.

فحص التكوين: تشغيل moquery -c snmpSrc | egrep "snmp.src|name|dn". تحقق من وجود مصادر المراقبة في النطاقات الثلاثة جميعها (الوضع الافتراضي ل Monfab، وضع أحادي، وضع افتراضي أحادي). هناك مراقبة مشتركة تقوم بتكوين المصدر فقط في نهج "إعدادات البنية الافتراضية"، الذي يغفل أحداث نهج الوصول.

فحص عملياتي: قم بتشغيل حدث إختبار (على سبيل المثال، تبديل واجهة في حالة انتقال المسؤول إلى الأسفل). على العقدة ذات الصلة، قم بتشغيل tcpdump -i kpm_inb -f port 162. إذا ظهرت حزم الملائمة في واجهة العقدة، فإن جانب قائمة التحكم في الوصول (ACI) يعمل والمشكلة في مسار الشبكة إلى NMS (جدار الحماية، التوجيه). إذا لم يظهر أي ملائمة على السلك، فإن مصدر مراقبة ACI مفقود أو أن نوع الحدث غير متضمن في سمة تضمين المصدر.

السبب الجذري 1: مصدر مراقبة واحد أو أكثر مفقود من النطاقات المطلوبة.

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

الحل:

1. قم بإضافة مصادر المراقبة المفقودة في واجهة المستخدم الرسومية لكل من النطاقات الثلاثة (الإعداد الافتراضي للقنوات الليفية وميزة "مشتركة للقنوات الليفية" وتقصير الوصول). قم بتعيين مجموعة الوجهة إلى مجموعة وجهة SNMP التي تم تكوينها.
2. تحقق من أن سمة تضمين تتضمن التدقيقات والأحداث والصدوع لتغطية الملائمة الشاملة.
3. بعد إجراء التغييرات، قم بإعادة تشغيل حدث الاختبار وإعادة التحقق من Tcpdump.

apic1# iptables -S | grep 161
-A fp-137 -s 10.0.0.0/8 -p udp -m udp --dport 161 -j ACCEPT     <--- permit SNMP from the management subnet
-A fp-137 -s 172.18.0.0/16 -p udp -m udp --dport 161 -j ACCEPT  <--- permit SNMP from INB management subnet

leaf101# pidof snmpd
5881

leaf101# show system internal sysmgr service name snmpd
Service "snmpd" ("snmpd", 127):
UUID = 0x1A, PID = 5881, SAP = 1545
State: SRV_STATE_HANDSHAKED (entered at time Mon Aug 25 19:23:50 2025).
Restart count: 3
Time of last restart: Mon Aug 25 19:23:48 2025.
Previous PID: 32080
Reason of last termination: SYSMGR_DEATH_REASON_FAILURE_SIGNAL
Tag = N/A
Plugin ID: 0
leaf101# kill -9 5881

leaf101# iptables -S | grep -i snmp

leaf101# zgrep "snmp" /var/log/dme/log/svc_ifc_dbgrelem.log*
leaf101# zgrep "snmpd" /var/log/dme/log/svc_ifc_dbgrelem.log*
leaf101# zgrep "snmpd_log" /var/log/dme/log/*