Erlang 21 - 2. Agent Functional Description

2 एजेंट कार्यात्मक विवरण




erlang

2 एजेंट कार्यात्मक विवरण

SNMP एजेंट सिस्टम में एक मास्टर एजेंट और वैकल्पिक उप-एजेंट होते हैं।

उपकरण रन-टाइम में SNMP एजेंट को गतिशील रूप से विस्तारित करना आसान बनाता है। MIB को कभी भी लोड और अनलोड किया जा सकता है। MIB को फिर से जोड़ने के बिना, रन-टाइम में MIB के कार्यान्वयन को बदलना भी आसान है। MIB कार्यान्वयन स्पष्ट रूप से एजेंट से अलग होता है।

वृद्धिशील एमआईबी कार्यान्वयन की सुविधा के लिए, उपकरण पूरे एमआईबी, या उसके कुछ हिस्सों के लिए प्रोटोटाइप कार्यान्वयन उत्पन्न कर सकता है। यह विभिन्न MIB और प्रबंधन अनुप्रयोगों को एक ही समय में विकसित करने की अनुमति देता है।

२.१ सुविधाएँ

एक एजेंट को लागू करने के लिए, प्रोग्रामर MIBs में चर और तालिकाओं के लिए इंस्ट्रूमेंटेशन फ़ंक्शन लिखता है, जो एजेंट का समर्थन करने वाला है। एक रनिंग प्रोटोटाइप जो set , get , और get-next बिना किसी प्रोग्रामिंग के बनाया जा सकता है।

टूलकिट निम्नलिखित प्रदान करता है:

  • बहुभाषी बहु थ्रेडेड एक्स्टेंसिबल SNMP एजेंट
  • उच्च स्तरीय प्रोग्रामिंग भाषा के साथ इंस्ट्रूमेंटेशन कार्यों का आसान लेखन
  • बुनियादी गलती जैसे स्वचालित प्रकार की जाँच
  • पहुँच नियंत्रण
  • प्रमाणीकरण
  • एन्क्रिप्शन के माध्यम से गोपनीयता
  • रन-टाइम में MIB की लोडिंग और अनलोडिंग
  • MIB को पुन: स्थापित किए बिना इंस्ट्रूमेंटेशन कार्यों को बदलने की क्षमता
  • रैपिड प्रोटोटाइप वातावरण जहां MIB कंपाइलर जेनेरिक इंस्ट्रूमेंटेशन फ़ंक्शन का उपयोग कर सकता है, जिसे बाद में प्रोग्रामर द्वारा परिष्कृत किया जा सकता है
  • लेनदेन से निपटने के लिए एक सरल और एक्स्टेंसिबल मॉडल और सेट-रिक्वेस्ट की स्थिरता की जाँच
  • वितरित एर्लांग के माध्यम से उप-एजेंट अवधारणा का समर्थन
  • सूचनाएं भेजने के लिए एक तंत्र (जाल और सूचना)
  • Mnesia DBMS में SNMP टेबल को लागू करने के लिए समर्थन।

2.2 एसएनएमपीवी 1, एसएनएमपीवी 2 और एसएनएमपीवी 3

एसएनएमपी विकास टूलकिट मानक इंटरनेट प्रबंधन फ्रेमवर्क के सभी तीन संस्करणों के साथ काम करता है; SNMPv1, SNMPv2 और SNMPv3। वे सभी एक ही मूल संरचना और घटकों को साझा करते हैं। और वे उसी वास्तुकला का पालन करते हैं।

संस्करण RFC के बाद परिभाषित किए गए हैं

  • एसएनएमपीवी 1 आरएफसी 1555, 1157 1212, 1213 और 1215
  • एसएनएमपीवी 2 आरएफसी 1902 - 1907
  • एसएनएमपीवी 3 आरएफसी 2570 - 2575

समय के साथ, जैसा कि एसएनएमपीवी 2 के माध्यम से एसएनएमपीवी 2 के माध्यम से फ्रेमवर्क विकसित हुआ है, एसएनएमपीवी 3 के माध्यम से इन वास्तु घटकों में से प्रत्येक की परिभाषाएं अधिक समृद्ध और अधिक स्पष्ट रूप से परिभाषित हो गई हैं, लेकिन मौलिक वास्तुकला लगातार बनी हुई है।

SNMPv1 की तुलना में SNMPv2 की मुख्य विशेषताएं हैं:

  • बड़ी मात्रा में डेटा स्थानांतरित करने के लिए get-bulk ऑपरेशन।
  • उन्नत त्रुटि कोड।
  • MIB विनिर्देशन के लिए एक अधिक सटीक भाषा

एसएनएमपीवी 2 को परिभाषित करने वाले मानक दस्तावेज अधूरे हैं, इस अर्थ में कि वे निर्दिष्ट नहीं करते हैं कि एसएनएमपीवी 2 संदेश कैसा दिखता है। संदेश प्रारूप और सुरक्षा समस्याएँ एक विशेष प्रशासनिक ढाँचे पर छोड़ दी जाती हैं। ऐसा ही एक ढांचा समुदाय आधारित SNMPv2 फ्रेमवर्क (SNMPv2c) है, जो SNMPv1 के समान संदेश प्रारूप और फ्रेमवर्क का उपयोग करता है। अन्य प्रायोगिक चौखटे मौजूद हैं, जैसे SNMPv2u और SNMPv2 *।

SNMPv3 विनिर्देशों SNMP के लिए एक मॉड्यूलर दृष्टिकोण लेते हैं। सभी मॉड्यूल एक दूसरे से अलग हो जाते हैं, और व्यक्तिगत रूप से विस्तारित या प्रतिस्थापित किए जा सकते हैं। मॉड्यूल के उदाहरण संदेश की परिभाषा, सुरक्षा और अभिगम नियंत्रण हैं। SNMPv3 की मुख्य विशेषताएं हैं:

  • एन्क्रिप्शन और प्रमाणीकरण जोड़ा जाता है।
  • एजेंट कॉन्फ़िगरेशन के लिए MIB को परिभाषित किया गया है।

इन सभी विशिष्टताओं को आमतौर पर "SNMPv3" के रूप में जाना जाता है, लेकिन यह वास्तव में केवल संदेश मॉड्यूल है, जो एक नया संदेश प्रारूप और सुरक्षा मॉड्यूल को परिभाषित करता है, जो एन्क्रिप्शन और प्रमाणीकरण का ख्याल रखता है, जिसे SNMPv1 या SNMPv2c के साथ उपयोग नहीं किया जा सकता है। एजेंट टूलकिट के इस संस्करण में, एजेंट कॉन्फ़िगरेशन के लिए सभी मानक MIB का उपयोग किया जाता है। इसमें सूचनाओं के लिए प्रबंधन लक्ष्यों की परिभाषा के लिए MIB शामिल हैं। इन MIB का उपयोग किया जाता है, इसके बावजूद कि SNMP संस्करण एजेंट को उपयोग करने के लिए कॉन्फ़िगर किया गया है।

