Състояние на pseudowire срещу броячи на трафик: кое от двете доказва доставянето
Оперативното състояние казва, че услугата е конфигурирана и работи; броячите казват, че кадрите са се движили. Свържете двете по индекса на VC и проверете посока, прекъсване и поддръжка на MIB.
Съобщението, че даден pseudowire е в състояние up, ви казва, че услугата съществува и че двете посоки са съгласни, че тя трябва да пренася трафик. То не ви казва, че през нея някога е преминал дори един кадър на клиент. Обектите за състояние и обектите за броячи са писани за различни цели и именно в това да приемете едното за доказателство на другото се крие грешката на повечето такива табла. Сравняването им е самата работа, защото доверието в което и да е от тях поотделно отговаря на въпрос, който никой не е задавал.
Състоянието и броячите отговарят на различни въпроси
Основният запис на VC носи обобщен оперативен статус и този статус е up само когато и двете посоки са up. Всичко зад него е знание за равнището на управление и конфигурацията: локалната верига на прикачване, партньорът, сигнализацията. Редът в това състояние е твърдение за намерение и готовност, а не за препратени кадри.
Трафикът живее в отделна таблица с броячи с висок капацитет за пакети и байтове, а тези редове носят същия индекс на VC. Растежът там е доказателство, че кадрите са преминали през точно този ред в интервала, който сте измерили. Неизменният брояч сам по себе си е двусмислен. Неактивна услуга, колектор, който чете грешния ред, и тихо прекъснат път дават една и съща плоска линия.
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether 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 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. Точно тогава заснемането на пакети по веригата на прикачване си заслужава.