IBM Tivoli Netcool/OMNIbus النسخة 8.1

أنواع عناصر MIB

يوضح هذا الموضوع أنواع العناصر التي تم تعريفها في SNMP v1 and v2.

يمكنك ايجاد معلومات العنصر التي تم توضيحها في الأقسام التالية بتحديد وحدة برامج في مشاهدة MIB Modules ثم البحث عن ifIndex في المجال بحث لمشاهدة تسلسل OID. اضغط على العنصر ifIndex في التسلسل الهرمي تسلسل OID لمشاهدة معلومات العنصر ومعلومات المصطلح النصي في مشاهدة التفاصيل.

OBJECT IDENTIFIER

يتم تعريف OBJECT IDENTIFIER بواسطة SNMP v1 ويعد كتلة البناء الرئيسية بتسلسل MIB. تكون أكواد تعريف العنصر مناظرة لعناوين الفصول في الكتاب - حيث لا تحتوي على بيانات حقيقية، لكن تقدم فكرة عن نوع المحتويات المتضمنة بواسطة العناصر الفرعية الخاصة بها.

OBJECT TYPE

يتم تعريف OBJECT-TYPE بواسطة SNMP v1 ويتم استخدامه كحاوية لفرز المعلومات عن الجهاز الذي يتم ادارته أو بعض القيم التي يتم قياسها بالجهاز.

TEXTUAL CONVENTION

يعد TEXTUAL-CONVENTION (TC) تعريف لنوع العنصر لكن ليس عنصر فعلي. في مشاهدة وحدات برامج MIB، يمكنك تحديد المفاهيم النصية من الكشف مشاهدة لمشاهدة المفاهيم النصية التي تم اجراء تحليل لغوي لها وعرضها في تسلسل MIB. حدد اسم TC في تسلسل MIB لعرض التعريف الخاص به في مشاهدة التفاصيل.

SNMP v1 TRAP TYPE و SNMP v2 NOTIFICATION TYPE

يعد SNMP v1 TRAP-TYPE و v2 NOTIFICATION-TYPE آليات الى SNMP لتكوين أحداث مستقلة الى SNMP Manager. لا يتم تعريف ملفات تعقب المشاكل SNMP في النسخة v1 كعناصر في تسلسل MIB. لا يكون لعنصر TRAP-TYPE عنصر رئيسي تم تعريفه بالنسق OBJECT IDENTIFIER. بدلا من ذلك، يقوم تعريف ملف تعقب المشاكل بتحديد المؤسسة التي تم تعريف الملف لها. فيما يلي عنصر TRAP-TYPE:

bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
 bgpPeerState } DESCRIPTION "يتم تكوين حدث BGP المؤسس عندما يقوم BGP FSM 
بالدخول فى حالة ESTABLISHED." ::= 1

يقوم القسم ENTERPRISE بتعريف العنصر الرئيسي بملف تعقب المشاكل. لكن، يمكن تعريف عنصر تسلسل MIB مع bgp على أنه العنصر الرئيسي وتعريفه كرقم فرعي 1. في الواقع، يتم تعريف bgpVersion على أنه { bgp 1} في وحدة البرامج RFC1269-MIB. لذلك، يكون من غير الممكن اضافة ملف تعقب مشاكل بالنسخة v1 الى تسلسل MIB كعنصر فرعي باستخدام ENTERPRISE كالعنصر الرئيسي.

يقوم SNMP v2 بتغيير التعريف بالنسبة الى TRAP-TYPE الى NOTIFICATION-TYPE ويحدد أن ملف تعقب المشاكل v2 الجديد يتم تعريفه مثل عناصر MIB الأخرى، مع رقم رئيسي وفرعي مما يجعل هذا مشكلة بالنسبة لملفات تعقب المشاكل بالنسخة v1 فقط. يقوم RFC1155 Section 4.1 بتعريف أن استخدام الصفر (0) كرقم فرعي يعد غير صحيح، ويتم حجز للاستخدام المستقبلي. يقوم SNMP v2 باستخدام هذا الصفر من خلال السماح للموردين باضافة ملفات تعقب المشاكل ذات النسخة v1 الخاصة بهم الى v2 MIB، من خلال اضافة صفر الى اسم المؤسسة ثم اضافة رقم ملف تعقب المشاكل بعد الصفر. لذلك، أسفل v2 يكون من المناسب تعريف كود تعريف العنصر بصفر كرقم فرعي للمشروع ثم اضافة ملفات تعقب المشاكل ذات النسخة v1 كملفات فرعية لهذا الصفر.