इस टूलकिट में एक्स्टेंसिबल एजेंट SNMPv1, SNMPv2c और SNMPv3 को समझता है। याद रखें कि SNMP में दो अलग-अलग भाग होते हैं, MIB परिभाषा भाषा (SMI), और प्रोटोकॉल। प्रोटोकॉल स्तर पर, एजेंट को एक ही समय में v1, v2c, v3 या उनमें से किसी भी संयोजन को बोलने के लिए कॉन्फ़िगर किया जा सकता है, अर्थात v1 अनुरोध को एक v1 उत्तर मिलता है, एक v2c अनुरोध को एक v2c उत्तर मिलता है, और एक v3 अनुरोध प्राप्त होता है v3 उत्तर। MIB स्तर पर, MIB कंपाइलर SMIv1 और SMIv2 MIB दोनों को संकलित कर सकता है। एक बार संकलित करने के बाद, किसी भी प्रारूप को एजेंट में लोड किया जा सकता है, भले ही प्रोटोकॉल संस्करण किस एजेंट का उपयोग करने के लिए कॉन्फ़िगर किया गया हो। इसका मतलब यह है कि एजेंट v2 सूचनाओं से v1 जाल में अनुवाद करता है, और इसके विपरीत। उदाहरण के लिए, v2 MIBs को एक एजेंट में लोड किया जा सकता है जो केवल v1 बोलता है। दो प्रोटोकॉल के बीच अनुवाद की प्रक्रियाएं RFC 1908 और RFC 2089 में वर्णित हैं।

एन्हांस्ड SNMPv2 त्रुटि कोड का पूर्ण उपयोग करने के लिए एक कार्यान्वयन के लिए, यह आवश्यक है कि इंस्ट्रूमेंटेशन फ़ंक्शन त्रुटि के मामले में हमेशा SNMPv2 त्रुटि कोड लौटाएं। यदि आवश्यक हो तो ये एजेंट द्वारा संबंधित SNMPv1 त्रुटि कोड में अनुवादित किए जाते हैं।

ध्यान दें

एक SMIv1 MIB से एक SNMPv2c या SNMPv3 उत्तर का अनुवाद हमेशा बहुत सीधा होता है, लेकिन v2 MIB से v1 उत्तर तक अनुवाद कुछ अधिक जटिल होता है। SMIv2 में एक डेटा प्रकार है, जिसे Counter64 कहा जाता है, एक SNMPv1 प्रबंधक सही ढंग से डिकोड नहीं कर सकता है। इसलिए, एक एजेंट कभी भी एक Counter64 प्रबंधक को एक Counter64 ऑब्जेक्ट नहीं भेज सकता है। इन स्थितियों में सामान्य अभ्यास किसी भी Counter64 वस्तुओं को अनदेखा करना है, जब एक एसएनएमपीवी 1 प्रबंधक को उत्तर या जाल भेजते हैं। उदाहरण के लिए, यदि एक SNMPv1 प्रबंधक एक प्रकार की Counter64 की वस्तु प्राप्त करने की कोशिश करता है, तो उसे एक noSuchName त्रुटि noSuchName , जबकि एक SNMPv2 प्रबंधक को एक सही मूल्य मिलेगा।

२.३ ऑपरेशन

रनिंग एजेंट प्राप्त करने के लिए निम्न चरणों की आवश्यकता होती है:

  • एक पाठ फ़ाइल में SMI में अपना MIB लिखें।

  • एर्लैंग में इंस्ट्रूमेंटेशन फ़ंक्शंस लिखें और उन्हें संकलित करें।

  • एसोसिएशन फ़ाइल में उनके नाम रखें।

  • MIB कंपाइलर के माध्यम से एसोसिएशन फ़ाइल के साथ MIB को चलाएं।

  • एप्लिकेशन (एजेंट) कॉन्फ़िगर करें।

  • एप्लिकेशन (एजेंट) शुरू करें।

  • संकलित MIB को एजेंट में लोड करें।

इस खंड के आंकड़े एक एसएनएमपी एजेंट के विकास में शामिल चरणों का वर्णन करते हैं।

चित्र 2.1: MIB कंपाइलर सिद्धांत

कंपाइलर SMI फ़ाइल को पार्स करता है और इंस्ट्रूमेंटेशन फ़ंक्शन के साथ प्रत्येक टेबल या चर को जोड़ता है (चित्र MIB Compiler Principles )। MIB संकलन समय पर वास्तविक इंस्ट्रूमेंटेशन फ़ंक्शन की आवश्यकता नहीं है, केवल उनके नाम।

कंपाइलर द्वारा निर्मित बाइनरी आउटपुट फ़ाइल एजेंट द्वारा एमआईबी लोड समय पर पढ़ी जाती है (देखें Starting the Agent )। इंस्ट्रूमेंटेशन साधारण एर्लांग कोड है जो स्पष्ट रूप से लोड होता है या स्वचालित रूप से पहली बार इसे कहा जाता है।

चित्र 2.2: एजेंट शुरू करना

SNMP एजेंट सिस्टम में एक मास्टर एजेंट और वैकल्पिक उप-एजेंट होते हैं। मास्टर एजेंट को एक विशेष प्रकार के उप-एजेंट के रूप में देखा जा सकता है। यह कोर एजेंट की कार्यक्षमता, यूडीपी पैकेट प्रोसेसिंग, टाइप चेकिंग, एक्सेस कंट्रोल, ट्रैप डिस्ट्रीब्यूशन आदि को लागू करता है। उपयोगकर्ता के दृष्टिकोण से, यह एक साधारण उप-एजेंट के रूप में उपयोग किया जाता है।

यदि आपके एप्लिकेशन को SNMP टूलकिट से वितरण के लिए विशेष समर्थन की आवश्यकता होती है, तो उप-एजेंटों की केवल आवश्यकता होती है। यदि उप-एजेंट का उपयोग किया जा सकता है, तो अनुप्रयोग को मास्टर एजेंट से अधिक जटिल सेट लेनदेन योजना की आवश्यकता होती है।

निम्नलिखित चित्रण से पता चलता है कि कोई सिस्टम रनटाइम में कैसे दिख सकता है।

चित्र 2.3: वास्तुकला

एक विशिष्ट ऑपरेशन में निम्नलिखित चरण शामिल हो सकते हैं:

  • प्रबंधक एजेंट को एक अनुरोध भेजता है।
  • मास्टर एजेंट आने वाले यूडीपी पैकेट को डीकोड करता है।
  • मास्टर एजेंट यह निर्धारित करता है कि अनुरोध में किन वस्तुओं को यहां संसाधित किया जाना चाहिए और कौन सी वस्तुओं को उसके अधीन किया जाना चाहिए।
  • चरण 3 को सभी अधीनताओं द्वारा दोहराया जाता है।
  • प्रत्येक उप-एजेंट अपने लोड किए गए एमआईबी के लिए इंस्ट्रूमेंटेशन को कॉल करता है।
  • इंस्ट्रूमेंटेशन को कॉल करने के परिणामों को मास्टर एजेंट को वापस प्रचारित किया जाता है।
  • अनुरोध का उत्तर UDP प्रोटोकॉल डेटा यूनिट (PDU) में एन्कोड किया गया है।

दिखाए गए चरणों का क्रम सामान्य से अधिक जटिल है, लेकिन यह कार्यक्षमता की मात्रा को दिखाता है जो उपलब्ध है। निम्नलिखित बातों पर ध्यान दिया जाना चाहिए:

  • एक एजेंट के पास एक ही समय में कई MIB लोड हो सकते हैं।
  • उप-एजेंटों में उप-एजेंट भी हो सकते हैं। प्रत्येक उप-एजेंट के पास पंजीकृत उप-एजेंटों की एक मनमानी संख्या हो सकती है, जो एक पदानुक्रम बनाती है।
  • एक MIB कई अनुप्रयोगों के साथ संवाद कर सकता है।
  • इंस्ट्रूमेंटेशन किसी एप्लिकेशन के साथ संवाद करने के लिए डिस्ट्रिब्यूटेड एरलैंग का उपयोग कर सकता है।

अधिकांश अनुप्रयोगों को केवल मास्टर एजेंट की आवश्यकता होती है क्योंकि एक एजेंट एक ही समय में कई MIBs लोड कर सकता है।

2.4 उप-एजेंट और एमआईबी लोड हो रहा है

चूंकि अनुप्रयोग क्षणिक होते हैं (वे गतिशील रूप से लोड और अनलोड होते हैं), इन अनुप्रयोगों का प्रबंधन भी गतिशील होना चाहिए। उदाहरण के लिए, यदि हमारे पास रैक के लिए एक उपकरण MIB और बोर्डों के लिए अलग-अलग MIB हैं, जिसे रैक में स्थापित किया जा सकता है, कार्ड डालने पर MIB को लोड किया जाना चाहिए और कार्ड हटाए जाने पर उतार दिया जाए।

इस एजेंट प्रणाली में, प्रबंधन जानकारी को गतिशील रूप से स्थापित करने के दो तरीके हैं। एक एजेंट में MIB को लोड करने का सबसे आम तरीका है। दूसरा तरीका उप-एजेंट का उपयोग करना है, जो एप्लिकेशन द्वारा नियंत्रित किया जाता है और खुद को पंजीकृत करने और अपंजीकृत करने में सक्षम है। एक उप-एजेंट एक उप-वृक्ष के प्रबंधन के लिए खुद को पंजीकृत कर सकता है ( erlang:register साथ मिश्रित नहीं होना चाहिए erlang:register )। उप-ट्री की पहचान ऑब्जेक्ट आइडेंटिफ़ायर द्वारा की जाती है। जब एक उप-एजेंट पंजीकृत होता है, तो उसे इस विशेष उप-पेड़ के लिए सभी अनुरोध प्राप्त होते हैं और यह उनके जवाब देने के लिए जिम्मेदार होता है। यह भी ध्यान दिया जाना चाहिए कि किसी भी समय एक उप-एजेंट को शुरू और बंद किया जा सकता है।

अन्य एसएनएमपी एजेंट पैकेजों की तुलना में, उप-एजेंटों का उपयोग करने के इस तरीके में एक महत्वपूर्ण अंतर है। अन्य पैकेज सामान्य रूप से रन-टाइम में MIBs को लोड और अनलोड करने के लिए उप-एजेंटों का उपयोग करते हैं। Erlang में, रन-टाइम में कोड लोड करना आसान है और एक MIB को मौजूदा सब-एजेंट में लोड करना संभव है। नए MIB को संभालने के लिए एक नई प्रक्रिया बनाना आवश्यक नहीं है।

उप-एजेंटों का उपयोग निम्नलिखित कारणों से किया जाता है:

  • मास्टर एजेंट की तुलना में अधिक जटिल सेट-लेन-देन योजना प्रदान करना
  • अनावश्यक प्रक्रिया संचार से बचने के लिए
  • रन-टाइम में MIB को लोड करने और उतारने के लिए एक अधिक हल्का तंत्र प्रदान करने के लिए
  • अन्य SNMP एजेंट टूलकिट के साथ बातचीत प्रदान करने के लिए।

इन विषयों के बारे में अधिक जानकारी के लिए इस यूजर गाइड में अध्याय Advanced Agent Topics संदर्भ लें।

उप-एजेंटों के बीच संचार प्रोटोकॉल गुजरता हुआ सामान्य संदेश है जो वितरित एर्लांग सिस्टम में उपयोग किया जाता है। इसका तात्पर्य यह है कि SMUX, DPI, AgentX और इसी तरह के प्रोटोकॉल की तुलना में सब-एजेंट संचार बहुत कुशल है।

2.5 प्रसंग और समुदाय

एक संदर्भ एक SNMP इकाई द्वारा सुलभ प्रबंधन जानकारी का एक संग्रह है। एक प्रबंधन वस्तु का एक उदाहरण एक से अधिक संदर्भों में मौजूद हो सकता है। एक SNMP इकाई संभावित रूप से कई संदर्भों तक पहुंच रखती है।

प्रत्येक प्रबंधित ऑब्जेक्ट SNMP इकाई के भीतर कई उदाहरणों में मौजूद हो सकता है। MIB मॉड्यूल द्वारा निर्दिष्ट उदाहरणों की पहचान करने के लिए, वास्तविक उदाहरण को उसके 'स्कोप' या संदर्भ द्वारा अलग करने की विधि का उपयोग किया जाता है। अक्सर संदर्भ एक भौतिक या एक तार्किक उपकरण है। इसमें कई डिवाइस शामिल हो सकते हैं, एक डिवाइस का एक सबसेट या कई डिवाइस का एक सबसेट हो सकता है, लेकिन संदर्भ को हमेशा एक सिंगल एसएनएमपी इकाई के सबसेट के रूप में परिभाषित किया जाता है। एक SNMP इकाई के भीतर प्रबंधन की जानकारी के एक विशिष्ट आइटम की पहचान करने में सक्षम होने के लिए, संदर्भ, ऑब्जेक्ट प्रकार और उसके उदाहरण का उपयोग किया जाना चाहिए।

उदाहरण के लिए, प्रबंधित ऑब्जेक्ट प्रकार ifDescr से, एक नेटवर्क इंटरफ़ेस के विवरण के रूप में परिभाषित किया गया है। डिवाइस-एक्स के पहले नेटवर्क इंटरफेस के विवरण की पहचान करने के लिए, जानकारी के चार टुकड़ों की आवश्यकता होती है: एसएनएमपी इकाई का स्नैम्पवाइनिड, जो डिवाइस-एक्स, contextName (डिवाइस-एक्स), प्रबंधित ऑब्जेक्ट प्रकार पर प्रबंधन जानकारी तक पहुंच प्रदान करता है; ifDescr ), और उदाहरण ("1")।

SNMPv1 और SNMPv2c में, संदेश में समुदाय स्ट्रिंग का उपयोग तीन अलग-अलग उद्देश्यों के लिए किया गया था:

  • संदर्भ की पहचान करने के लिए

  • प्रमाणीकरण प्रदान करने के लिए

  • जाल लक्ष्य का एक सेट की पहचान करने के लिए

एसएनएमपीवी 3 में, इन उपयोग क्षेत्रों में से प्रत्येक का अपना अनूठा तंत्र है। एक संदर्भ एसएनएमपी इकाई के नाम से जाना जाता है, contextEngineID , और संदर्भ का नाम, contextName । प्रत्येक SNMPv3 संदेश में इन दो मापदंडों के लिए मान शामिल हैं।

एक MIB, SNMP-COMMUNITY-MIB है, जो एक कम्युनिटी स्ट्रिंग को एक contextEngineID और contextName । इस प्रकार, प्रत्येक संदेश, एक SNMPv1, SNMPv2c या एक SNMPv3 संदेश, हमेशा विशिष्ट रूप से एक संदर्भ की पहचान करता है।

एक एजेंट के लिए, एक प्राप्त संदेश द्वारा पहचाने जाने वाले contextEngineID , हमेशा एजेंट के snmpEngineID के बराबर होता है। अन्यथा, संदेश एजेंट के लिए अभिप्रेत नहीं था। यदि एजेंट को एक से अधिक संदर्भों के साथ कॉन्फ़िगर किया गया है, तो इंस्ट्रूमेंटेशन कोड यह पता लगाने में सक्षम होना चाहिए कि किस संदर्भ में अनुरोध किया गया था। एक फ़ंक्शन snmpa:current_context/0 इस उद्देश्य के लिए snmpa:current_context/0 प्रदान किया गया है।

डिफ़ॉल्ट रूप से, एजेंट को डिफ़ॉल्ट संदर्भ, "" अलावा किसी अन्य संदर्भ का कोई ज्ञान नहीं है। यदि यह अधिक संदर्भों का समर्थन करने के लिए है, तो इन्हें उचित कॉन्फ़िगरेशन फ़ाइल Agent Configuration Files का उपयोग करके स्पष्ट रूप से जोड़ा जाना चाहिए।

2.6 एजेंट का प्रबंधन

मानक MIB का एक सेट होता है, जिसका उपयोग SNMP एजेंट को नियंत्रित और कॉन्फ़िगर करने के लिए किया जाता है। ये सभी MIB, वैकल्पिक SNMP-PROXY-MIB (जो केवल प्रॉक्सी एजेंटों के लिए उपयोग किया जाता है) के अपवाद के साथ, इस एजेंट में लागू होते हैं। इसके अलावा, यह कॉन्फ़िगर करने योग्य है कि इनमें से कौन सा एमआईबी वास्तव में लोड किया गया है, और इस प्रकार एसएनएमपी प्रबंधकों को दिखाई देता है। उदाहरण के लिए, एक गैर-सुरक्षित वातावरण में, एमआईबी को नहीं बनाना एक अच्छा विचार हो सकता है जो एक्सेस कंट्रोल को परिभाषित करता है। ध्यान दें, MIBs परिभाषित डेटा का उपयोग आंतरिक रूप से एजेंट में किया जाता है, भले ही MIBs लोड न हों। इस अध्याय में इन मानक MIB और उनके कार्यान्वयन के कुछ पहलुओं का वर्णन किया गया है।

किसी भी SNMP एजेंट को MIB-II में परिभाषित system समूह और snmp समूह को लागू करना चाहिए। इन समूहों की परिभाषा SNMPv1 से SNMPv2 में बदल गई है। वितरण में इन दोनों संस्करणों के लिए MIB और कार्यान्वयन प्रदान किए जाते हैं। SNMPv1 के लिए MIB फ़ाइल को STANDARD-MIB कहा जाता है, और SNMPv2 के लिए इसी को SNMPv2-MIB कहा जाता है। यदि एजेंट केवल SNMPv1 के लिए कॉन्फ़िगर किया गया है, तो STANDARD-MIB को डिफ़ॉल्ट रूप से लोड किया गया है; अन्यथा, SNMPv2-MIB डिफ़ॉल्ट रूप से लोड किया गया है। इस डिफ़ॉल्ट व्यवहार को ओवरराइड करना संभव है, इस एमआईबी के दूसरे संस्करण को स्पष्ट रूप से लोड करके, आप इन दो एमआईबी में सभी वस्तुओं के संघ को लागू करने का विकल्प चुन सकते हैं।

SNMPv3 एजेंट को SNMP-FRAMEWORK-MIB और SNMP-MPD-MIB को लागू करना चाहिए। यदि एजेंट SNMPv3 के लिए कॉन्फ़िगर किया गया है, तो ये MIB डिफ़ॉल्ट रूप से लोड किए जाते हैं। इन MIB को अन्य संस्करणों के लिए भी लोड किया जा सकता है।

पाँच अन्य मानक MIB हैं, जिन्हें एजेंट में भी लोड किया जा सकता है। ये MIB हैं:

  • SNMP-TARGET-MIB और SNMP-NOTIBATION-MIB, जो प्रबंधन लक्ष्य के विन्यास के लिए प्रबंधित वस्तुओं को परिभाषित करता है, अर्थात सूचनाओं (रसीदों और सूचनाओं) के रिसीवर। इन MIB का उपयोग किसी भी SNMP संस्करण के साथ किया जा सकता है।

  • SNMP-VIEW-BASED-ACM-MIB, जिसने अभिगम नियंत्रण के लिए प्रबंधित वस्तुओं को परिभाषित किया। इस MIB का उपयोग किसी भी SNMP संस्करण के साथ किया जा सकता है।

  • SNMP-COMMUNITY-MIB, जो SNMPv1 और SNMPv2c के सह-अस्तित्व के लिए SNMPv3 के साथ प्रबंधित वस्तुओं को परिभाषित करता है। यह MIB केवल तभी उपयोगी है जब SNMPv1 या SNMPv2c का उपयोग किया जाता है, संभवतः SNMPv3 के साथ संयोजन में।

  • SNMP-USER-BASED-SM-MIB, जो प्रमाणीकरण और गोपनीयता के लिए प्रबंधित वस्तुओं को परिभाषित करता है। यह MIB केवल SNMPv3 के साथ उपयोगी है।

इन सभी MIB को मास्टर एजेंट में लोड किया जाना चाहिए। एक बार लोड होने के बाद, ये MIB हमेशा सभी संदर्भों में उपलब्ध हैं।

ASN.1 कोड, Erlang स्रोत कोड, और उनके लिए उत्पन्न .hrl फ़ाइलें वितरण में प्रदान की जाती हैं और इन्हें mibs include क्रमशः mibs , src , और include किया जाता है।

.hrl साथ .hrl फाइलें जनरेट की snmpc:mib_to_hrl/1 । अपने कोड में इन फ़ाइलों को निम्न उदाहरण में शामिल करें:

-include_lib("snmp/include/SNMPv2-MIB.hrl").

इन तालिकाओं में परिभाषित प्रबंधित ऑब्जेक्ट के लिए प्रारंभिक मान, कॉन्फ़िगरेशन फ़ाइलों के सेट से स्टार्ट-अप पर पढ़े जाते हैं। ये Configuration Files में वर्णित हैं।

मानक- MIB और SNMPv2-MIB

इन MIBs में MIB-II के स्नेप- और system समूह होते हैं जो RFC1213 (STANDARD-MIB) या RFC1907 (SNMPv2-MIB) में परिभाषित होते हैं। वे snmp_standard_mib मॉड्यूल में कार्यान्वित किए जाते हैं। snmpEnableAuthenTraps काउंटर सभी वाष्पशील मेमोरी और system में रहते हैं और एसएनएमपी बिल्ट-इन डेटाबेस (रेफरेंस मैनुअल, सेक्शन snmpa_local_db , मॉड्यूल snmpa_local_db को अधिक विवरण के लिए संदर्भित करते हुए) का उपयोग करते हुए निरंतर मेमोरी में system और snmpEnableAuthenTraps चर में रहते हैं।

यदि इनमें से किसी भी चर का एक और कार्यान्वयन आवश्यक है, उदाहरण के लिए एक Mnesia डेटाबेस में लगातार चर स्टोर करने के लिए, चर का एक ही कार्यान्वयन किया जाना चाहिए। उस MIB को डिफ़ॉल्ट MIB के बजाय संकलित और लोड किया जाएगा। नए संकलित MIB का मूल MIB (यानी STANDARD-MIB या SNMPv2-MIB) के समान नाम होना चाहिए, और SNMP कॉन्फ़िगरेशन डायरेक्टरी ( Configuration Files देखें) में स्थित होना चाहिए।

इनमें से एक MIB हमेशा लोड होता है। यदि केवल SNMPv1 का उपयोग किया जाता है, तो STANDARD-MIB को लोड किया जाता है, अन्यथा SNMPv2-MIB को लोड किया जाता है।

जानकारी का प्रकार

SNMPv2 में कुछ नए डेटा प्रकार हैं जो SNMPv1 में भी उपयोगी हैं। STANDARD-MIB में, तीन डेटा प्रकारों को परिभाषित किया गया है, RowStatus , TruthValue और DateAndTime । इन डेटा प्रकारों को मूल रूप से SNMPv2-TC (RFC1903) में शाब्दिक सम्मेलनों के रूप में परिभाषित किया गया है।

SNMP-FRAMEWORK-MIB और SNMP-MPD-MIB

SNMP-FRAMEWORK-MIB और SNMP-MPD-MIB अतिरिक्त रीड-ओनली प्रबंधित ऑब्जेक्ट्स को परिभाषित करते हैं, जिसका उपयोग RFC2271 में परिभाषित जेनेरिक SNMP फ्रेमवर्क और RFC2272 में जेनेरिक मैसेज प्रोसेसिंग और डिस्पैचिंग मॉड्यूल में किया जाता है। वे इस अर्थ में सामान्य हैं कि वे किसी विशिष्ट एसएनएमपी संस्करण से बंधे नहीं हैं।

इन snmp_framework_mib की वस्तुओं को क्रमशः snmp_framework_mib और snmp_standard_mib के मॉड्यूल में लागू किया जाता है। सभी ऑब्जेक्ट्स वाष्पशील मेमोरी में रहते हैं, और कॉन्फ़िगरेशन फ़ाइलें हमेशा स्टार्ट-अप पर फिर से व्यवस्थित होती हैं।

यदि SNMPv3 का उपयोग किया जाता है, तो ये MIB डिफ़ॉल्ट रूप से लोड होते हैं।

SNMP-TARGET-MIB और SNMP-NOTIFICATION-MIB

SNMP-TARGET-MIB और SNMP-NOTIFICATION-MIB अधिसूचना रिसीवर के विन्यास के लिए प्रबंधित वस्तुओं को परिभाषित करते हैं। उन्हें RFC2273 में विस्तार से वर्णित किया गया है। केवल एक संक्षिप्त विवरण यहां दिया गया है।

इन StorageType की सभी तालिकाओं में StorageType टाइप का एक कॉलम StorageType । इस कॉलम का मान निर्दिष्ट करता है कि प्रत्येक पंक्ति कैसे संग्रहीत की जाती है, और एजेंट के पुनरारंभ होने के मामले में क्या होता है। कार्यान्वयन मूल्यों का समर्थन करता है volatile और nonVolatile । जब तालिकाएँ प्रारंभ में कॉन्फ़िगरेशन फ़ाइलों के डेटा से भरी होती हैं, तो इन पंक्तियों में स्वचालित रूप से स्टोरेज टाइप nonVolatile - nonVolatile । क्या एजेंट को फिर से शुरू करना चाहिए, सभी nonVolatile volatile पंक्तियों को पुनरारंभ करने से बचे, जबकि volatile पंक्तियाँ खो जाती हैं। कॉन्फ़िगरेशन फ़ाइलों को डिफ़ॉल्ट रूप से पुनरारंभ पर नहीं पढ़ा जाता है।

ये MIB डिफ़ॉल्ट रूप से लोड नहीं होते हैं।

snmpNotifyTable

snmpNotifyTable में एक प्रविष्टि प्रबंधन लक्ष्यों का एक सेट का चयन करती है, जिसे सूचना प्राप्त करनी चाहिए, साथ ही अधिसूचना का प्रकार (जाल या सूचना) जिसे प्रत्येक चयनित प्रबंधन लक्ष्य को भेजा जाना चाहिए। जब कोई एप्लिकेशन फ़ंक्शन send_trap send_notification/5 या फ़ंक्शन send_trap पैरामीटर का उपयोग करके एक अधिसूचना भेजता है, तो निर्दिष्ट NotifyName , कॉल में एक सूचकांक के रूप में उपयोग किया जाता है। अधिसूचना उस प्रविष्टि द्वारा चयनित प्रबंधन लक्ष्यों को भेजी जाती है।

snmpTargetAddrTable

snmpTargetAddrTable में एक प्रविष्टि प्रत्येक प्रबंधन लक्ष्य के लिए परिवहन पैरामीटर (जैसे IP पता और UDP पोर्ट) को परिभाषित करती है। snmpNotifyTable में प्रत्येक पंक्ति snmpNotifyTable में संभावित रूप से कई पंक्तियों को संदर्भित snmpTargetAddrTable snmpTargetAddrTable में प्रत्येक पंक्ति snmpTargetAddrTable में एक प्रविष्टि को संदर्भित snmpTargetParamsTable

snmpTargetParamsTable

snmpTargetParamsTable में एक प्रविष्टि जो SNMP संस्करण का उपयोग करने के लिए परिभाषित करता है, और जो सुरक्षा मापदंडों का उपयोग करता है।

एसएनएमपी संस्करण का उपयोग करने के लिए संदेश प्रसंस्करण मॉडल को निर्दिष्ट करके स्पष्ट रूप से परिभाषित किया गया है। एजेंट का यह संस्करण मॉडल v1 , v2c और v3 संभालता है।

प्रत्येक पंक्ति निर्दिष्ट करती है कि सुरक्षा स्तर और सुरक्षा मापदंडों के साथ कौन से सुरक्षा मॉडल का उपयोग करना है।

SNMP-दृश्य-आधारित-ACM-एमआईबी

SNMP-VIEW-BASED-ACM-MIB प्रबंधकों के लिए प्रबंधित ऑब्जेक्ट तक पहुंच को नियंत्रित करने के लिए प्रबंधित ऑब्जेक्ट्स को परिभाषित करता है। व्यू आधारित एक्सेस कंट्रोल मॉड्यूल (VACM) का उपयोग किसी भी SNMP संस्करण के साथ किया जा सकता है। हालाँकि, यदि इसे SNMPv1 या SNMPv2c के साथ प्रयोग किया जाता है, तो SNMP-COMMUNITY-MIB अतिरिक्त वस्तुओं को VACM मापदंडों के लिए समुदाय स्ट्रिंग को परिभाषित करता है।

इस MIB की सभी तालिकाओं में StorageType का एक कॉलम StorageType । इस कॉलम का मान निर्दिष्ट करता है कि प्रत्येक पंक्ति कैसे संग्रहीत की जाती है, और एजेंट के पुनरारंभ होने के मामले में क्या होता है। कार्यान्वयन मूल्यों का समर्थन करता है volatile और nonVolatile । जब तालिकाएँ प्रारंभ में कॉन्फ़िगरेशन फ़ाइलों के डेटा से भरी होती हैं, तो इन पंक्तियों में स्वचालित रूप से स्टोरेज टाइप nonVolatile - nonVolatile । क्या एजेंट को फिर से शुरू करना चाहिए, सभी nonVolatile volatile पंक्तियों को पुनरारंभ करने से बचे, जबकि volatile पंक्तियाँ खो जाती हैं। कॉन्फ़िगरेशन फ़ाइलें डिफ़ॉल्ट रूप से पुनरारंभ पर नहीं पढ़ी जाती हैं।

यह MIB डिफ़ॉल्ट रूप से लोड नहीं है।

VACM RFC2275 में विस्तार से वर्णित है। यहाँ केवल एक संक्षिप्त विवरण दिया गया है।

मूल अवधारणा एक एमआईबी दृष्टिकोण की है । एक MIB दृश्य एक एजेंट द्वारा कार्यान्वित सभी वस्तुओं का एक सबसेट है। एक प्रबंधक के पास एक निश्चित MIB दृश्य तक पहुंच होती है, जिसके आधार पर सुरक्षा मापदंडों का उपयोग किया जाता है, जिसके संदर्भ में अनुरोध किया जाता है, और किस प्रकार का अनुरोध किया जाता है।

निम्न चित्र MIB दृश्य का चयन करने के लिए तंत्र का अवलोकन देता है:

चित्र 2.4: MIB चयन के तंत्र का अवलोकन

vacmContextTable

vacmContextTable एक रीड-ओनली टेबल है जो सभी उपलब्ध संदर्भों को सूचीबद्ध करती है।

vacmSecurityToGroupTable

vacmSecurityToGroupTable एक securityModel और एक vacmSecurityToGroupTable एक vacmSecurityToGroupTable मैप करता है।

vacmAccessTable

vacmAccessTable मैप्स vacmAccessTable ( vacmSecurityToGroupTable में पाया जाता है), contextName , securityModel , और प्रत्येक प्रकार के ऑपरेशन के लिए एक MIB दृश्य के लिए securityLevel (पढ़ें, लिखें या सूचित करें)। MIB दृश्य को एक viewName रूप में viewName । दृश्य नाम से दर्शाए गए MIB दृश्य की परिभाषा viewName में पाई vacmViewTreeFamilyTable

vacmViewTreeFamilyTable

vacmViewTreeFamilyTable द्वारा अनुक्रमित होता है, और परिभाषित करता है कि कौन से ऑब्जेक्ट MIB दृश्य में शामिल हैं।

तालिका के लिए MIB की परिभाषा इस प्रकार है:

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

INDEX { vacmViewTreeFamilyViewName,
        vacmViewTreeFamilySubtree
      }
        

प्रत्येक vacmViewTreeFamilyViewName उप-पेड़ों के संग्रह को संदर्भित करता है।

MIB देखें शब्दार्थ

एक MIB दृश्य उप-पेड़ों को शामिल और बहिष्कृत का एक संग्रह है। एक उप-वृक्ष की पहचान OBJECT IDENTIFIER द्वारा की जाती है। प्रत्येक उप-वृक्ष के साथ एक मुखौटा जुड़ा हुआ है।

प्रत्येक संभावित MIB ऑब्जेक्ट उदाहरण के लिए, उदाहरण उप-ट्री का है यदि:

  • उस MIB ऑब्जेक्ट उदाहरण के OJJECT IDENTIFIER नाम में कम से कम कई उप-पहचानकर्ता शामिल हैं जैसा कि उप-वृक्ष और
  • उस एमआईबी ऑब्जेक्ट उदाहरण के नाम से प्रत्येक उप-पहचानकर्ता उप-ट्री के संबंधित उप-पहचानकर्ता से मेल खाता है जब भी संबंधित मुखौटा का संबंधित बिट 1 (0 एक वाइल्ड कार्ड है जो कुछ भी मेल खाता है)।

MIB दृश्य में किसी ऑब्जेक्ट उदाहरण की सदस्यता निम्न एल्गोरिथम द्वारा निर्धारित की जाती है:

  • यदि कोई MIB ऑब्जेक्ट आवृत्ति संबंधित सब-ट्री से संबंधित नहीं है, तो वह उदाहरण MIB दृश्य में नहीं है।
  • यदि कोई MIB ऑब्जेक्ट उदाहरण बिल्कुल एक उप-ट्री के अंतर्गत आता है, तो वह उदाहरण उस प्रविष्टि के प्रकार के अनुसार प्रासंगिक MIB दृश्य को शामिल या इससे बाहर रखा गया है।
  • यदि कोई MIB ऑब्जेक्ट उदाहरण एक से अधिक उप-ट्री के अंतर्गत आता है, तो उप-ट्री जिसमें सबसे बड़ी संख्या में उप-पहचानकर्ता शामिल हैं, और लेक्सिकोग्राफ़िक रूप से सबसे बड़ा है, का उपयोग किया जाता है।
ध्यान दें

यदि OBJECT IDENTIFIER MIB में ऑब्जेक्ट प्रकार के OBJECT IDENTIFIER से अधिक है, तो यह ऑब्जेक्ट इंस्टेंस को संदर्भित करता है। इस वजह से, यह नियंत्रित करना संभव है कि किसी तालिका में विशेष पंक्तियाँ दिखाई देंगी या नहीं।

SNMP-समुदाय-एमआईबी

SNMP-COMMUNITY-MIB प्रबंधित वस्तुओं को परिभाषित करता है जो SNMPv1 और SNMPv2c के बीच SNMPv3 के बीच सह-अस्तित्व के लिए उपयोग किया जाता है। विशेष रूप से, इसमें सामुदायिक स्ट्रिंग्स और संस्करण-स्वतंत्र SNMP संदेश मापदंडों के बीच मानचित्रण के लिए ऑब्जेक्ट शामिल हैं। इसके अलावा, यह MIB आने वाले अनुरोधों पर स्रोत पते सत्यापन करने के लिए, और आने वाली सूचनाओं के लिए लक्ष्य पते के आधार पर सामुदायिक स्ट्रिंग्स का चयन करने के लिए एक तंत्र प्रदान करता है।

इस MIB की सभी तालिकाओं में StorageType का एक कॉलम StorageType । इस कॉलम का मान निर्दिष्ट करता है कि प्रत्येक पंक्ति कैसे संग्रहीत की जाती है, और एजेंट के पुनरारंभ होने के मामले में क्या होता है। कार्यान्वयन मूल्यों का समर्थन करता है volatile और nonVolatile । जब तालिकाएँ प्रारंभ में कॉन्फ़िगरेशन फ़ाइलों के डेटा से भरी होती हैं, तो इन पंक्तियों में स्वचालित रूप से स्टोरेज टाइप nonVolatile - nonVolatile । क्या एजेंट को फिर से शुरू करना चाहिए, सभी nonVolatile volatile पंक्तियों को पुनरारंभ करने से बचे, जबकि volatile पंक्तियाँ खो जाती हैं। कॉन्फ़िगरेशन फ़ाइलों को डिफ़ॉल्ट रूप से पुनरारंभ पर नहीं पढ़ा जाता है।

यह MIB डिफ़ॉल्ट रूप से लोड नहीं है।

SNMP-उपयोगकर्ता-आधारित-SM-एमआईबी

SNMP-USER-BASED-SM-MIB प्रबंधित ऑब्जेक्ट्स को परिभाषित करता है जो उपयोगकर्ता-आधारित सुरक्षा मॉडल के लिए उपयोग किया जाता है।

इस MIB की सभी तालिकाओं में StorageType का एक कॉलम StorageType । स्तंभ का मान निर्दिष्ट करता है कि प्रत्येक पंक्ति कैसे संग्रहीत की जाती है, और एजेंट के पुनरारंभ होने की स्थिति में क्या होता है। कार्यान्वयन मूल्यों का समर्थन करता है volatile और nonVolatile । जब तालिकाएँ प्रारंभ में कॉन्फ़िगरेशन फ़ाइलों के डेटा से भरी होती हैं, तो इन पंक्तियों में स्वचालित रूप से स्टोरेज टाइप nonVolatile - nonVolatile । क्या एजेंट को फिर से शुरू करना चाहिए, सभी nonVolatile volatile पंक्तियों को पुनरारंभ करने से बचे, जबकि volatile पंक्तियाँ खो जाती हैं। कॉन्फ़िगरेशन फ़ाइलों को डिफ़ॉल्ट रूप से पुनरारंभ पर नहीं पढ़ा जाता है।

यह MIB डिफ़ॉल्ट रूप से लोड नहीं है।

OTP-SNMPEA-एमआईबी

OTP-SNMPEA-MIB का उपयोग एजेंट के पुराने संस्करणों में किया गया था, इससे पहले कि मानक MIBs एक्सेस कंट्रोल, MIB दृश्यों और ट्रैप लक्ष्य विनिर्देशन के लिए मौजूद थे। इस MIB में सभी ऑब्जेक्ट अब अप्रचलित हैं।

2.7 सूचनाएं

सूचनाएँ MIB की परिभाषा में TRAP-TYPE मैक्रो के साथ SMIv1 में परिभाषित की गई हैं (RFC1215 देखें)। SMIv2 में संबंधित मैक्रो नोटिफ़िकेशन-टाइप है। जब कोई एप्लिकेशन एक अधिसूचना भेजने का फैसला करता है, तो यह निम्नलिखित कार्यों में से एक को कॉल करता है:

snmpa:send_notification(Agent, Notification, Receiver
                       [, NotifyName, ContextName, Varbinds])
snmpa:send_trap(Agent, Notification, Community [, Receiver, Varbinds])

उस एजेंट का पंजीकृत नाम या प्रक्रिया पहचानकर्ता प्रदान करना जहां सूचना को परिभाषित करने वाला MIB लोड किया गया हो और अधिसूचना का प्रतीकात्मक नाम।

यदि send_notification/3,4 फ़ंक्शन का उपयोग किया जाता है, तो सभी प्रबंधन लक्ष्य चुने जाते हैं, जैसा कि RFC2273 में परिभाषित किया गया है। Receiver पैरामीटर परिभाषित करता है जहां एजेंट को सूचित अनुरोधों के वितरण के बारे में जानकारी भेजनी चाहिए।

यदि NotifyName send_notification/5 फ़ंक्शन का उपयोग किया जाता है, तो एक NotifyName प्रदान किया जाना चाहिए। यह पैरामीटर snmpNotifyTable में एक सूचकांक के रूप में उपयोग किया जाता है, और उस एकल प्रविष्टि द्वारा परिभाषित प्रबंधन लक्ष्य का उपयोग किया जाता है।

send_notification/6 फ़ंक्शन फ़ंक्शन का सबसे सामान्य संस्करण है। एक ContextName निर्दिष्ट किया जाना चाहिए, जिसमें से अधिसूचना भेजी जाएगी। यदि यह पैरामीटर निर्दिष्ट नहीं है, तो डिफ़ॉल्ट संदर्भ ( "" ) का उपयोग किया जाता है।

फ़ंक्शन send_trap को पश्चगामी संगतता के लिए रखा गया है और इसे नए कोड में उपयोग नहीं किया जाना चाहिए। इस फ़ंक्शन का उपयोग करने वाले एप्लिकेशन काम करना जारी रखेंगे। जब कोई सूचना भेजी snmpNotifyName है तो snmpNotifyName को एजेंट द्वारा समुदाय स्ट्रिंग के रूप में उपयोग किया जाता है।

अधिसूचना भेजा जा रहा है

एक अधिसूचना भेजने का सबसे सरल तरीका है फ़ंक्शन snmpa:send_notification(Agent, Notification, no_receiver) को कॉल करना snmpa:send_notification(Agent, Notification, no_receiver) । इस स्थिति में, एजेंट नोटिफिकेशन स्पेसिफिकेशन (TRAP-TYPE या NOTIFICATION-TYPE मैक्रोज़ के साथ) में परिभाषित ऑब्जेक्ट वैल्यू को पुनः प्राप्त करने के लिए एक ऑपरेशन करता है। अधिसूचना को लक्षित और अधिसूचित तालिकाओं में परिभाषित सभी प्रबंधकों को भेजा जाता है, या तो जाल के रूप में अनजाने में, या सूचित अनुरोधों के रूप में स्वीकार किया जाता है।

यदि फ़ंक्शन का कॉलर यह जानना चाहता है कि किसी निश्चित अधिसूचना के लिए स्वीकृति प्राप्त है या नहीं (बशर्ते कि इसे एक सूचना के रूप में भेजा जाता है), तो Receiver पैरामीटर को {Tag, ProcessName} रूप में निर्दिष्ट किया जा सकता है (संदर्भ मैनुअल, अनुभाग {Tag, ProcessName} को देखें {Tag, ProcessName} , अधिक जानकारी के लिए मॉड्यूल snmp )। इस स्थिति में, एजेंट प्रत्येक संदेश {snmp_notification, Tag, {got_response, ManagerAddr}} लिए एक संदेश {snmp_notification, Tag, {got_response, ManagerAddr}} या {snmp_notification, Tag, {no_response, ManagerAddr}}

