Состояние pseudowire против счётчиков трафика: что доказывает доставку

Оперативное состояние говорит, что услуга настроена и работает; счётчики говорят, что кадры двигались. Свяжите оба по индексу VC и проверьте направление, разрыв непрерывности и поддержку MIB.

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 индексируется одним целым числом, а ID 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

Записывайте адрес управления и индекс вместе в систему мониторинга. Повторное развёртывание может перенести услугу в другую строку, и тогда сборщик, привязанный по имени к ID 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. Именно тогда захват пакетов на цепи присоединения оправдывает себя.

Похожие статьи