Какая классификация QoS должна применяться к NTP?

Проект эталонной сети Cisco Enterprise QoS Solution предлагает классифицировать 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 должны быть помечены значением EF DSCP.

o Для приложений, которые требуют точности синхронизации «настенных часов», следует использовать стандартный класс обслуживания, а пакеты должны быть помечены DF DSCP.

— Ронни Ройстон
источник

исправлено выше

— Ронни Ройстон

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

Синхронизация клиента с сетевым сервером состоит из нескольких обменов пакетами, где каждый обмен представляет собой пару запросов и ответов. При отправке запроса клиент сохраняет свое время (метку времени начала) в отправляемом пакете. Когда сервер принимает такой пакет, он, в свою очередь, сохраняет свое собственное время (временную метку получения) в пакете, и пакет будет возвращен после помещения временной метки передачи в пакет. При получении ответа получатель еще раз запишет свое время получения, чтобы оценить время прохождения пакета. Время в пути (задержка) оценивается как половина «общей задержки за вычетом времени удаленной обработки», при условии симметричных задержек.

Причина, по которой он не относится к той же категории, что и управление сетью, заключается в том, что он не несет прямой ответственности за операции маршрутизации / пересылки пакетов. Все вещи в категории управления сетью не являются критическими компонентами сетевой системы в целом. Если вы потеряли какие-либо пакеты, связанные с SNMP, syslog или NTP, вы, вероятно, даже не заметите.

SNMP просто передаст эту информацию, поскольку он основан на TCP. Даже если связь разорвется, ничего катастрофического не произойдет; вы можете просто получить агент snmp, который не отвечает, а затем попробовать еще раз. Если вы потеряете трафик системного журнала (UDP), вы просто потеряете информацию о журналировании, которая, вероятно, все еще содержится в буфере или в файле журнала на устройстве. Так как NTP вычисляет задержку на основе предыдущих пакетов, а также учитывает максимальную ошибку смещения, вы действительно не столкнетесь с какими-либо проблемами. В худшем случае ваше время смещается на несколько пикосекунд ...

Если вы потеряли пакет, связанный с маршрутизацией, хотя бы на секунду, вы можете столкнуться со сбоем всей системы; делая любые другие маркировки бесполезными. В этот момент NTP просто полностью потеряет синхронизацию и будет полагаться на свой локальный тикер, чтобы сохранить время.

— Райан Фоли
источник