up रिपोर्ट करणारा pseudowire तुम्हाला सांगतो की सेवा अस्तित्वात आहे आणि दोन्ही दिशा सहमत आहेत की तिने ट्राफिक वाहून नेले पाहिजे. पण तो सांगत नाही की एकही ग्राहक फ्रेम कधीही त्यातून गेली आहे. स्थिती ऑब्जेक्ट आणि काउंटर ऑब्जेक्ट वेगवेगळ्या उद्देशांसाठी लिहिले गेले होते, आणि एकाला दुसऱ्याचा पुरावा मानणे हेच या डॅशबोर्डमधील बहुतेक चुका होतात ते ठिकाण. त्यांची तुलना करणे हेच काम आहे, कारण कोणत्याही एकावर विश्वास ठेवणे हे कोणीही न विचारलेल्या प्रश्नाचे उत्तर देते.

स्थिती आणि काउंटर वेगवेगळ्या प्रश्नांची उत्तरे देतात

मुख्य VC नोंद संयुक्त ऑपरेशनल स्थिती धारण करते, आणि ती स्थिती दोन्ही दिशांच्या स्थिती up असतानाच up असते. त्यामागील सर्व काही कंट्रोल-प्लेन आणि कॉन्फिगरेशनचे ज्ञान आहे: स्थानिक अटॅचमेंट सर्किट, पीअर, सिग्नलिंग. या स्थितीतील ओळ हे हेतू आणि तयारीबद्दलचे विधान आहे, फॉर्वर्ड केलेल्या फ्रेमबद्दल नाही.

ट्राफिक पॅकेट आणि बाइटसाठी उच्च-क्षमतेच्या काउंटरच्या वेगळ्या तक्त्यात राहते, आणि त्या ओळी तोच VC इंडेक्स धारण करतात. तिथली वाढ हा पुरावा आहे की तुम्ही मोजलेल्या अंतराने फ्रेम त्या विशिष्ट ओळीतून गेल्या. अपरिवर्तित काउंटर स्वतःच अस्पष्ट असतो. निष्क्रिय सेवा, चुकीची ओळ वाचणारा कलेक्टर आणि शांतपणे तुटलेला मार्ग, सर्व एकच सपाट रेषा देतात.

QuestionObjectWhat it can establish
Is the service up?cpwVcOperStatusBoth direction states agree the VC should carry traffic.
Which side is down?cpwVcInboundOperStatus, cpwVcOutboundOperStatusDirection of the reported fault.
Did frames move?cpwVcPerfTotalTable HC countersObserved forwarding on that row between two polls.
Is the interval clean?cpwVcPerfTotalDiscontinuityTimeWhether the counter was reset inside the window.

तक्त्याला तीव्रतेची एक शिडी न मानता पुराव्याचे दोन स्तंभ म्हणून वाचा. सपाट काउंटरसह up असणे हे वाढीसह up असण्याची वाईट आवृत्ती नाही, ते वेगळ्या पुढील पावलासह वेगळे निरीक्षण आहे.

VC इंडेक्सवर जोडा, तिकिटातील क्रमांकावर नाही

VC तक्ता एका पूर्णांकाने इंडेक्स होतो, आणि VC ID, पीअर पत्ता, सेवा प्रकार व नाव या त्या ओळीच्या गुणधर्म आहेत. या गुणधर्मांनी तुम्ही तुमची सेवा शोधता; इंडेक्सने पहिल्या पोलनंतरही ती शोधत राहता. इंटरफेस इंडेक्स, दाखवलेले सर्किट नाव किंवा MPLS लेबल हा तो इंडेक्स नाही, अंक जुळले तरीही.

संख्यात्मक OID ब्लॉग पोस्टमधून नाही, कलेक्टरवरील MIB फाइलमधून काढा, नंतर तक्ता एकदा फिरा आणि सापडलेली ओळख जतन करा.

snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTable

व्यवस्थापन पत्ता आणि इंडेक्स एकत्रच देखरेख प्रणालीत नोंदवा. पुन्हा प्रोव्हिजनिंगमुळे सेवा दुसऱ्या ओळीत जाऊ शकते, आणि नावाने VC ID ला जोडलेला कलेक्टर तेव्हाही जुना इंडेक्स रेखाटत राहील जो अजूनही नम्रपणे उत्तर देतो.

दिशा म्हणजे pseudowire, ग्राहक नाही

इनबाउंड काउंटर सांगतात की VC ने पॅकेट-स्विच्ड नेटवर्ककडून काय घेतले; आउटबाउंड काउंटर सांगतात की त्याने त्या नेटवर्ककडे काय फॉर्वर्ड केले. ग्राहकाकडे तोंड असलेल्या PE वर हे बऱ्याचदा कोणत्या तरी क्रमाने डाउनलोड व अपलोडशी जुळते. हब PE वर, किंवा कोअरशी पीअरिंग करणाऱ्या PE वर, तीच ऑब्जेक्ट नावे उलटा ग्राहक अनुभव सांगतात.

