Protocole de temps réseau Cisco (NTP)

NTP (Network Time Protocol) est utilisé pour permettre aux périphériques réseau de synchroniser leurs horloges avec une horloge source centrale. Pour les périphériques réseau tels que les routeurs, les commutateurs ou les pare-feu, cela est très important car nous voulons nous assurer que les informations de journalisation et les horodatages ont l’heure et la date précises. Si jamais vous rencontrez des problèmes de réseau ou êtes piraté, vous voulez vous assurer de savoir exactement ce qui s’est passé et quand cela s’est produit.

Normalement, un routeur ou un commutateur fonctionnera en mode client NTP, ce qui signifie qu’il ajustera son horloge en fonction de l’heure d’un serveur NTP. Fondamentalement, le protocole NTP décrit l’algorithme utilisé par les clients NTP pour synchroniser leurs horloges avec le serveur NTP et les paquets utilisés entre eux.

Un bon exemple de serveur NTP est ntp.pool.org . Il s’agit d’un cluster de serveurs NTP que de nombreux serveurs et périphériques réseau utilisent pour synchroniser leurs horloges.

NTP utilise un concept appelé « strate » qui définit le nombre de sauts NTP d’un périphérique à partir d’une source de temps d’auteur. Par exemple, un appareil avec strate 1 est un appareil très précis et peut avoir une horloge atomique attachée à celui-ci. Un autre serveur NTP qui utilise ce serveur de strate 1 pour synchroniser son propre temps serait un périphérique de strate 2 car il est à un saut NTP plus éloigné de la source. Lorsque vous configurez plusieurs serveurs NTP, le client préférera le serveur NTP avec la valeur de strate la plus basse.

Les routeurs et commutateurs Cisco peuvent utiliser 3 modes NTP différents:

• Mode client NTP.
• Mode serveur NTP.
• Mode actif symétrique NTP.

Le mode actif symétrique est utilisé entre les périphériques NTP pour se synchroniser les uns avec les autres, il est utilisé comme mécanisme de sauvegarde lorsqu’ils ne peuvent pas atteindre le serveur NTP (externe).

Dans le reste de cette leçon, je vais démontrer comment configurer NTP sur un routeur et des commutateurs Cisco.

Configuration

C’est la topologie que je vais utiliser:

Le routeur sur le dessus s’appelle « CoreRouter » et c’est le bord de mon réseau. Il est connecté à Internet et utilisera l’un des serveurs NTP de pool.ntp.org pour synchroniser son horloge. Le réseau dispose également de deux commutateurs internes qui nécessitent des horloges synchronisées. Les deux commutateurs deviendront des clients NTP du CoreRouter, faisant ainsi du CoreRouter un serveur NTP.

Configuration du routeur

Nous allons d’abord configurer le CoreRouter sur le dessus. Je vais utiliser pool.ntp.org comme serveur NTP externe pour cet exemple. Nous devons nous assurer que le routeur est capable de résoudre les noms d’hôte:

CoreRouter(config)#ip name-server 8.8.8.8

Je vais utiliser Google DNS pour cela. Notre prochaine étape consiste à configurer le serveur NTP:

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

C’était assez facile, une seule commande et nous synchroniserons notre horloge avec le serveur public. Nous pouvons vérifier notre travail comme ceci:

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

Ci-dessus, nous voyons la commande show ntp associations qui nous indique si notre horloge est synchronisée ou non. Le ~ devant l’adresse IP nous indique que nous avons configuré ce serveur mais que nous ne sommes pas encore synchronisés. Vous pouvez le voir car il n’y a pas de * devant l’adresse IP et le champ « st » (strate) est actuellement 16.

Il y a une commande de plus qui nous donne plus d’informations sur la configuration 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.

Le routeur nous dit que nous ne sommes pas synchronisés et qu’il n’y a pas d’horloge de référencewe nous allons juste attendre quelques minutes et jeter un œil à ces commandes à nouveau:

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

Quelques minutes plus tard et la sortie a changé. Le * devant l’adresse IP nous indique que nous avons synchronisé et que la strate est de 2that cela signifie que ce serveur NTP est assez proche d’une source de temps fiable. Le champ « sondage » nous indique que nous allons essayer de synchroniser l’heure toutes les 64 secondes. Vérifions l’autre commande que nous venons de voir:

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.

Notre horloge a été synchronisée et notre propre strate est 3, c’est logique puisque le serveur public de strate a une strate de 2 et que nous en sommes à un « saut ».

Les routeurs Cisco ont deux horloges différentes, ils ont une horloge logicielle et une horloge matérielle et ils fonctionnent séparément les uns des autres. Voici comment voir les deux horloges:

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

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

La commande show clock me montre l’horloge logicielle tandis que la commande show calendar me donne l’horloge matérielle. Les deux horloges ne sont pas synchronisées, c’est donc quelque chose que nous devrions corriger, vous pouvez le faire comme ceci:

CoreRouter#(config)ntp update-calendar

La commande ntp update-calendar mettra à jour l’horloge matérielle avec l’heure de l’horloge logicielle, voici le résultat:

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

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

C’est tout ce que je voulais configurer sur le CoreRouter pour l’instant. Nous devons encore configurer deux interrupteurs pour synchroniser leurs horloges.

Configuration du commutateur

Les deux commutateurs seront configurés pour utiliser le CoreRouter comme serveur NTP et je les configurerai également pour synchroniser leurs horloges les unes avec les autres. Configurons-les pour qu’ils utilisent d’abord le CoreRouter:

SW1(config)#ntp server 192.168.123.3

Encore une fois, la synchronisation peut prendre quelques minutes mais c’est ce que vous verrez:

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’horloge de SW1 a été synchronisée et sa strate est de 4. Cela a du sens car c’est un « saut » plus loin de son serveur NTP (CoreRouter). Faisons de même pour SW2:

SW2(config)#ntp server 192.168.123.3

Soyons patients encore quelques minutes et c’est ce que nous obtiendrons:

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 et SW2 utilisent maintenant CoreRouter pour synchroniser leurs horloges. Configurons-les également pour qu’ils s’utilisent mutuellement pour la synchronisation. C’est le mode actif symétrique que j’ai mentionné précédemment, en gros, les deux commutateurs vont « s’aider » mutuellement à se synchroniser… cela pourrait être utile au cas où le CoreRouter échouerait un jour:

SW1(config)#ntp peer 192.168.123.2

SW2(config)#ntp peer 192.168.123.1

Après avoir attendu quelques minutes, vous verrez que SW1 et SW2 se sont synchronisés l’un avec l’autre:

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

Tout est maintenant synchronisé.

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

On a fini ? Pas encore tout à faitthere il y a encore quelques choses que nous pouvons faire avec NTP. Le CoreRouter et les deux commutateurs utilisent l’unicast (port UDP 123) pour la synchronisation, mais vous pouvez également utiliser la multidiffusion ou la diffusion. Permettez-moi de vous donner un exemple Multidiffusion et diffusion

Si vous avez plus de 20 périphériques réseau ou un routeur qui a une mémoire système ou des ressources CPU limitées, vous voudrez peut-être envisager d’utiliser la diffusion ou la multidiffusion NTP car elle nécessite moins de ressources. Nous pouvons activer la multidiffusion ou la diffusion sur l’interface level.To démontrez cela, j’ajouterai deux routeurs sous SW1 et SW2 qui se synchroniseront en utilisant la multidiffusion ou la diffusion. Voici à quoi cela ressemble:

Je configurerai SW1 pour utiliser l’adresse de multidiffusion 239.1.1.1 et SW2 enverra des mises à jour NTP par diffusion: