Cisco Network Time Protocol (NTP)

NTP (Network Time Protocol) viene utilizzato per consentire ai dispositivi di rete di sincronizzare i loro orologi con un orologio sorgente centrale. Per i dispositivi di rete come router, switch o firewall questo è molto importante perché vogliamo assicurarci che le informazioni di registrazione e i timestamp abbiano l’ora e la data precise. Se avete mai problemi di rete o ottenere violato, si vuole fare in modo di sapere esattamente cosa e quando è successo.

Normalmente un router o uno switch verrà eseguito in modalità client NTP, il che significa che regolerà il suo orologio in base al tempo di un server NTP. Fondamentalmente il protocollo NTP descrive l’algoritmo che i client NTP utilizzano per sincronizzare i loro orologi con il server NTP e i pacchetti che vengono utilizzati tra di loro.

Un buon esempio di un server NTP è ntp.pool.org. Questo è un cluster di server NTP che molti server e dispositivi di rete utilizzano per sincronizzare i loro orologi.

NTP utilizza un concetto chiamato “stratum” che definisce il numero di passaggi NTP che un dispositivo proviene da un’origine temporale autorativa. Ad esempio, un dispositivo con strato 1 è un dispositivo molto preciso e potrebbe avere un orologio atomico collegato ad esso. Un altro server NTP che utilizza questo server stratum 1 per sincronizzare il proprio tempo sarebbe un dispositivo stratum 2 perché è un hop NTP più lontano dalla fonte. Quando si configurano più server NTP, il client preferirà il server NTP con il valore di strato più basso.

I router e gli switch Cisco possono utilizzare 3 diverse modalità NTP:

• Modalità client NTP.
• Modalità server NTP.
• Modalità attiva simmetrica NTP.

La modalità attiva simmetrica viene utilizzata tra i dispositivi NTP per sincronizzarsi tra loro, viene utilizzata come meccanismo di backup quando non sono in grado di raggiungere il server NTP (esterno).

Nel resto di questa lezione, dimostrerò come configurare NTP su un router e switch Cisco.

Configurazione

Questa è la topologia che userò:

Il router in alto si chiama “CoreRouter” ed è il bordo della mia rete. È connesso a Internet e utilizzerà uno dei server NTP da pool.ntp.org per sincronizzare il suo orologio. La rete ha anche due interruttori interni che richiedono orologi sincronizzati. Entrambi gli switch diventeranno client NTP del CoreRouter, rendendo così il CoreRouter un server NTP.

Configurazione del router

Per prima cosa configureremo il CoreRouter in cima. Userò pool.ntp.org come server NTP esterno per questo esempio. Dobbiamo assicurarci che il router sia in grado di risolvere i nomi host:

CoreRouter(config)#ip name-server 8.8.8.8

Userò Google DNS per questo. Il nostro prossimo passo è configurare il server NTP:

CoreRouter(config)#ntp server pool.ntp.org

È stato abbastanza facile, basta un comando e sincronizzeremo il nostro orologio con il server pubblico. Possiamo verificare il nostro lavoro in questo modo:

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

Sopra vediamo il comando Mostra associazioni ntp che ci dice se il nostro orologio è sincronizzato o meno. Il ~ davanti all’indirizzo IP ci dice che abbiamo configurato questo server ma non siamo ancora sincronizzati. Puoi vederlo perché non c’è * davanti all’indirizzo IP e il campo “st” (strato) è attualmente 16.

C’è un altro comando che ci dà ulteriori informazioni sulla configurazione NTP:

CoreRouter#show ntp statusClock is unsynchronized, stratum 16, no reference clocknominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)clock offset is 0.0000 msec, root delay is 0.00 msecroot dispersion is 0.16 msec, peer dispersion is 0.00 msecloopfilter state is 'FSET' (Drift set from file), drift is 0.000000000 s/ssystem poll interval is 64, never updated.

Il router ci dice che siamo sincronizzato e che non c’è alcun riferimento di clock…dobbiamo solo attendere un paio di minuti e date un’occhiata a questi comandi:

CoreRouter#show ntp associations address ref clock st when poll reach delay offset disp*~146.185.130.223 193.79.237.14 2 26 64 1 10.857 -5.595 7937.5 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

pochi minuti più tardi, e l’uscita è cambiato. Il * di fronte all’indirizzo IP ci dice che abbiamo sincronizzato e lo strato è 2 means ciò significa che questo server NTP è abbastanza vicino a una fonte di tempo affidabile. Il campo “sondaggio” ci dice che cercheremo di sincronizzare l’ora ogni 64 secondi. Controlliamo l’altro comando che abbiamo appena visto:

CoreRouter#show ntp status Clock is synchronized, stratum 3, reference is 146.185.130.22nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24reference time is D76513B4.66A4CDA6 (12:40:20.400 UTC Mon Jul 7 2014)clock offset is -5.5952 msec, root delay is 13.58 msecroot dispersion is 7966.62 msec, peer dispersion is 7937.50 msecloopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000000018 s/ssystem poll interval is 64, last update was 43 sec ago.

