Configuration d'un serveur NTP local de la couche 2

9

J'essaie de configurer NTP sur un réseau local qui n'a pas (et ne sera jamais) de connexion Internet. La priorité principale est que les machines du réseau soient synchronisées entre elles, même si l'heure à laquelle elles sont synchronisées n'est pas précise à 100%.

Nous avons également besoin d'utiliser une hiérarchie NTP afin de répliquer la configuration d'un système déployé. Ce que je veux faire, c'est avoir une hiérarchie de machines comme celle-ci:

Moon  (Main Server running Windows) (10.1.3.10)
|____Earth   (Linux x64 client) (10.1.3.1)
|____Mars    (Linux x64 client) (10.1.3.2)
|____Saturn  (Linux x64 client) (10.1.3.3)
|____RackCard23   (Linux x64 client and server to the two machines below)  (10.1.3.23)
     |___RackCard21   (Linux x64 client) (10.1.4.21)
     |___RackCard22   (Linux x64 client) (10.1.4.22)

Notez que les RackCards ont deux ports Ethernet, l'un connecté au réseau 10.1.3.x et l'autre sur le réseau 10.1.4.x. RackCard23, qui se synchronise avec le serveur maître Moon, le fera sur le réseau 10.1.3.x et la RackCard22 / 23 se connectera à RackCard23 sur le réseau 10.1.4.x. C'est parce que je ne veux pas que les RackCards22 / 23 quittent leur réseau pour synchroniser l'heure et parce qu'il reproduit un système final déployé.

Jusqu'à présent, j'ai réussi à obtenir tout ce qui devrait en se synchronisant avec Moon pour se synchroniser correctement (y compris RackCard23).

Mais j'ai du mal à synchroniser RackCard22 et 23 avec RackCard23.

[root@RackCard23]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.3.10 iburst minpoll 4 maxpoll 4 prefer #This is what we want to happen
fudge   127.127.1.0 stratum 2   #Not sure about these two lines, was trying to force it to be a stratum 2 server
fudge   127.127.0.1 stratum 2

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
restrict 10.1.3.10 mask 255.255.255.255 nomodify notrap noquery

#Attempt to get to act as an NTP Server
broadcast 10.1.4.255

restrict 10.1.3.21 mask 255.255.255.255 nomodify notrap
restrict 10.1.4.21 mask 255.255.255.255 nomodify notrap

Voici la sortie de ntptrace:

[rootRackCard23]# /usr/sbin/ntptrace
localhost.localdomain: stratum 16, offset 0.000000, synch distance 0.000030

Comme vous pouvez le voir, la machine se présente comme un serveur de la couche 16, bien qu'elle ait été synchronisée avec un serveur "de la couche 1" (Moon):

[root@RackCard23 awd]# /usr/sbin/ntpdate -d 10.1.3.10
21 Jun 13:55:09 ntpdate[19410]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.3.10 and service ntp
host found : 10.1.3.10
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
receive(10.1.3.10)
transmit(10.1.3.10)
server 10.1.3.10, port 123
stratum 1, precision -6, leap 00, trust 000
refid [LOCL], delay 0.04135, dispersion 0.00383
transmitted 4, in filter 4
reference time:    cfc99402.e010624d  Mon, Jun 21 2010  8:32:18.875
originate timestamp: cfc9dfad.48000000  Mon, Jun 21 2010 13:55:09.281
transmit timestamp:  cfc9dfad.47e27179  Mon, Jun 21 2010 13:55:09.280
filter delay:  0.04155  0.04155  0.04137  0.04135
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.01448 0.000781 0.000537 0.000394
         0.000000 0.000000 0.000000 0.000000
delay 0.04135, dispersion 0.00383
offset 0.000394

21 Jun 13:55:09 ntpdate[19410]: adjust time server 10.1.3.10 offset 0.000394 sec

La configuration des clients (RackCard21 / 22) ressemble à ceci:

[root@RackCard21]# cat /etc/ntp.conf
# NTP Deamon Configuration File "ntp.conf"
# Created on 27/04/2010
# Original backed-up as "ntp.conf.backup"

server 10.1.4.23 iburst minpoll 4 maxpoll 4 prefer

server 127.127.1.0
fudge   127.127.1.0 stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# restrict 127.0.0.1

restrict None mask 255.255.255.255 nomodify notrap noquery

Et ntptrace donne ceci:

[root@RackCard21]# /usr/sbin/ntpdate -d 10.1.4.23
21 Jun 14:04:34 ntpdate[14381]: ntpdate 4.2.2p1@1.1570-o Tue May 19 13:57:56 UTC 2009 (1)
Looking for host 10.1.4.23 and service ntp
host found : 10.1.4.23
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
receive(10.1.4.23)
transmit(10.1.4.23)
10.1.4.23: Server dropped: strata too high
server 10.1.4.23, port 123
stratum 16, precision -20, leap 11, trust 000
refid [10.1.4.23], delay 0.02568, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: cfc9dfef.12b79516  Mon, Jun 21 2010 13:56:15.073
transmit timestamp:  cfc9e1e2.aeae7d56  Mon, Jun 21 2010 14:04:34.682
filter delay:  0.02573  0.02571  0.02568  0.02568
         0.00000  0.00000  0.00000  0.00000
filter offset: -499.609 -499.609 -499.609 -499.609
         0.000000 0.000000 0.000000 0.000000
delay 0.02568, dispersion 0.00000
offset -499.609286

21 Jun 14:04:34 ntpdate[14381]: no server suitable for synchronization found

Il ne peut donc pas trouver de serveur approprié car le serveur que j'essaie d'utiliser signale qu'il s'agit d'un serveur de la couche 16 (ce qui, je crois, signifie non synchronisé). Ceci malgré le fait qu'il est synchronisé.

Je dois donc en quelque sorte faire de RackCard23 une strate supérieure (idéalement la strate 2). Comment dois-je procéder?

Toute aide est très appréciée car j'essaie de faire fonctionner cela depuis des jours maintenant!

ÉDITER:

Salut Christopher,

J'ai redémarré le ntpd, oui;)

Toutes les boîtes Linux exécutent CentOS 5.4.

Il s'agit de la sortie des commandes que vous avez suggérées. Tout d'abord depuis le serveur:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

[root@RackCard23]# /usr/sbin/ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  34566 127.0.0.1              1 7 2      0      0       0
10.1.4.21                123 10.1.4.23              5 3 4    180      5       1
10.1.4.22                123 10.1.4.23              7 3 4      0      2       2

Et puis du client:

[root@RackCard21]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.4.23       .INIT.          16 u   10   16    0    0.000    0.000   0.000
 LOCAL(0)        .LOCL.          10 l   44   64    1    0.000    0.000   0.001

ntp

— fwgx
source

Si vous n'avez pas de connexion Internet, quelle est votre source de temps, l'ai-je raté quelque part?

— dbasnett

La source de temps n'a pas vraiment d'importance, nous ne recherchons pas un temps précis à 100%. Ce que nous voulons, c'est que toutes les machines soient synchronisées les unes avec les autres, même si cela signifie que leur temps est supérieur de 10 minutes à l'heure réelle. Nous utilisons donc une machine aléatoire sur le réseau comme source de temps maître - c'est-à-dire juste son horloge interne. Ce que nous connaissons et acceptons n'est pas fiable, mais tant que les choses se synchronisent, c'est OK pour nous. Dans le vrai système déployé, nous synchroniserons avec une source de temps sur un autre système sur lequel nous n'avons aucun contrôle, qui peut être plus précis ou non.

— fwgx

5

Comme Chris l'a mentionné, la strate 16 indique qu'un serveur n'a pas réellement été synchronisé avec un serveur. Juste pour être certain, vous avez redémarré les services ntp, non? ( service ntpd restart) Je n'essaye pas d'insinuer que vous manquez les trucs faciles, mais je le fais toujours!

Pouvez-vous publier la sortie de quelques commandes supplémentaires pour aider à diagnostiquer?

ntpq -psur le client et le serveur. Devrait montrer quels serveurs il a configurés, ainsi que les statistiques de ces serveurs.
ntpdc -c monlistsur le serveur. Devrait montrer les clients connectés.

De plus, comme vous n'avez pas mentionné de système d'exploitation, je cours avec des commandes de style RHEL. Faites-moi savoir si vous avez quelque chose de différent.

MODIFIER après plus d'informations
OK, en voyant votre sortie, voici votre problème: vous n'avez pas de serveur de couche 1. En fait, la "Lune" utilise son horloge locale. Il se présente comme un serveur de la couche 16. Pour votre référence, un serveur Stratum1 aurait un GPS local ou une horloge atomique. En avez-vous un? Sinon, Moon doit synchroniser son horloge avec UN AUTRE serveur ntp. S'il n'a pas accès au réseau, vous devrez truquer sa couche. (Cela vous oblige à ne pas trop vous soucier du «vrai» temps. Ce que vous n'avez pas, mais toute personne lisant ceci devrait le noter.)

Sur la Lune, ajoutez la ligne suivante dans votre fichier ntp.conf: fudge 127.127.1.0 stratum 10. Cela lui fera signaler son horloge locale en tant que strate 10. Ce qui obligera tous les autres serveurs à l'utiliser sur leur horloge locale de la strate 16.

--Christopher Karel

— Christopher Karel
source

a ajouté des résultats à la question principale.

— fwgx

d'accord avec Christopher. beaucoup d'idées fausses sur Strata ntp.org/ntpfaq/NTP-s-algo.htm

— dbasnett

3

Peut-être hors sujet, un serveur Stratum 2 local nécessite une connexion à un serveur Stratum 1 et au sein de votre réseau isolé, vous n'en avez pas.

Vous pouvez obtenir un module GPS bon marché et un Raspberry Pi, un ordinateur à carte unique avec une consommation d'énergie minimale et une grande capacité d'interface. Connectez votre module GPS au Raspberry Pi et connectez le Pi à votre réseau, avec le logiciel approprié, il peut s'agir de votre serveur NTP Stratum 1 que votre serveur Stratum 2, ou puisque vous l'avez dans votre réseau chaque ordinateur, synchronisez l'heure avec.

2

NTPd définira sa propre strate en fonction de:

Si la dérive de l'horloge locale n'a pas été évaluée, définissez la strate sur 16. Ce processus prend environ 15 minutes sur un serveur normal, après quoi il passe à l'étape suivante.
Connectez-vous à tous les serveurs de temps configurés, évaluez ceux qui sont fiables (et donc préférés), définissez la strate locale sur la strate du serveur fiable la plus basse plus une. Donc, si le serveur fiable le plus bas trouvé est 1, alors local sera 2.

(Il ne s'agit pas nécessairement de l'ordre des événements, mais de l'ordre dans lequel ils sont traités pour définir la strate locale.)
(De plus, la strate 16 ne signifie pas nécessairement qu'elle n'est pas synchronisée).

— Chris S
source

1

Serait-ce parce que Moon est une machine Windows XP Pro x64 utilisant le service NTP W32Time par défaut qui est en fait Simple NTP (SNTP), que RackCard23 ne le voit pas comme un serveur NTP approprié, donc ne définira jamais sa strate à autre chose que 16?

— fwgx

D'oh, je n'ai pas vu ça avant d'éditer mon post. C'est assez probable. Une raison de ne pas utiliser un client ntp approprié au sommet de votre hiérarchie? (Windows ou Unix)

— Christopher Karel

2

Comme une sorte de côté, je vais inclure une analyse de votre sortie ntpq. Juste pour aider au dépannage générique à l'avenir, pour vous et pour les autres.

Tout d'abord, depuis votre serveur:

[root@RackCard23]# /usr/sbin/ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.3.10       .INIT.          16 u    -   16    0    0.000    0.000   0.000
 10.1.4.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

La première colonne indique les deux serveurs sur lesquels cette machine est configurée pour se synchroniser. L'absence *ou +l'indication d'un pair synchronisé ou de candidats secondaires est notable . Cela signifie que votre serveur n'utilisera pas les entrées ici, mais qu'il se connecte au moins avec elles.

La troisième colonne, "st", indique la strate de ces serveurs. Dans ce cas, cela indique que ces deux machines utilisent leur horloge locale. (strate par défaut de 16) Les trois dernières colonnes indiqueraient la distance entre les deux horloges. Soit dans une valeur de "différence d'heures en secondes", soit la latence entre les deux machines, à la différence de cette latence. Ici, des chiffres plus élevés sont pires.

La raison des entrées non synchronisées comme celle-ci peut dépendre de certains facteurs: si le décalage dans les horloges est trop important, alors ntp n'essaiera même pas, car il introduirait un saut trop important dans l'heure locale. Si la gigue se détériore, le client se désynchronise jusqu'à ce que les choses se stabilisent. (Ceci est généralement temporaire, mais se reproduit) Alternativement, comme dans votre cas, si les serveurs configurés ont des valeurs de strate égales ou supérieures, indiquant qu'ils sont moins fiables en tant que sources de temps, le client ne les utilisera pas.

--Christopher Karel

— Christopher Karel
source