Najwyższy czas na zapoznanie się z Network Time Protocol!

NTP (Network Time Protocol) to jeden z wielu protokołów, które inżynierowie sieciowi traktują po macoszemu/z dystansem. Podobnie jak inne “maleństwa” (np. SNMP, ARP, VTP, DTP itp.) jest to stosunkowo prosty i mało skomplikowany protokół, któremu nie poświęca się dużo uwagi. Rola NTP w sieciach jest jednak niesamowicie istotna i jeśli nie wykorzystujesz tego protokołu w Twojej sieci to możesz mieć spore problemy!

Po co synchronizować czas?

Zanim porozmawiamy o NTP wyobraź sobie następującą sytuację: jako analityk sieciowy masz za zadanie znaleźć przyczynę problemów z backupem wirtualnych maszyn w zeszłą noc.

Część backupów odbyła się planowo i zakończyła sukcesem, natomiast ponad połowa z nich nie doszła do skutku.

Bierzesz się więc ochoczo za troubleshooting.

Zaglądasz w logi na firewallu, sprawdzasz je na switchach, po drodze wchodzisz na jakiś router. No tak, większość logów zdążyła się już w międzyczasie “przekręcić” bo od incydentu minęło zbyt dużo czasu. Nie martwisz się tym jednak bo masz skonfigurowany eksport logów na syslog server.

Wchodzisz zatem na syslog server, wydobywasz potrzebne logi, zaczynasz je ze sobą korelować i nagle dostrzegasz coś dziwnego. Logi ze switch’a dowodzą, że problemy z siecią miały miejsce o godzinie 3:16 w nocy, podczas gdy logi z firewalla wskazują, że o tej godzinie wszystko działało jak należy.

Logujesz się na oba te urządzenia po CLI, wydajesz komendę “show clock” (lub jej odpowiednik) i okazuje się, że na switchu masz ustawiony taki czas:

Switch# show clock
14:31:57.089 PST Tue Feb 10 2018

podczas gdy na firewall’u zegar wskazuje zupełnie co innego:

Firewall# show clock
12:18:32.071 UTC Tue Feb 10 2018

Zegary na obu urządzeniach są niezsynchronizowane! Jak w takiej sytuacji efektywnie troubleshootować? Pewnie ostatecznie uda się tego dokonać…

Nie zmienia to jednak faktu, że stracisz dużo czasu i jeszcze więcej nerwów żeby doprowadzić logi różnych urządzeń do zbieżności w taki sposób, aby jasno wskazywały one przebieg wydarzeń, które doprowadziły do incydentu.

Na co komu NTP?

NTP, jak sama nazwa wskazuje, ma coś wspólnego z czasem. Protokół ten jest odpowiedzialny za synchronizowanie zegarów na urządzeniach sieciowych.

Ale w sumie w jakim celu? Przecież możemy to zrobić ręcznie. Wchodzimy na jedno urządzenie i wydajemy komendę:

Switch(config)#clock set 14:12:00 12 nov 2018

Po czym szybko wchodzimy na drugie urządzenie i wydajemy tę samą komendę.

Problem rozwiązany? No nie do końca.

Dokładność

Zegary są nadal rozsynchronizowane w najlepszym wypadku o kilkaset milisekund. Może to nie być problemem gdy mamy do czynienia z troubleshootingiem mało złożonych incydentów. Niektóre awarie będą jednak generowały duże ilości logów w milisekundowych odstępach czasu i wtedy musimy mieć zegary zsynchronizowane co do milisekundy aby móc precyzyjnie odtworzyć kolejność wydarzeń.

Skalowalność

Wyobrażasz sobie ręczne konfigurowanie zegarów na kilku urządzeniach? A na dziesiątkach lub setkach? Nie jest to skalowalne. W sukurs przychodzi jednak NTP.

Funkcjonalność

Niektóre urządzenia wręcz nie będą w stanie funkcjonować poprawnie bez zsynchronizowanych zegarów! Miałem swego czasu do czynienia z klastrem dwóch serwerów DHCP, w których zegary były rozsynchronizowane o kilkanaście sekund. Powodowało to następującą anomalię – jeśli dany host uzyskał dzierżawę adresu IP z pierwszego serwera DHCP, to jeżeli poźniej żądanie odnowy dzierżawy trafiało do drugiego serwera DHCP, odmawiał on jej przedłużenia! W rezultacie karta sieciowa hosta przypisywała sobie adres autokonfiguracji (tzw. APIPA) i host nie był w stanie uzyskać łączności sieciowej.

Zasada działania NTP

Teraz gdy już wiemy po co nam NTP, przyjrzyjmy się bliżej jak ten protokół działa. NTP jest protokołem opartym o model klient – serwer. Oznacza to więc, że w typowym przypadku nasze urządzenia sieciowe będą pobierały czas z wyznaczonego przez nas serwera (lub serwerów) NTP.

W tym artykule będziemy się posługiwali następującą topologią:

