Стан pseudowire проти лічильників трафіку: що доводить доставку

pseudowire, що повідомляє стан up, каже вам, що послуга існує і що обидва напрямки згодні з тим, що вона має передавати трафік. Але він не каже, що через нього коли-небудь пройшов хоч один кадр клієнта. Об'єкти стану й об'єкти лічильників писалися для різних цілей, і саме на тому, що одне беруть за доказ іншого, помиляється більшість таких панелей. Порівнювати їх і є роботою, бо довіра лише до одного з них відповідає на питання, якого ніхто не ставив.

Стан і лічильники відповідають на різні питання

Основний запис VC несе об'єднаний оперативний статус, і цей статус є up лише тоді, коли обидва напрямки в стані up. Усе за ним — це знання площини керування та конфігурації: локальне коло приєднання, партнер, сигналізація. Рядок у цьому стані — твердження про намір і готовність, а не про передані кадри.

Трафік живе в окремій таблиці високоємних лічильників пакетів і байтів, і ці рядки несуть той самий індекс VC. Зростання там — доказ того, що кадри проходили саме через цей рядок у виміряному інтервалі. Незмінний лічильник сам по собі неоднозначний. Простійна послуга, збирач, що читає не той рядок, і тихо розірваний шлях дають ту саму пласку лінію.

Читайте таблицю як два стовпці доказів, а не як одну драбину серйозності. 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. Саме тоді захоплення пакетів на колі приєднання виправдовує себе.