שוביט מחשוב

MIB - Management Information Base

במאמר הקודם עסקנו ב OID שהינו רכיב קרדינלי בשימוש ב SNMP. במאמר הזה, אגע ב MIB - המשלים של ה OID. נתחיל בהסבר שילך כך : נניח שחברת מסוימת פיתחה Firewall (או כל ציוד תקשורת אחר), והם רוצים לעדכן את כל ה nms-ים שבעולם ברשימת ה OID שאיתם אפשר לדגום את הציוד שלהם, באיזה פורמט הם יגדירו ויפרסמו זאת עבור ה NMS ?

התשובה, כמו שניחשתם, היא קובץ MIB. מדובר בקובץ טקסט בפורמט של סטנדרט/שפת ASN (חבל שכאשר פיתחו את ה MIB לא חשבו על שפות יותר ידידותיות למשתמש). קובץ ה MIB מכיל את ה Metadata עבור כל OID, וכן את ההיררכיה של כל ה OIDs. לצורך המחשה, נניח שיש פנייה של NMS ל- SNMP Agent של Palo Alto (שרץ כמובן על ה FW) על מנת לדעת איזה גרסת מערכת אפליקציה יש ל FW. אז ל-NMS הוטען ה MIB הרלוונטי של Palo Alto כמובן, והפנייה מתבצעת על ידי ה NMS עם ה OID הרלוונטי (1.3.6.1.4.1.25461.2.1.2.1.7). ה NMS כמובן מחכה לתשובה, והוא אמור לעשות איתה משהו - לפרסר אותה או לשמור אותה ב DB או כל דבר אחר.

איך ה NMS יודע מה סוג המידע שאמור להתקבל- האם גרסת ה FW אמור לחזור כ String או כ Integer ?

יש מקום בו הדברים האלו צריכים להיות מוגדרים, וזה ה MIB. הינה התשובה לשאלה ששאלנו למעלה :

דוגמה נוספת, זוכרים שמאמר הראשון דובר על זה שבעזרת SNMP אפשר גם לכתוב לתוך ציוד/סוכן? איפה מוגדר אם אפשר לשנות אובייקט של OID בעזרת פעולת כתיבה (Write)? התשובה - גם זה מוגדר ב MIB. שימו לב להבדל בהדגשה לעומת התמונה הקודמת :

וכמובן, דבר נוסף שמוגדר ב MIB, זה שמות נוחים לקריאה עבורנו - המשתמשים. למשל, ה OID שמייצג את גרסת אפליקציית ה FW הוא 1.3.6.1.4.1.25461.2.1.2.1.7. זה מתורגם ב MIB ל panSysAppVersion (זה כמובן שם ה OID ולא ה VALUE עצמו). כמו כן, ה MIB גם מכיל תיאור נוסף של אותו שדה. במקרה שלנו, עבור panSysAppVersion, זה :

היררכיה
לגבי ההיררכיה של ה OIDs, גם כאן הדבר מוגדר באמצעות ה MIB. התחביר לא כל כך אינטואיטיבי, אבל בסוף מתרגלים להכל. הינה כמה דגשים : בכל MIB (למעט ה MIB-ים הבסיסים ביותר שהם ה CORE של כל ה MIBS האחרים), מתבצע יבוא של טיפוסי נתונים ומידע רלוונטי מתוך ה "Core\Root MIBs"

מספר ה Enterprise של אותה חברה (הוסבר במאמר הקודם) :



אובייקט סקלארי - אובייקט "חד מימדי"- של ערך אחד, מודגש בתמונה הבאה בצבע ירוק .
לעומת זאת, אובייקט טבלאי - אובייקט שמאגד תחתיו מספר אובייקטים שקיים בניהם יחס מסוים. מודגש בצבע צהוב

שני טיפוסים בסיסים שכדאי מאד להכיר הם :

• Object Type - מייצג NODE של OID ספציפי.
• Notification Type - מייצג NODE של OID ספציפי מסוג TRAP.

הינה תמונות להמחשה של Object Type ולאחריו של Notification Type :







האינטראקציה בניהם : Object Type יכול להידגם בעצמו, או להיות מועבר כפרמטר של בתוך Trap (אפשר לראות דוגמה במאמר הקודם). כמובן של NMS אין שליטה אלו Varbinds יועברו אליו יחד עם ה TRAP, אלא זה מה שמוגדר בציוד ששולח את ה TRAP על ידי היצרן.

אני רוצה לציין עוד כמה דברים לסיום: :

• יש עוד מספר טיפוסי נתונים ומספר דברים שאולי שווה להכיר בתחביר של ה MIB, אבל זה לא משהו שהוא הכרחי להכיר לצורך ניטור ברמה הבסיסית
• במאמר הזה נתתי דוגמאות מתוך MIB של חברת Palo Alto. אין בהם משהו מיוחד, מעבר לכך שהם בנוים נכון, והיתי יכול לבחור כמעט בכל MIB אחר לצורך ההדגמה.
  מה שכן חשוב לציין זה שיש את ה MIBS הגנריים שלא שייכים לחברה מסויימת. למשל ה MIB הסטנדרטי ביותר שנקרא RFC1155-SMI ומכיל את כל המידע הבסיסי ביותר. למשל התחלת ההיררכיה של ה OID, וגם טיפוסי המשתנים (String, Int, Date) והיכולות השונות (ReadOnly, Write) הינה תמונה שמתחיש זאת מתוך ה MIB :
  
  
  
  
  
  אחריו בהיררכיה ישנם כמובן MIB-ים פנימים יותר שדרכם אפשר לחשוף יותר מידע. למשל מי שיורש מה MIB שהוזר לעיל, זה MIB ששמו RFC1213-MIB. אפשר לראות ששם למשל מוגדרים דברים גנריים מאד (שרלוונטים לכל ציוד), כמו System Up Time
  
  
  
  
  
  
• עבור יצרני חומרה להגדיר MIB ספציפי עבור החומרה שלהם, זו מלאכת מחשבת של ממש. עם ה MIB בנוי בצורה נכונה תחבירית, זה לא מספיק. יש לכתוב את ה MIB כך שיאפשר לNMS-ים להוציא את המידע בצורה המיטבית, כאשר הם מתשאלים את הציוד שיודע להשיב עבור אותו ה MIB