Il nostro orologio è stato sincronizzato e il nostro strato è 3, che ha senso dal momento che il server stratum pubblico ha uno strato di 2 e siamo un “salto” di distanza da esso.

I router Cisco hanno due orologi diversi, hanno un orologio software e un orologio hardware e operano separatamente l’uno dall’altro. Ecco come vedere entrambi gli orologi:

CoreRouter#show clock 12:41:25.197 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:43:24 UTC Mon Jul 7 2014

Il comando show clock mi mostra l’orologio software mentre il comando show calendar mi dà l’orologio hardware. I due orologi non sono sincronizzati, quindi questo è qualcosa che dovremmo risolvere, puoi farlo in questo modo:

CoreRouter#(config)ntp update-calendar

Il comando ntp update-calendar aggiornerà l’orologio hardware con l’ora dell’orologio software, ecco il risultato:

CoreRouter#show clock 12:42:31.853 UTC Mon Jul 7 2014

CoreRouter#show calendar 12:42:30 UTC Mon Jul 7 2014

Questo è tutto quello che volevo configurare sul CoreRouter per ora. Dobbiamo ancora configurare due interruttori per sincronizzare i loro orologi.

Configurazione switch

I due switch saranno configurati per utilizzare il CoreRouter come server NTP e li configurerò anche per sincronizzare i loro orologi tra loro. Configuriamoli per usare prima il CoreRouter:

SW1(config)#ntp server 192.168.123.3

Ancora una volta potrebbe richiedere alcuni minuti per la sincronizzazione, ma questo è ciò che vedrai:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 21 64 1 2.5 1.02 15875. * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW1#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2089 Hz, precision is 2**18reference time is D765271D.D6021302 (14:03:09.835 UTC Mon Jul 7 2014)clock offset is 1.0229 msec, root delay is 14.31 msecroot dispersion is 16036.00 msec, peer dispersion is 15875.02 msec

L’orologio di SW1 è stato sincronizzato e il suo strato è 4. Questo ha senso dal momento che è un “salto” più lontano dal suo server NTP (CoreRouter). Facciamo lo stesso per SW2:

SW2(config)#ntp server 192.168.123.3

Cerchiamo di essere pazienti per qualche altro minuto e questo è quello che otterremo:

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 17 64 37 3.4 1.89 875.8 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp status Clock is synchronized, stratum 4, reference is 192.168.123.3nominal freq is 119.2092 Hz, actual freq is 119.2084 Hz, precision is 2**18reference time is D765274D.D51A0546 (14:03:57.832 UTC Mon Jul 7 2014)clock offset is 1.8875 msec, root delay is 15.18 msecroot dispersion is 1038.39 msec, peer dispersion is 875.84 msec

SW1 e SW2 stanno ora utilizzando CoreRouter per sincronizzare i loro orologi. Configuriamo anche loro di utilizzare l’un l’altro per la sincronizzazione. Questa è la modalità attiva simmetrica ho detto prima, fondamentalmente due opzioni di “aiuto” per sincronizzare…questo potrebbe essere utile nel caso in cui il CoreRouter fallisce qualche giorno:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

Dopo un’attesa di pochi minuti vedrai che SW1 e SW2 sono sincronizzati l’uno con l’altro:

SW1#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 59 64 37 3.0 -0.74 877.4+~192.168.123.2 192.168.123.3 4 50 128 376 2.2 -2.04 1.3 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

SW2#show ntp associations address ref clock st when poll reach delay offset disp*~192.168.123.3 146.185.130.223 3 45 128 377 2.9 1.95 1.0 ~192.168.123.1 192.168.123.3 4 67 1024 376 1.8 2.40 1.4 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

tutto quello che è ora in sincronia.

hostname CoreRouter!interface FastEthernet0/0 ip address 192.168.123.3 255.255.255.0!ip name-server 8.8.8.8!ntp server pool.ntp.orgntp update-calendar!end

hostname SW1!interface FastEthernet0/24 ip address 192.168.123.1 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.2!end

hostname SW2!interface FastEthernet0/24 ip address 192.168.123.2 255.255.255.0!ntp server 192.168.123.3ntp peer 192.168.123.1!end

Abbiamo finito? Non ancora del tutto…ci sono alcune altre cose che possiamo fare con NTP. Il CoreRouter e i due switch utilizzano unicast (porta UDP 123) per la sincronizzazione, ma è anche possibile utilizzare multicast o broadcast. Permettetemi di fare un esempio Multicast e Broadcast

Se si dispone di più di 20 dispositivi di rete o di un router con risorse di memoria di sistema o CPU limitate, si potrebbe prendere in considerazione l’utilizzo di NTP broadcast o multicast in quanto richiede meno risorse. Possiamo abilitare multicast o broadcast sull’interfaccia level.To dimostrare questo aggiungerò due router sotto SW1 e SW2 che si sincronizzeranno utilizzando multicast o broadcast. Questo è quello che sembra:

Configurerò SW1 per utilizzare l’indirizzo multicast 239.1.1.1 e SW2 invierà aggiornamenti NTP tramite broadcast: