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 سے دور اشارہ کرتے ہیں۔ وہیں منسلکہ سرکٹ پر پیکٹ کیپچر اپنی قیمت کماتا ہے۔

متعلقہ مضامین