प्रत्येक उपकरण भूमिकेसाठी मॅपिंग एकदा लिहा आणि ते डॅशबोर्ड लेबलात ठेवा. ग्राहक अपलोड असे शीर्षक असलेला आलेख जो प्रत्यक्षात कोअरकडे ट्राफिक रेखाटतो तो पुनरावलोकन पार करेल आणि क्षमता निर्णयांसाठी त्याचा वापर करणाऱ्या प्रत्येकाला शांतपणे दिशाभूल करेल. तोच धोका त्या आलेखांवर आधारित सूचनांनाही लागू होतो, कारण त्या चुकीच्या टीमला बोलावतील. प्रत्येक आलेख pseudowireच्या संदर्भातील हालचालीच्या दिशेने लेबल करा, आणि ग्राहक-मॅपिंगला त्याची गरज असलेल्या पॅनेलमध्येच राहू द्या.

एक चाचणी ऑब्जेक्ट वर्णने वाचण्याच्या कोणत्याही प्रमाणापेक्षा वरचढ आहे: ज्ञात फाइल सेवेतून गुजरवा, लगेच नंतर दोन्ही दिशा पोल करा, आणि कोणता काउंटर हलला ते पहा. निकाल उपकरण भूमिकेजवळ नोंदवा, कारण पुढची व्यक्ती तोच प्रश्न विचारेल.

दर केवळ एका अखंडता-भंग खिडकीतच वैध असतो

बाइट काउंटरची वाढ गेलेल्या सेकंदांनी भागून दर काढा, आणि सेकंदाला बिटसाठी आठने गुणा. काउंटर घटला, एजंट पुन्हा सुरू झाला, ओळ बदलली किंवा अखंडता-भंग ऑब्जेक्ट हलला, तर अंतराल अवैध माना. तो ऑब्जेक्ट प्रणालीच्या अपटाइमच्या संदर्भात व्यक्त होतो, त्यामुळे उपकरण पुन्हा सुरू झाल्यासही तो अवैध होतो. स्पाइक रेखाटण्याऐवजी नमुना सोडून नवीन खिडकी उघडा.

ज्ञात अंतराने दोन नमुने घ्या आणि टाइमस्टॅम्प कलेक्टरकडून ठेवा, तुमच्या टर्मिनल इतिहासातून नाही.

snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7

उच्च-क्षमतेचे काउंटर एका pseudowireवर रॅपिंगला प्रश्न न राहू देतात, म्हणून घट म्हणजे जवळजवळ नेहमी रीसेट, बदललेला एजंट किंवा वेगळी ओळ, अंकगणितीय ओव्हरफ्लो नाही. म्हणूनच तिसरा आदेश पहिल्या दोनाइतकाच महत्त्वाचा आहे.

स्थापित आवृत्ती प्रत्यक्षात काय समर्थन देते ते तपासा

MIB व्याख्या ही एक तपशील आहे, तुमच्या इमेजबद्दलचे वचन नाही. तक्ते अनुपस्थित असू शकतात, अंशतः अंमलात असू शकतात, किंवा वैशिष्ट्य सक्रिय होईपर्यंत उपस्थित पण न भरलेले असू शकतात, आणि तेच प्लॅटफॉर्म आवृत्त्यांमध्ये वेगळे असू शकते. CISCO-IETF-PW-MIB व्याख्या तुम्हाला ऑब्जेक्ट नावे देते; ती उत्तर देतात का हे उपकरण सांगते.

दोन्ही तक्ते आणि फर्मवेअर स्ट्रिंग एकाच पासमध्ये पोल करा, नंतर रिलीज नोटच्या दाव्याशी तुलना करा.

snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -l

रिकामी वॉक आणि असमर्थित वॉक वेगवेगळ्या अपयशी आहेत, म्हणून केवळ ओळींची गणना नाही, त्रुटी वाचा. स्थिती तक्ता उत्तर देतो आणि कार्यक्षमता तक्ता देत नाही, तर पहिल्या विभागात रचलेल्या जोडणीला उतरण्याची जागा नाही, आणि सुधारणा सर्किट बदल नाही, कलेक्टर बदल आहे.

वादग्रस्त सर्किटसाठी क्रम लहान आहे: इंडेक्सवरून ओळीची ओळख पटवा, एका ज्ञात हस्तांतरणाने दिशा-मॅपिंग पटवा, स्वच्छ अखंडता-भंग खिडकीतच दर मोजा, आणि त्या आवृत्तीवर दोन्ही तक्ते उत्तर देतात याची खात्री करा. प्रत्येक पाऊल एक संभाव्य स्पष्टीकरण काढून टाकते. चारही लागू असताना काउंटर अजूनही हलत नसतील, तर पुरावा pseudowireपासून दूर निर्देश करतो. तिथेच अटॅचमेंट सर्किटवरील पॅकेट कॅप्चर आपली किंमत कमावते.

संबंधित लेख