कभी-कभी अधिसूचना विनिर्देश में कुछ ऑब्जेक्ट के लिए मान प्राप्त करना संभव नहीं है, एक ऑपरेशन के साथ। हालाँकि, उन्हें तब जाना जाता है जब send_notification फ़ंक्शन कहा जाता है। यह मामला है यदि कोई वस्तु किसी तालिका में एक तत्व है। snmpa:send_notification(Agent, Notification, Receiver, Varbinds) function snmpa:send_notification(Agent, Notification, Receiver, Varbinds) को कुछ वस्तुओं का मान देना संभव है। इस समारोह में, Varbinds की एक सूची है, जहाँ प्रत्येक Varbind से एक है:

  • {Variable, Value} , जहां Variable अधिसूचना विनिर्देश में संदर्भित स्केलर चर का प्रतीकात्मक नाम है।
  • {Column, RowIndex, Value} , जहां Column कॉलम वैरिएबल का सांकेतिक नाम है। RowIndex निर्दिष्ट तत्व के लिए सूचकांक की एक सूची है। यदि यह स्थिति है, तो जाल में भेजा गया OBJECT IDENTIFIER टेबल कॉलम के लिए OBJECT IDENTIFIER में संलग्न RowIndex है। यह OBJECT IDENTIFIER है जो तत्व को निर्दिष्ट करता है।
  • {OID, Value} , जहां OID किसी ऑब्जेक्ट, स्केलर वैरिएबल या कॉलम वैरिएबल के उदाहरण के लिए OBJECT IDENTIFIER है।

उदाहरण के लिए, यह बताने के लिए कि sysLocation का मान "upstairs" होना चाहिए, हम इनमें से किसी एक का उपयोग कर सकते हैं:

  • {sysLocation, "upstairs"} या
  • {[1,3,6,1,2,1,1,6,0], "upstairs"}

अतिरिक्त चर के लिए नाम और मान निर्दिष्ट करना भी संभव है जिन्हें अधिसूचना में भेजा जाना चाहिए, लेकिन अधिसूचना विनिर्देश में परिभाषित नहीं किया गया था।

अधिसूचना तालिकाओं में पाए गए सभी प्रबंधन लक्ष्यों को भेजी जाती है। हालाँकि, सुनिश्चित करें कि प्रत्येक प्रबंधक के पास सूचना में चर तक पहुँच हो। यदि कोई चर प्रबंधक के MIB दृश्य के बाहर है, तो यह प्रबंधक सूचना प्राप्त नहीं करेगा।

ध्यान दें

परिभाषा के अनुसार, सूचनाओं में not-accessible वस्तुओं को भेजना संभव नहीं है। हालांकि, ऐतिहासिक रूप से यह अक्सर किया जाता है और इस कारण से हम इसे अधिसूचना भेजने में अनुमति देते हैं। यदि एक चर में पहुंच not-accessible , तो उपयोगकर्ता को Varbinds सूची में चर के लिए एक मूल्य प्रदान करना होगा। यह मान प्राप्त करने के लिए एजेंट के लिए एक ऑपरेशन प्राप्त करना संभव नहीं है।

अधिसूचना फ़िल्टर

एक एजेंट के लिए अधिसूचना फ़िल्टर जोड़ना संभव है। जब कोई नोटिफिकेशन भेजना हो तो ये फिल्टर कहलाएंगे। उनका उद्देश्य संशोधन, दमन या अन्य प्रकार के कार्यों की अनुमति देना है।

एक सूचना फ़िल्टर snmpa_notification_filter व्यवहार को लागू करने snmpa_notification_filter एक मॉड्यूल है। फ़ंक्शंस का उपयोग करके एक फ़िल्टर जोड़ा / हटा दिया जाता है: snmpa:register_notification_filter और snmpa:unregister_notification_filter

जब तक अन्यथा निर्दिष्ट नहीं किया जाता है, तब तक पंजीकृत फ़िल्टर का क्रम वह क्रम होगा जिसमें वे पंजीकृत हैं।

उप-एजेंट पथ

यदि किसी ऑब्जेक्ट का मान send_notification फ़ंक्शन को नहीं दिया गया है, तो उप-एजेंट इसे पुनर्प्राप्त करने के लिए एक गेट-ऑपरेशन करेगा। यदि ऑब्जेक्ट इस उप-एजेंट में लागू नहीं किया गया है, तो इसके मूल एजेंट इसे प्राप्त करने के लिए एक गेट-ऑपरेशन करने की कोशिश करते हैं। यदि ऑब्जेक्ट को इस एजेंट में लागू नहीं किया गया है, तो यह उसके माता-पिता के लिए ऑब्जेक्ट को आगे बढ़ाता है, और इसी तरह। आखिरकार मास्टर एजेंट पहुंच जाता है और इस बिंदु पर सभी अज्ञात ऑब्जेक्ट मानों को हल किया जाना चाहिए। यदि मास्टर एजेंट के लिए भी कुछ ऑब्जेक्ट अज्ञात है, तो इसे त्रुटि माना जाता है और user_err/2 त्रुटि रिपोर्ट मॉड्यूल के कॉल के साथ सूचित किया जाता है। इस मामले में कोई सूचना नहीं भेजी जाती है।

किसी दिए गए नोटिफिकेशन के लिए, चर, जिसे अधिसूचना विनिर्देश में संदर्भित किया गया है, को उस एजेंट द्वारा लागू किया जाना चाहिए जिसके पास MIB लोड है, या कुछ अभिभावक इस एजेंट के पास हैं। यदि नहीं, तो आवेदन को अज्ञात चर के लिए मान प्रदान करना चाहिए। एप्लिकेशन को तालिकाओं में सभी तत्वों के लिए मान भी प्रदान करना चाहिए।

2.8 डिस्कवरी

इस है आधिकारिक पेलोड जो करता वाले संदेशों के लिए नहीं है (उदाहरण के SNMPv2-जाल, प्रतिक्रिया या रिपोर्ट PDU के लिए) एक प्रतिक्रिया की उम्मीद है।

रिसीवर है आधिकारिक पेलोड जो उम्मीद एक प्रतिक्रिया (उदाहरण के लिए जाओ, GetNext, Get-थोक, सेट या सूचित PDU) वाले संदेशों के लिए।

एजेंट खोज करने के लिए प्रदर्शन और प्रतिक्रिया दोनों कर सकता है।

एजेंट उपयोगकर्ता द्वारा बातचीत किए बिना, स्वायत्त रूप से खोज करने के लिए प्रतिक्रिया करता है।

discovery फ़ंक्शन को कॉल करके प्रबंधक की ओर खोज शुरू करना। EngineId में लक्ष्य (प्रबंधक) प्रविष्टि के क्षेत्र target_addr.conf फ़ाइल मूल्य होना आवश्यक है discovery । ध्यान दें कि यदि प्रबंधक जवाब नहीं देता है, Timeout और RetryCount फ़ील्ड यह तय करती है कि लौटने से पहले फ़ंक्शन कितनी देर तक लटका रहेगा।

डिस्कवरी केवल एक समय में एक प्रबंधक की ओर किया जा सकता है।

Original text