Protocolo de tempo da rede da Cisco (NTP)

NTP (Network Time Protocol) é usado para permitir que dispositivos de rede sincronizem seus relógios com um relógio de origem central. Para dispositivos de rede como roteadores, switches ou firewalls isso é muito importante porque queremos ter certeza de que as informações de registro e timestamps têm a hora e data precisas. Se alguma vez tiver problemas de rede ou for pirateado, quer certificar-se de que sabe exactamente o que aconteceu e quando aconteceu.

normalmente um roteador ou interruptor será executado no modo cliente NTP, o que significa que ele irá ajustar o seu relógio com base na hora de um servidor NTP. Basicamente, o protocolo NTP descreve o algoritmo que os clientes NTP usam para sincronizar seus relógios com o servidor NTP e os pacotes que são usados entre eles.

um bom exemplo de um servidor NTP é ntp.pool.org. este é um conjunto de Servidores NTP que muitos servidores e dispositivos de rede usam para sincronizar seus relógios.

NTP usa um conceito chamado “estrato” que define quantos saltos NTP a distância de um dispositivo é de uma fonte de tempo autorativa. Por exemplo, um dispositivo com estrato 1 é um dispositivo muito preciso e pode ter um relógio atômico ligado a ele. Outro servidor NTP que está usando este servidor stratum 1 para sincronizar seu próprio tempo seria um dispositivo stratum 2 porque é um hop NTP mais longe da fonte. Quando você configurar vários servidores NTP, o cliente irá preferir o servidor NTP com o menor valor estrato.

roteadores e interruptores Cisco podem usar 3 modos NTP diferentes:

• NTP modo cliente.
• modo de servidor NTP.
• NTP modo activo simétrico.

o modo ativo simétrico é usado entre dispositivos NTP para sincronizar uns com os outros, é usado como um mecanismo de backup quando eles são incapazes de alcançar o servidor NTP (externo).

no restante desta lição, vou demonstrar como configurar NTP em um roteador e switches Cisco.

configuração

esta é a topologia que vou usar:

the router on the top is called “CoreRouter” and its the edge of my network. Ele está conectado à Internet e vai usar um dos servidores NTP de pool.ntp.org para sincronizar o relógio. A rede também tem dois interruptores internos que requerem relógios sincronizados. Ambos os switches se tornarão clientes NTP do CoreRouter, tornando assim o CoreRouter um servidor NTP.

configuração do Router

Primeiro, vamos configurar o CoreRouter no topo. Eu usarei pool.ntp.org como o servidor NTP externo para este exemplo. Temos de ter a certeza que o router é capaz de resolver os nomes das máquinas:

CoreRouter(config)#ip name-server 8.8.8.8

vou usar o Google DNS para isso. O nosso próximo passo é configurar o servidor NTP:

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

isso foi fácil o suficiente, apenas um comando e vamos sincronizar o nosso relógio com o servidor público. Podemos verificar o nosso trabalho assim.:

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

acima vemos o comando Mostrar associações ntp que nos diz se o nosso relógio está sincronizado ou não. O ~ na frente do endereço IP nos diz que configuramos este servidor, mas ainda não estamos sincronizados. Você pode ver isso porque não há * na frente do endereço IP e o campo ” st ” (estrato) é atualmente 16.

Há um comando mais que nos dá mais informações sobre a configuração do 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.

O roteador diz a nós que não estão sincronizados e que não há nenhuma referência relógio…vamos apenas esperar alguns minutos e dê uma olhada nesses comandos novamente:

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

alguns minutos mais tarde e a saída foi alterado. O * na frente do endereço IP nos diz que temos sincronizado e o estrato é 2…isso significa que este servidor NTP está muito perto de uma fonte de tempo confiável. O campo “poll” nos diz que vamos tentar sincronizar o tempo a cada 64 segundos. Vamos verificar o outro comando que acabamos de ver.:

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.

nosso relógio foi sincronizado e nosso próprio estrato é 3, que faz sentido uma vez que o servidor público estrato tem um estrato de 2 e estamos a um “hop” de distância dele.

os roteadores da Cisco têm dois relógios diferentes, têm um relógio de software e um relógio de hardware e operam separadamente um do outro. Aqui está como ver os dois relógios:

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

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

o comando mostrar o relógio mostra-me o relógio de software enquanto o comando mostrar o calendário me dá o relógio de hardware. Os dois relógios não estão sincronizados, então isto é algo que devemos consertar, você pode fazer assim:

CoreRouter#(config)ntp update-calendar

o comando ntp update-calendar irá atualizar o relógio de hardware com a hora do relógio de software, aqui está o resultado:

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

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

era tudo o que queria configurar no CoreRouter por agora. Ainda temos de configurar dois interruptores para sincronizar os relógios.

Switch Configuration

the two switches will be configured to use the CoreRouter as the NTP server and I will also configure them to synchronize their clocks with each other. Vamos configurá-los para usar o CoreRouter primeiro.:Mais uma vez pode demorar alguns minutos a sincronizar, mas isto é o que você vai ver:

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

o relógio de SW1 foi sincronizado e seu estrato é de 4. Isto faz sentido uma vez que é um “hop” mais longe de seu servidor NTP (CoreRouter). Vamos fazer o mesmo para o SW2:

SW2(config)#ntp server 192.168.123.3

vamos ser pacientes por mais alguns minutos e isto é o que vamos ter:

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 estão agora a usar o CoreRouter para sincronizar os relógios. Vamos também configurá-los para usar uns aos outros para a sincronização. Este é o modo simétrico ativo mencionei antes, basicamente, duas opções, vai “ajudar” os outros para sincronizar…isso pode ser útil no caso de o CoreRouter falhar algum dia:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

Depois de esperar alguns minutos, você verá que SW1 e SW2 ter sincronizados uns com os outros:

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

Grande agora está tudo em 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

isso é tudo? Ainda não…há mais algumas coisas que podemos fazer com a NTP. O CoreRouter e os dois switches usam unicast (UDP port 123) para sincronização, mas você também pode usar multicast ou transmissão. Deixe-me dar-lhe um exemplo …

Multicast e Broadcast

se você tem mais de 20 dispositivos de rede ou um roteador que tem memória limitada do sistema ou recursos de CPU você pode querer considerar a utilização de transmissão NTP ou multicast, uma vez que requer menos recursos. Podemos activar o multicast ou transmitir na interface level.To demonstre isso eu vou adicionar dois roteadores abaixo SW1 e SW2 que vão sincronizar-se usando multicast ou transmissão. Isto é o que parece:

i’ll configure SW1 to use multicast address 239.1.1.1 and SW2 will send NTP updates through broadcast: