Яку класифікацію QoS слід застосувати до NTP?

Довідкова мережа дизайнерських рішень Cisco Enterprise QoS пропонує класифікувати NTP як трафік управління мережею та позначити його як CS2:

Задовольняючи потреби QoS у трафіку управління мережею, Cisco рекомендує такі вказівки:

Трафік управління мережею повинен бути позначений DSCP CS2.

Програми управління мережею повинні бути чітко захищені з мінімальною гарантією пропускної здатності.

Управління мережевим трафіком важливо для аналізу тенденцій та потенціалу та усунення несправностей. Отже, ви можете надати окрему чергу з мінімальною пропускною здатністю для трафіку управління мережею, яка може включати SNMP, NTP , Syslog, NFS та інші програми управління .

Зважаючи на те, що NTP чутливий до тремтіння, чому NTP не позначений як експедиційне пересилання та не трактується так само, як голосові дані?

Чи є причина, чому її не слід розміщувати в такій же низькій черзі затримки, що й голос?

— Стівен Крейвен
джерело

Я не думаю, що "чутливий до тремтіння" - це справедлива характеристика NTP. Це багато що пояснює, але я вважаю, що алгоритм та інтервали опитування можуть вирішувати певну кількість тремтіння. Тож це призведе до того, що я не думаю, що до цього не слід ставитися як до голосу. (Я про QoS я мало знаю.)

— Крейг Костянтин

@CraigConstantine Це правильно. У більшості середовищ, поки ви можете отримати чергу, щоб вибити BE-трафік, ви, мабуть, випередили 95% даних, так чи інакше.

— Райан Фолі

@CraigConstantine погляньте на RFP4594 Добрий улов Стівен. Я здогадуюсь, що Cisco не наближається до IETF на цьому? ...

— Ронні Ройстон

Cisco - велика компанія, що має безліч різних осіб / груп. Не всі вони завжди згодні з тим, що найкраще. Особисто я вважаю, що рекомендація IETF є кращою, якщо мова йде про "високу точність синхронізації", але я особисто не хотів би, щоб NTP для мого мережевого обладнання (яке я, як правило, не можна віднести до високої точності), було "тимчасовим синхронізацією" або DF, як вважає RFC. Рекомендація Cisco, здається, є більш "серединою дороги", і відповідно до того, що я б очікував, буде задовольняти загальні потреби NTP у мережевому обладнанні.

— YLearn

@StevenCraven, щоб це було відповідальним питанням, нам потрібно зрозуміти, які вимоги до точності щодо NTP і як він використовується.

— Майк Пеннінгтон

Відповіді:

Відредагована відповідь: NTP повинен бути розміщений у класі EF (такий же, як голосові пакети в режимі реального часу) відповідно до Правил конфігурації IETF RFC 4594 для класів обслуговування DiffServ .

5.2. Картографування для NTP

З проведених тестів вказується на те, що точний розподіл часу вимагає дуже низької зміни затримки пакетів (джиттера). Тому ми пропонуємо використовувати наступні вказівки щодо протоколу мережевого часу (NTP):

o Коли NTP використовується для забезпечення високої точності синхронізації в мережі адміністратора (оператора) або для кінцевих користувачів / клієнтів, слід використовувати клас обслуговування телефонії , а пакети NTP повинні бути позначені значенням DSCP EF.

o Для додатків, які вимагають точності синхронізації "настінний годинник", слід використовувати стандартний клас обслуговування, а пакети - маркувати DF DSCP.

— Ронні Ройстон
джерело

виправлено вище

— Ронні Ройстон

NTP не особливо чутливий до тремтіння, оскільки він використовує originateта transmitчасові позначки для відстеження затримки. Ntp.org докладно пояснює, як він тримає затримку в чеку , але ось фрагмент:

Синхронізація клієнта з мережевим сервером складається з декількох обмінів пакетів, де кожен обмін є парою запиту та відповіді. Відправляючи запит, клієнт зберігає власний час (початкова мітка часу) у відправляється пакет. Коли сервер отримує такий пакет, він, в свою чергу, зберігає свій власний час (отримує часову позначку) в пакет, і пакет буде повернутий після введення часової мітки передачі в пакет. Отримавши відповідь, одержувач ще раз запише власний час отримання для оцінки часу подорожі пакету. Час у дорозі (затримка) оцінюється вдвічі від "загальної затримки мінус час віддаленої обробки", якщо вважати симетричні затримки.

Причина, що це не в тій же категорії, що і мережеве управління, полягає в тому, що це не безпосередньо відповідає за роботу маршрутизації / переадресації пакетів. Усі речі, що належать до категорії управління мережею, не є критичними компонентами мережі в цілому. Якщо ви втратили будь-які пакети, пов'язані з SNMP, syslog або NTP, ви, ймовірно, навіть не помітите.

SNMP просто повторно передасть цю інформацію, оскільки вона базується на TCP. Навіть якби зв’язок перепав усі разом, нічого катастрофічного не трапиться; ви можете просто отримати агент snmp, який не відповідає, а потім спробувати ще раз. Якщо ви втратили трафік syslog (UDP), ви просто втратите інформацію про журнал, яка, ймовірно, все ще міститься в буфері або у файлі журналу на пристрої. Оскільки NTP обчислює затримку на основі попередніх пакетів, а також враховує максимальну помилку зміщення, ви насправді не стикаєтесь з жодними проблемами. Найгірший випадок, ваш час переміщується на кілька пікосекунд ...

Якщо ви втратили пакет, пов’язаний із маршрутизацією, навіть на секунду, можливо, ви зіткнетесь із тим, що вся система знизиться; що робить будь-які інші позначення марними. У цей момент NTP просто повністю випаде з синхронізації і покладається на його місцевий тикер, щоб зберегти час.

— Райан Фолі
джерело