IBM Tivoli Netcool/OMNIbus, מהדורה 7.4

סוגי אובייטים של MIB

נושא זה מתאר את סוגי האובייקטים המוגדרים ב-SNMP v1 ו-v2.

תוכלו לאתר את מידע האובייקט המתואר במקטעים הבאים באמצעות בחירת מודול בתצוגה מודולים של MIB ולאחר מכן חיפוש אחר 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. לכידות 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. מקטע 4.1 ב-RFC1155 קובע שהשימוש באפס בתור מספר בן אינו חוקי, וכי הוא שמור לשימוש בעתיד. SNMP v2 עושה שימוש באפס זה בכך שהוא מאפשר לספקים להוסיף לכידות v1 ל-MIB מסוג v2, על-ידי הוספת אפס לשם הארגון והוספת מספר הלכידה לאחר האפס. לכן, תחת v2 ניתן להגדיר זיהוי אובייקט עם אפס בתור בן הארגון ולאחר מכן להוסיף לכידות v1 בתור בנים של אותו אפס.

מוסכמה זו גרמה למחברים של MIB לבצע שגיאה נפוצה נוספת. מקטע 4 של RFC1155 מציין:

"הגדרה של סוג אובייקט מורכבת מחמישה שדות: OBJECT: ------- A שם תמליל, המכונה OBJECT DESCRIPTOR, עבור סוג האובייקט, יחד עם ה-OBJECT IDENTIFIER המתאים לו. תחביר: התחביר המופשט של סוג האובייקט. על ערך זה להיות מפוענח למופע של ASN.1 מסוג ObjectSyntax (מוגדר להלן). הגדרה: תיאור תמליל של הסמנטיקה של סוג האובייקט. היישומים אמורים להבטיח שהמופעים של האובייקט שלהם ממלאים הגדרה זו מאחר ש-MIB נועד לשמש בסביבות עם ספקים מרובים. לכן, הכרחי שלאובייקטים תהיה משמעות עקבית בכל המחשבים. גישה: מסוג לקריאה בלבד, קריאה-כתיבה, כתיבה בלבד או ללא גישה. סטאטוס: מסוג הכרחי, אופציונלי, או מיושן. תזכירים עתידיים יכולים גם לציין שדות אחרים עבור האובייקטים שהם מגדירים."

לפי כלל זה, כל האובייקטים חייבים לכלול שם אובייקט ומספר אובייקט. מודולי MIB של ספקים מסוימים, ואפילו חלק מרכיבי ה-RFC, הגדירו NOTIFICATION-TYPE עם אב בערך אפס אך ללא שם אובייקט עבור אותו אפס. בדוגמה שלהלן, התחביר של הגדרת האובייקט שגויה מאחר שלא הוגדר שם אובייקט עבור בן מספר אפס באובייקט adslAtucTraps. MIB Manager מזהה את העדפתם של מחברי MIB מסוימים להשתמש בשיטות כאלה כקיצור דרך ומאפשר להוסיף את האובייקט ללא שם אובייקט. בנוסף, כדי לסייע בהוספת לכידות v1 לעץ ה-MIB‏, MIB Manager מוסיף באופן אוטומטי אובייקט אפס בתור בן של אובייקט ארגון מסוג v1 (שימו לב ש-MIB מסוג v1 אינו יכול להשתמש באפס ב-OID שלו), מקצה לאותו אובייקט אפס בתור לכידות במקומות שבהם נמצא שם הארגון ומוסיף את הלכידה מתחת לאובייקט חדש זה בעץ ה-MIB. לדוגמה, שימוש ב- bgp יגרום להורי הלכידות הבאים: { bgp bgpTraps(0) 1 }).

adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, 
adslAtucThresh15MinLofs } STATUS current DESCRIPTION "המערכת הגיעה לסף מרווח של 15 דקות 
של אובדן מסגרת." ::= { adslAtucTraps 0 1 }

Varbinds

אובייקטים הנשלחים עם לכידת v1 או הודעת v2 נקראים varbinds. Varbinds כוללים מידע נוסף על האירוע המדווח. בלכידת v1, ה-varbinds מפורטים במקטע VARIABLES ובהודעת v2 ה-varbinds מפורטים במקטע OBJECTS. הם בעלי אותו שימוש בכל הגרסאות של SNMP. הסדר שבו מופיעים ה-varbinds ברשימה הוא חשוב מכיוון שה-PDU (חבילת SNMP) מקודד את הערכים המשויכים באותו סדר שבו הם מפורטים ב-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), -- ready to pass packets down(2), 
testing(3) -- in some test mode }

כאשר ה-varbind מפוענח מחבילת SNMP, הערך שלו יהיה מספר שלם, ערך זה צריך להיות מפורש בהתבסס על הפריטים ברשימה ממוספרת זו. כאשר MIB Manager משמש ליצירת קובץ כללים, הוא יצור טבלת בדיקת חיפוש כדי לקשר באופן אוטומטי בין המספר השלם הממוספר ובין הייצוג הטקסטואלי שלו. ה-varbind השלישי הינו סוג ממוספר גם כן עם אותם ערכים. לכן, אם ה-ifAdminStatus הוא 1 (up) וה-ifOperStatus הוא 2 (down), אנו יודעים מדוע הופק האירוע ויכולים להמשיך ולנסות לקבוע את הסיבה להפסקה זו.

Varbinds מוצגים למשתמש בקובץ כללים כגון $1‏, $2‏, $3, וכן הלאה, כשכל מספר מייצג מספר varbind. ה-MIB Manager יוצר מרכיבים בהתבסס על מרכיבי varbind והוא משתמש בהם להגדרת משתנים בטבלת הפרטים. לדוגמה, המרכיבים המשמשים בטבלת הפרטים עשויים להיות $ifIndex = $1, שיהיה מספר שלם, $ifAdminStatus = $2, שהוא דבר מה דומה ל-up‏ (1), ו-$ifOperStatus = $3, שהוא דבר מה דומה ל-down‏ (3). כל שינוי שהוא שיתבצע בהגדרות האובייקט מוגדר באופן אוטומטי בקובץ הכללים, בעזרת ערכת המוסכמות שהוגדרה על-ידי Netcool Knowledge Library‏ (NCKL).

טבלאות

טבלאות מייצגות רכיב שווה ערך למערך רב-ממדי בעל שורות ועמודות של נתונים. אובייקט הטבלה מוגדר בתור SEQUENCE OF של אובייקט רישום. אובייקט הרישום מוגדר לאחר מכן בתור SEQUENCE של אובייקטים מסוג OBJECT-TYPE. לעיתים, ספק מעצב מערכת לא רגילה, לדוגמה הנתב Cisco 10k. התקן זה כולל טבלה פנימית של תנאי התרעות ומפיק לכידה או הודעה כאשר הטבלה משתנה. לאחר מכן יש להנפיק בקשת SNMP GET על תוכן הטבלה כדי לקבוע את הסטאטוס הנוכחי של ההתרעות הפעילות בהתקן. מצב זה מקשה על קבלת ההתרעות על-ידי המנהל של SNMP, אך אינו מונע אותה, אם המנהלן מצויד בכלים המתאימים.

OCTET STRING

שמיניה היא מבנה נתונים המורכב משמונה סיביות (הידוע בתור בית). אם כן, OCTET STRING הוא מערך של בתים (או מחרוזת של בתים). המונח OCTET STRING אינו רומז שכל הבתים במחרוזת הם אלפאנומריים. הם גם יכולים להיות תווים בינאריים ולשמש בתור מסיכות סיביות.

ספריה | תמיכה |
עודכן לאחרונה: נובמבר 2012