يؤدي هذا المصطلح لحدوث خطأ عام أخر بواسطة مؤلفي MIB. يوضح القسم 4 من RFC1155 ما يلي:

"يتكون تعريف نوع العنصر من خمس مجالات: OBJECT: ------- اسم نصي، OBJECT DESCRIPTOR، لنوع العنصر، مع OBJECT IDENTIFIER المناظر. الصيغة: صيغة الملخص لنوع العنصر. يجب أن يتم حل هذا الى نسخة ASN.1 النوع ObjectSyntax (المعرف بأسفل). التعريف: وصف نصي لمعنى نوع العنصر. يجب أن يقوم الاعداد بالتأكد من أن النسخة الخاصة بهم من العنصر تقابل هذا التعريف حيث أن MIB هذا خاص بالاستخدام في بيئات التشغيل ذات موردين متعددين. كما يعد من المهم أن يكون للعناصر معاني متسقة خلال كل الأجهزة. امكانية التوصل: أي من قراءة-فقط أو قراءة-كتابة أو كتابة-فقط أو لا يمكن التوصل. الحالة: أي من أساسي أو اختياري أو غير مستخدم. قد تحدد المذكرات المستقبلية مجالات أخرى للعناصر التي تقوم بتعريفها. "

وفقا لهذه القاعدة، يجب أن يكون لكل العناصر كلا من اسم عنصر ورقم عنصر. بعض وحدات برامج MIB الخاصة بالمورد، وأيضا بعض RFC تقوم بتعريف NOTIFICATION-TYPE مع عنصر رئيسي بالرقم صفر لكن بدون اسم عنصر لهذا الصفر. في المثال التالي، لا يعد تعريف العنصر صحيح لغويا حيث لا يوجد اسم عنصر معرف للرقم الفرعي صفر للعنصر adslAtucTraps. يتعرف MIB Manager على تفضيلات بعض مؤلفى MIB لاستخدام مثل هذه الطرق كمسار مختصر، والسماح باضافة العنصر بدون اسم العنصر. بالاضافة الى ذلك، لتسهيل اضافة الصفحات الشرطية v1 الى تسلسل MIB، يقوم MIB Manager آليا باضافة عنصر صفر كفرع من عنصر مشروع v1 (لاحظ أن v1 MIB لا يمكنه استخدام صفر فى ما يخصه من OID)، ويقوم بتخصيص عنصر الصفر هذا كصفحة شرطية حيث اسم المشروع واضافة الصفحة الشرطية أسفل هذا العنصر الجديد فى تسلسل MIB. على سبيل المثال، سينتج عن استخدام bgp العناصر الفرعية المتفرعة لملفات تعقب المشاكل التالية: { bgp bgpTraps(0) 1 }).

adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 }

Varbinds

العناصر التي يتم نقلها باستخدام ملف تعقب المشاكل للنسخة v1 أو الاعلام للنسخة v2 تعرف على أنها varbinds. تحتوي Varbinds على معلومات اضافية عن الحدث الذي تم تسجيله. في ملف تعقب المشاكل v1، يتم تحديد بنود الى varbinds في قسم VARIABLES وفي الاعلام للنسخة v2 يتم عرض varbinds في قسم OBJECTS. سيكون لها نفس الاستخدام في كل نسخ SNMP. ترتيب عرض varbinds في الكشف يكون ضروري لأن PDU (SNMP Packet) يقوم بتكويد القيم المرفقة بنفس ترتيب عرضها في MIB.

