یک pseudowire که وضعیت up را گزارش می‌کند به شما می‌گوید سرویس وجود دارد و هر دو جهت توافق دارند که باید ترافیک حمل کند. اما نمی‌گوید که حتی یک فریم مشتری هرگز از آن عبور کرده است. اشیای وضعیت و اشیای شمارنده برای مقاصد متفاوت نوشته شده‌اند و همین که یکی را شاهد دیگری بگیریم جایی است که بیشتر این داشبوردها اشتباه می‌کنند. مقایسهٔ آن دو کار اصلی است، چون اعتماد به هر یک به‌تنهایی به پرسشی پاسخ می‌دهد که هیچ‌کس نپرسیده است.

وضعیت و شمارنده‌ها به دو پرسش متفاوت پاسخ می‌دهند

ورودی اصلی 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، نشانی همتا، نوع و نام سرویس ویژگی‌های همان ردیف‌اند. با همین ویژگی‌ها سرویس خود را پیدا می‌کنید؛ شاخص چیزی است که با آن پس از نخستین بررسی هم آن را می‌یابید. شاخص رابط، نام مدار نمایش‌داده‌شده یا برچسب 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 پیوسته است همچنان شاخصی کهنه را رسم می‌کند که هنوز مؤدبانه پاسخ می‌دهد.

جهت به معنای 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 دور می‌شوند. همان‌جاست که گرفتن بسته روی مدار اتصال ارزش خود را ثابت می‌کند.

مقالات مرتبط