NTP bazuje na koncepcji tzw. stratum. Stratum jest wartością z przedziału 0-15 określającą jak daleko dane urządzenia sieciowe znajduje się od wzorcowego źródła czasu (np. zegarów atomowych dla czasu UTC). Dla przykładu stratum 0 może oznaczać fizyczne zegary atomowe, a stratum 1 to będą serwery podłączone bezpośrednio do serwerów stratum 0. Serwer NTP, który będzie synchronizował czas z serwera stratum 1, sam będzie określany mianem stratum 2. 

Jeśli dane urządzenie sieciowe skonfigurujemy tak aby synchronizowało czas z wielu serwerów NTP, to zawsze najbardziej będzie preferowany serwer o najniższym stratum!

Dane urządzenie sieciowe może być nie tylko klientem NTP, ale również serwerem (podobnie jak w przypadku np. SNMP). W naszym scenariuszu możemy mieć więc do czynienia z następującą sytuacją:

• Zdalny Serwer NTP (stratum 1) podłączony jest bezpośrednio do zegara atomowego (stratum 0)
• Router (stratum 2) skonfigurowany jest jako serwer NTP synchronizujący czas ze Zdalnym Serwerem NTP (stratum 1)
• Lokalny Serwer NTP (stratum 2) również skonfigurowany jest jako serwer NTP synchronizujący czas ze Zdalnym Serwerem NTP (stratum 1)
• Switch (stratum 3) synchronizuje czas z Lokalnym Serwerem NTP (stratum 2)

Nie będziemy się tu dokładnie zagłębiać w sposób synchronizacji zegarów. Warto natomiast wiedzieć, że komunikaty NTP wymieniane są za pomocą segmentów UDP (co ma sens – zależy nam na jak najszybszym transporcie informacji o czasie między urządzeniami). Sam protokół NTP ma wbudowane mechanizmy pozwalające korygować np. opóźnienia różnych typów łącz co powoduje, że synchronizowany czas jest bardzo dokładny.

Konfiguracja NTP

NTP jest bardzo proste w konfiguracji. Przyjrzymy się tutaj konfiguracji na Routerze oraz na Switchu – zakładamy, że Lokalny Serwer NTP jest już zsynchornizowany ze Zdalnym Serwerem NTP. Przypomnijmy sobie topologię:

Konfiguracja na Routerze

Możemy wskazać serwer NTP używając adresu IP:

Router(config)#ntp server 216.239.35.4

lub nazwy FQDN, która następnie zostanie rozwiązana za pomocą DNS:

Router(config)#ntp server time.google.com

Stan synchronizacji możemy zweryfikować wydając komendę show ntp associations:

Router#show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
 ~216.239.35.4 .INIT.          16      ‐     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, ‐ outlyer, x falseticker, ~ configured

Tylda (~) przed adresem IP w outpucie powyżej oznacza, że zegar nie jest jeszcze zsynchronizowany. Możemy również zauważyć, że powoduje to ustawienie wartości stratum na 16.

Po chwili zegar powinien zostać zsynchronizowany:

Router#show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
 *216.239.35.4 .INIT.          2      ‐     64     0  0.000   0.000 16000.
 * sys.peer, # selected, + candidate, ‐ outlyer, x falseticker, ~ configured

Wskazuje na to gwiazdka (*) przed adresem IP, a stratum 2 informuje nas o odległości od referencyjnego źródła czasu.

Komenda show ntp status daje nam nieco więcej wglądu w stan synchronizacji:

Router#show ntp status
Clock is synchronized, stratum 2, reference is 216.239.35.4
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is D76513B4.66A4CDA6 (13:42:21.300 UTC Mon Nov 11 2018)
clock offset is ‐4.5678 msec, root delay is 12.38 msec
root dispersion is 5466.62 msec, peer dispersion is 6537.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is ‐0.000000018 s/s
system poll interval is 64, last update was 43 sec ago.

Konfiguracja na Switchu

Konfiguracja na Switchu przebiegnie bardzo podobnie – pokazuję ją tutaj po to by podkreślić różnicę w wartości stratum, którą zauważymy. W tym przypadku będziemy synchronizować czas z Lokalnego Serwera NTP (stratum 2).

Konfigurujemy zatem serwer NTP na Switchu:

Switch(config)#ntp server 10.1.0.250

Po chwili weryfikujemy stan synchronizacji, używając np. komendy show ntp status:

Switch#show ntp status

Clock is synchronized, stratum 3, reference is 10.1.0.250

nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is D76513B4.66A4CDA6 (13:44:32.200 UTC Mon Nov 11 2018)
[...]

Wszystko wygląda jak należy – mamy działające NTP.

Jak sam widzisz, NTP jest łatwe i przyjemne w użytkowaniu i konfiguracji. Jest to mały protokół, który pełni dużą rolę w troubleshootingu problemów sieciowych. Jeśli jeszcze nie używasz NTP to najwyższy czas aby zacząć!