Więcej

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

    spot_img

    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ą:

    Topologia NTP używana w tym artykule
    Topologia NTP używana w tym artykule

    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)
    Wartości stratum w przykładowej topologii
    Wartości stratum w przykładowej topologii

    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ę:

    Topologia NTP używana w tym artykule
    Topologia NTP używana w tym artykule

    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ąć! W tym artykule świadomie nie poruszyłem zagadnień bezpieczeństwa i troubleshootingu NTP – powstanie o tym osobny materiał. Chciałem uniknąć pisania zbyt długiego artykułu. Stay tuned!

    A czy Ty miałeś kiedyś do czynienia z sytuacją, w której rozsynchronizowane zegary utrudniły lub uniemożliwiły troubleshooting? Podziel się w komentarzu swoim doświadczeniem!

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 4.5 / 5. Ilość głosów: 11

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Damian Michalak
    Network Consultant, Twórca Na Styku Sieci

    6 KOMENTARZE

    guest
    6 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    Paweł Drzewiecki

    Cześć Damian. Świetny artykuł. Dotknął mnie dosyć poważnie problem z ntp kiedy jeden z hostów z Vcenter na którym było X logicznych maszyn synchronizował czas z nieistniejącym serwerem czasu. W konsekwencji czas na logicznych serwerach cofał się o dwie godziny, na których były uruchomione joby, które na podstawie czasu tworzyły strukturę folderów i przerzucały odpowiednio pliki do nich. Problem udało się zdiagnozować w logach maszyny wirtualnej na której proces vm… cofał czas a potem szybko go naprawić np. w edycji hosta ustawić odpowiedni serwer ntp. Także ntp to \”must have\” odpowiednia ilość serwerów wyskalowana do potrzeb.

    SpeX

    To jak najlepiej zorganizować sobie swój lokalny serwer NTP? Czy trzymać go na routerze, czy jednak na jakiś dedykowanym rozwiązaniu?

    SpeX

    Do tego drugie pytanie, jak porównać dwa NTP? W sensie, iż systemy po naszej stronie korzystają z naszego NTP, ale musimy komunikować się z drugą (zewnętrzną) stroną i chcemy wiedzieć, jaka jest rozbieżność czasu między nami?

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    134ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    6
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x