على سبيل المثال، في قسم OBJECTS تم تحديد الثلاثة varbinds التاليين: ifIndex و ifAdminStatus و ifOperStatus. لذلك، يعد ifIndex أول varbind يتم تكويده، و ifAdminStatus هو الثاني، و ifOperStatus هو الثالث. من خلال التحقق من IF-MIB تم ايجاد أنه تم تعريف نوع عنصر ifIndex على أنه InterfaceIndex. وحيث أنه لا يعد نوع ASN.1 أولي صحيح الى SNMP، فانه يجب أن يكون مفهوم نصي. وبالبحث خلال المفاهيم النصية، تم ايجاد أنه تم حل InterfaceIndex الى Integer32 (رقم صحيح ذو 32 بت) بالفعل. وبالتالي، عندما يصل PDU الى MIB Manager، يصبح أول varbind رقما صحيحا. لتحديد معنى هذا الرقم الصحيح، يجب على MIB Manager الاشارة الى وحدة برامج IF-MIB، والبحث عن ifIndex، وقراءة معلومات العنصر المرفق. وبالتحقق من varbind الثاني، تم ايجاد نوع رقم صحيح تم عده:

SYNTAX INTEGER { up(1), -- اجهاز لامرار حزم البرامج down(2)، 
testing(3) -- في بعض أنماط الاختبار }

عند فك تكويد varbind من حزمة برامج SNMP، ستكون القيمة الخاصة به رقم صحيح، ويجب ترجمة القيمة الخاصة به بناءا على البنود التي توجد في الكشف الذي تم تعداده هذا. عندما يتم استخدام MIB Manager لتكوين ملف قواعد، سوف يتم تكوين جدول للبحث لربط الرقم الصحيح المعدود آليا بالتمثيل النصى الخاص به. يعد varbind الثالث نوع تم عده أيضا بنفس القيم. لذلك، اذا كان ifAdminStatus هو 1 (up) و ifOperStatus هو 2 (down)، سيكون سبب تكوين الحدث معروفا وسيمكن الاستمرار في محاولة تحديد سبب انقطاع الخدمة هذا.

يتم تقديم Varbinds للمستخدم في rulesfile على أنه $1 و $2 و $3 وهكذا، مع كل رقم يمثل رقم varbind. يقوم MIB Manager بتكوين العناصر بناءا على عناصر varbind ويستخدم هذه العناصر لتحديد المتغيرات فى جدول التفاصيل. على سبيل المثال، العناصر التى يتم استخدامها فى جدول التفاصيل قد تكون $ifIndex = $1، الذى سوف يكون رقم صحيح، $ifAdminStatus = $2، الذى سوف يكون شيء من هذا القبيل حتى (1)، و $ifOperStatus = $3، الذى سوف يبدو كما أقل (3). أية تغييرات يتم اجرائها على محددات العنصر سيتم تحديدها آليا في ملف القواعد، باستخدام المفاهيم التي تم تحديدها بواسطة Netcool Knowledge Library (NCKL).

الجداول

تمثل الجداول ما يكافئ متجه متعدد الأبعاد ذو صفوف وأعمدة بيانات. يتم تعريف عنصر الجدول على انه SEQUENCE OF لعنصر ادخال. عندئذ يتم تعريف عنصر الادخال على انه SEQUENCE لعناصر OBJECT-TYPE. في بعض الأحيان، يمكن أن يقوم المورد بتصميم نظام غير عادي، على سبيل المثال، أداة التوجيه isco 10k. يحتفظ هذا الجهاز بجدول داخلي لشروط التنبيه ويقوم بتكوين ملف تعقب مشاكل أو اعلام عند تغيير الجدول. عندئذ يجب أن تقوم باصدار طلب SNMP GET على محتويات الجدول لتحديد الحالة الحالية للتنبيهات الفعالة للجهاز. وهذا يجعل الحصول على التنبيهات بواسطة SNMP Manager أكثر صعوبة، لكن غير مستحيلة، اذا كان موجه النظام يتوافر لديه الأدوات للتوافق.

OCTET STRING

يعد الثماني هيكل بيانات يتكون من ثماني بت (تعرف عادة باسم بايت). مجموعة حروف OCTET STRING، تعد متجه من البايت (أو مجموعة من البايت). لا يشير المصطلح OCTET STRING الى أن كل البايت في مجموع ة الحروف تعد أبجدية عددية. يمكن أن تكون أيضا حروف ثنائية ويتم استخدامها على انها bitmasks.

المكتبة | الدعم |