Jaką klasyfikację QoS należy zastosować do NTP?

Referencyjne rozwiązanie Cisco Enterprise QoS Network Design sugeruje klasyfikację NTP jako ruchu związanego z zarządzaniem siecią i oznaczenie go jako CS2:

Odpowiadając na potrzeby QoS związane z ruchem w ramach zarządzania siecią, Cisco zaleca następujące wytyczne:

Ruch związany z zarządzaniem siecią powinien być oznaczony jako DSCP CS2.

Aplikacje do zarządzania siecią powinny być wyraźnie chronione przy minimalnej gwarancji przepustowości.

Ruch związany z zarządzaniem siecią jest ważny dla przeprowadzenia analizy trendów i przepustowości oraz rozwiązywania problemów. W związku z tym można udostępnić osobną minimalną kolejkę przepustowości dla ruchu zarządzania siecią, która może obejmować SNMP, NTP , Syslog, NFS i inne aplikacje do zarządzania .

Biorąc pod uwagę, że NTP jest wrażliwy na fluktuacje, dlaczego NTP nie jest oznaczony jako przyspieszone przekazywanie i nie jest traktowany tak samo jak dane głosowe?

Czy istnieje powód, dla którego nie należy go umieszczać w tej samej kolejce o niskim opóźnieniu co głos?

cisco qos best-practices ntp Stephen Craven
źródło

Nie sądzę, by „wrażliwy na jitter” był uczciwą charakterystyką NTP. To wiele wyjaśnia, ale uważam, że algorytm i interwały odpytywania mogą poradzić sobie z pewną ilością fluktuacji. Doprowadziłoby mnie to do wniosku, że nie trzeba traktować tego samego jak głos. (Niewiele wiem o QoS.)

Craig Constantine

@CraigConstantine To prawda. W większości środowisk, o ile można uzyskać kolejkę do pokonania ruchu BE, prawdopodobnie i tak wyprzedzasz 95% danych.

Ryan Foley

@CraigConstantine spojrzeć na RFP4594 Dobry połów Stephen. Myślę, że Cisco nie zgadza się z IETF w tej sprawie? ...

Ronnie Royston

Cisco to duża firma z wieloma różnymi osobami / grupami. Nie wszyscy z nich zawsze zgadzają się co do tego, co jest najlepsze. Osobiście uważam, że zalecenie IETF jest lepsze, jeśli chodzi o „taktowanie o wysokiej dokładności”, ale osobiście nie chciałbym, aby NTP dla mojego sprzętu sieciowego (którego ogólnie nie klasyfikowałbym jako o wysokiej dokładności) to „taktowanie zegara ściennego” lub DF, jak to ujmuje RFC. Wydaje się, że zalecenie Cisco jest bardziej „na środku drogi” i zgodnie z tym, czego oczekiwałbym, zaspokoi ogólne potrzeby NTP w zakresie sprzętu sieciowego.

YLearn

@StevenCraven, aby było to pytanie, na które można odpowiedzieć, musimy zrozumieć, jakie wymagania dotyczące precyzji masz względem NTP i jak jest on wykorzystywany.

Mike Pennington

Odpowiedzi:

Edytowana odpowiedź: NTP należy umieścić w klasie EF (tak samo jak pakiety głosowe w czasie rzeczywistym) zgodnie z wytycznymi konfiguracji IFCF RFC 4594 dla klas usług DiffServ .

5.2 Mapowanie dla NTP

Z przeprowadzonych testów wynika, że dokładny rozkład czasu wymaga bardzo małego transportu zmienności opóźnienia (fluktuacji). Dlatego sugerujemy stosowanie następujących wytycznych dla Network Time Protocol (NTP):

o Gdy NTP jest używany do zapewnienia bardzo dokładnego pomiaru czasu w sieci administratora (operatora) lub użytkownikom końcowym / klientom, należy użyć klasy usługi telefonii , a pakiety NTP powinny być oznaczone wartością EF DSCP.

o W przypadku aplikacji wymagających dokładności taktowania „zegara ściennego” należy zastosować Standardową klasę usług, a pakiety należy oznaczyć DF DSCP.

Ronnie Royston
źródło

poprawione powyżej

Ronnie Royston

NTP nie jest szczególnie wrażliwy na jitter, ponieważ wykorzystuje originatei transmitznaczniki czasu do śledzenia opóźnień. Ntp.org szczegółowo wyjaśnia, w jaki sposób utrzymuje opóźnienie w ryzach , ale oto fragment:

Synchronizacja klienta z serwerem sieciowym składa się z kilku wymian pakietów, przy czym każda z nich to para żądań i odpowiedzi. Podczas wysyłania żądania klient przechowuje swój czas (źródłowy znacznik czasu) w wysyłanym pakiecie. Gdy serwer odbierze taki pakiet, z kolei zapisze swój czas (znacznik czasu odbioru) w pakiecie, a pakiet zostanie zwrócony po umieszczeniu znacznika czasu transmisji w pakiecie. Po otrzymaniu odpowiedzi odbiorca ponownie zarejestruje swój własny czas odbioru, aby oszacować czas podróży pakietu. Czas podróży (opóźnienie) szacuje się na połowę „całkowitego opóźnienia minus czas zdalnego przetwarzania”, przy założeniu symetrycznych opóźnień.

Powodem, dla którego nie jest to ta sama kategoria co kontrola sieci, jest to, że nie jest to bezpośrednio odpowiedzialne za działanie routingu / przekazywania pakietów. Wszystkie elementy w kategorii zarządzania siecią nie są krytycznymi komponentami systemu sieciowego jako całości. Jeśli stracisz jakiekolwiek pakiety związane z SNMP, syslog lub NTP, prawdopodobnie nawet tego nie zauważysz.

SNMP po prostu retransmituje te informacje, ponieważ są one oparte na TCP. Nawet jeśli połączenie się rozpadnie, nic katastrofalnego się nie wydarzy; może się okazać, że agent snmp nie odpowiada, a następnie spróbuj ponownie. Jeśli utracisz ruch syslog (UDP), po prostu stracisz kupkę informacji rejestrowania, które prawdopodobnie nadal są zawarte w buforze lub w pliku dziennika na urządzeniu. Ponieważ NTP oblicza opóźnienie na podstawie poprzednich pakietów, a jednocześnie uwzględnia błąd maksymalnego przesunięcia, tak naprawdę nie występują problemy. W najgorszym przypadku Twój czas płynie o kilka pikosekund…

Jeśli straciłeś pakiet związany z routingiem, nawet na sekundę, być może czekasz na awarię całego systemu; czyniąc wszelkie inne oznaczenia bezwartościowymi. W tym momencie NTP po prostu całkowicie się nie zsynchronizuje i będzie polegać na swoim lokalnym tikerze, aby zachować czas.

Ryan Foley
źródło