כל המודולים של SNMP MIB המוגדרים לשימושו של התקן ספציפי מרכיבים את ה-MIB עבור אותו התקן. המונח MIB משמש לעיתים קרובות לתיאור הגדרה של מודול יחיד, עם זאת, מצב זה שגוי מבחינה טכנית. למעשה, ה-MIB הוא השילוב של כל המודולים המשמשים לניהול של התקן ספציפי, בין אם הוא קשור לחומרה או לתוכנה. לכן, השם המדויק יותר של כל מודול המוגדר על-ידי ספק או ב-RFC הוא מודול SNMP MIB.
כל מודולי ה-MIB הם בסופו של דבר הרחבות של מודול היסוד. כל מודולי ה-MIB המופצים מספקים נפרדים, מקורם באובייקט הארגונים המוגדר ב-RFC1155-SMI. לכן, כל הסוכנים של SNMP חייבים לתמוך ב-RFC1155, וכן המודולים של MIB הם הרחבות של RFC1155.
כדי לאפשר את הרחבת בסיס המידע הניהולי (MIB) של SNMP, פריטים קשורים מסודרים במודולים של MIB היוצרים היררכיה מובנית. כל מודול MIB מוגדר במבנה שלהלן:
ModuleName DEFINITIONS ::= BEGIN END
התווית BEGIN והתווית END במודול מאפשרות להגדיר מספר מודולים בקובץ תמליל אחד. מהדרים של MIB אמורים להיות מסוגלים לטפל בכל מספר כלשהו של מודולים המוגדרים בקובץ יחיד, אך הם אינם אמורים לדרוש זאת.
קיימות מוסכמות לכל אובייקט המוגדר במודול. לדוגמה, שם המודול חייב להתחיל בתו אלפאבתי באות רישית ולהכיל אותיות, מספרים, מקפים (-), או מקפים תחתונים (_) בלבד. שם האובייקט חייב להתחיל בתו אלפאבתי באות קטנה ולהכיל אותיות, מספרים, מקפים, או מקפים תחתונים בלבד. הערות במודולים של MIB מיוצגות על-ידי שני מקפים עוקבים (--) וניתן להתעלם מכל תמליל המופיע אחרי סמל זה או שורה כלשהי.
העיצוב המודולרי מאפשר להרחיב בקלות רכיבי MIB, והם יכולים לתמוך בפונקציונליות או בהתקנים חדשים על-ידי הוספת מודולים. בעת כתיבת מודול בתור הרחבה של מודול אחר, הוא יכלול מקטע IMPORTS, ממוקם מתחת לשורה DEFINITIONS. המקטע IMPORTS מגדיר את האובייקטים הדרושים למודולים הממוקמים גבוה יותר בהיררכיית ה-MIB ואת המודולים שבהם הם מוגדרים.
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress,
IpAddress, TimeTicks FROM RFC1155-SMI;
שגיאות טופוגרפיות נגרמות בקלות בעת ציון שמות MIB שיובאו. לדוגמה, RFC1212 עשוי להיות מצוין כמודול MIB במקום השם הנכון, RFC-1212. אם MIB Manager מסמן שגיאות ניתוח, יש לבדוק את המקטע IMPORTS כדי לוודא ששמות המודולים של MIB נכונים. מודולים מסוימים של MIB אף מכילים מקטע של EXPORTS (שגם מסתיים בנקודה ופסיק). מקטע זה מודיע לקורא שהמחבר דורש ממודולים אחרים של MIB להשתמש באותם האובייקטים שצוינו. מקטע זה אינו רלוונטי למטרותינו ויש להתעלם ממנו.
מודולים של SNMP MIB מוגדרים בתבנית שנקראת ASN.13 (Abstract Syntax Notation 1). אולם, SNMP משתמש רק בחלק מ-ASN.14. ASN.1 מוגדר ב-ITU-T X.208 וב-ISO 8824. החלקים ב-ASN.1 החלים על SNMP מוגדרים ב-RFC1155. RFC1155 מגדיר את סוגי הנתונים החוקיים של SNMP להלן:
סוג מוגדר הוא המנגנון המשמש לציון מבנה מסוים לסוגים בסיסיים או לסוגי בנאים. מחברי MIB יכולים לקבוע סוגים מוגדרים נוספים באמצעות המבנה TEXTUAL-CONVENTION.
DisplayString ::= OCTET STRING (0..255)
DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION
"מייצג מידע של תמליל הנלקח מערכת התווים של NVT ASCII, כמוגדר
בעמודים 4, 10-11 של RFC 854. כדי לסכם את RFC 854, אוסף הכללים של NVT ASCII
מציין: - שימוש בקודי התווים 0-127 (עשרוני) - התווים הגרפיים (32-126)
מפורשים בתור US ASCII - NUL, LF, CR, BEL, BS, HT, VT ו-FF הם בעלי משמעויות
מיוחדות המצוינות ב-RFC 854 - יתר 25 הקודים אינם בעלי פירוש
תקני - משמעות הרצף 'CR LF' היא שורה חדשה - משמעות הרצף 'CR NUL' היא
החזרת גררה - ערך 'LF' שלא קודם לו 'CR' פירושו מעבר לאותה עמודה
בשורה הבאה. - הרצף 'CR x' עבור כל ערך x אחר שאינו LF או NUL אינו חוקי.
(כמו כן, שימו לב, כי משמעות הדבר שמחרוזת עשויה להסתיים ב-'CR LF' או ב-'CR NUL',
אך לא ב-CR.) אורכו של כל אובייקט המוגדר באמצעות תחביר זה אינו יכול לחרוג מ-255 תווים."
SYNTAX OCTET STRING (SIZE (0..255))
הדוגמה המוצגת לעיל מראה ש-DisplayString הוא OCTET STRING שאורכו הוא 0 עד 255 תווים. שימו לב, כי כל ערך של
OBJECT DESCRIPTOR התואם לסוג האובייקט ב-MIB בתקן האינטרנט חייב להיות מחרוזת ייחודית, מסייעת לזכירה, הניתנת להדפסה.טעות נפוצה המתבצעת בעת כתיבת מודולים היא יצירת שם אובייקט שאינו ייחודי. הטענה היא, שמשמעותה של הצהרת RFC1155 היא שרק אובייקטים בתוך מודול MIB יחיד חייבים להיות ייחודיים. כפי שצוין קודם לכן, ה-MIB הוא ערכת המודולים השלמה, וכאשר משלבים את מודולים אלה הם משמשים לניהול התקן מסוים. לכן, כל האובייקטים המוגדרים במודול ה-MIB חייבים להיות ייחודיים, לא רק במודול עצמו, אך גם בכל שם אובייקט אחר בכל המודולים שמיובאים, ובכל המודולים שאותם מודולים עשויים לייבא. מנגנון נפוץ שמטרתו להבטיח ששמות האובייקטים ייחודיים הוא להוסיף מראש את סמל המניה או השם המקוצר של החברה לכל שמות המודולים.
בעת הגדרת האובייקטים הם ממופים להיררכיה מספרית הדומה לעץ מורחב. בכל פעם שאובייקט מוגדר, הוא מוגדר בתור עלה של אובייקט האב. שלושת אובייקטי היסוד הבאים מוגדרים בעץ SNMP MIB:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::=
{ internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER
::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT
IDENTIFIER ::= { private 1 }
הגדרות אלה מציינות את שם האובייקט, את סוג האובייקטים המשויכים, את שם האב של כל אובייקט (או רשימת אבות מסודרת) ואת מספר הצומת של בן זה לאותו אב (או אבות). פריטים אלה מסודרים בצורה היררכית מבחינה גרפית.
הניווט בתצוגה עץ MIB מתבצע על-ידי הרחבה וצמצום של הצמתים בעץ ה-MIB. הענפים ברמה העליונה של העץ של MIB מכילים את שמות המודולים של MIB, וכל ענף של מודול MIB כולל מרכיבים אחרים שמהם בנוי ה-MIB. ככל שמוספים מודולים ל-MIB, כך נוספים אובייקטים לעץ ה-MIB. ניתן להפנות אל כל אובייקט לפי שם האובייקט שלו או לפי זיהוי האובייקט שלו (OID). השיטה המדויקת ביותר היא להפנות אל ה-OID שלו. ה-OID של האובייקט מוגדר בתור המספר שלו, וכל אחד ממספרי ההורים שלו ממשיכים חזרה לצומת היסוד, כאשר הם מחוברים יחדיו באמצעות נקודה (.) המפרידה ביניהם. ה-OID של אובייקט הארגון (צומת או עלה) הוא 1.3.6.1.4.1.
ספקים רבים אינו מוודאים ששמות האובייקטים שלהם ייחודים ברחבי המערכת, ולכן קיימת האפשרות שלשני ספקים יהיה אובייקט בעל אותו שם. מצב זה הופך את השימוש בשם האובייקט לזיהוי האובייקט לרב-משמעי במקצת.