Configuración de un servidor NTP de estrato 2 local

9

Estoy tratando de configurar NTP en una red local que no tiene (y nunca tendrá) conexión a Internet. La principal prioridad es que las máquinas en la red estén sincronizadas entre sí, incluso si el tiempo en que están sincronizadas no es 100% preciso.

También tenemos el requisito de usar una jerarquía NTP para replicar la configuración de un sistema implementado. Lo que quiero hacer es tener una jerarquía de máquinas como esta:

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)

Tenga en cuenta que las RackCards tienen dos puertos ethernet, uno conectado a la red 10.1.3.xy otro en la red 10.1.4.x. RackCard23, que se sincroniza con el servidor maestro Moon lo hará en la red 10.1.3.xy la RackCard22 / 23 se conectará a RackCard23 en la red 10.1.4.x. Esto se debe a que no quiero que las RackCards22 / 23 abandonen su red para sincronizar la hora y porque replica un sistema implementado final.

Hasta ahora, he logrado obtener todo lo que debería al sincronizar Moon para sincronizar correctamente (incluida RackCard23).

Pero estoy teniendo dificultades para que RackCard22 y 23 se sincronicen con 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

Este es el resultado de ntptrace:

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

Como puede ver, la máquina se informa a sí misma como un servidor del estrato 16, a pesar de haberse sincronizado con un servidor del "estrato 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 configuración de los clientes (RackCard21 / 22) se ve así:

[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

Y ntptrace da esto:

[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

Por lo tanto, no puede encontrar un servidor adecuado porque el servidor que estoy tratando de usar informa que es un servidor del estrato 16 (que creo que significa no sincronizado). Esto a pesar del hecho de que está sincronizado.

Por lo tanto, necesito hacer de RackCard23 un estrato más alto (idealmente estrato 2). ¿Cómo hago para hacer eso?

Cualquier ayuda es muy apreciada ya que he estado tratando de hacer que esto funcione durante días.

EDITAR:

Hola christopher

He estado reiniciando el ntpd, sí;)

Todas las cajas de Linux están ejecutando CentOS 5.4.

Este es el resultado de los comandos que sugirió. Primero del servidor:

[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

Y luego del cliente:

[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
fuente

Si no tiene una conexión a Internet, ¿cuál es su fuente de tiempo? ¿La extrañé en alguna parte?

— dbasnett

La fuente de tiempo realmente no importa, no buscamos un tiempo 100% exacto. Lo que sí queremos es que todas las máquinas estén sincronizadas entre sí, incluso si eso significa que sus tiempos son más de 10 minutos menos que el tiempo real. Por lo tanto, estamos utilizando una máquina aleatoria en la red como fuente de tiempo maestro, es decir, solo su reloj interno. Lo que sabemos y aceptamos no es confiable, pero mientras las cosas se sincronicen, está bien para nosotros. En el sistema real desplegado, estaremos sincronizando con una fuente de tiempo en otro sistema sobre el que no tenemos control, lo que puede o no ser más preciso.

— fwgx

5

Como Chris mencionó, el estrato 16 indica que un servidor no se ha sincronizado realmente con un servidor. Solo para estar seguro, reinició los servicios ntp, ¿verdad? ( service ntpd restart) No estoy tratando de insinuar que te pierdas las cosas fáciles, ¡pero siempre lo hago!

¿Puedes publicar la salida de algunos comandos más para ayudar a diagnosticar?

ntpq -pen el cliente y el servidor. Debería mostrar qué servidores ha configurado, así como las estadísticas para esos servidores.
ntpdc -c monlisten el servidor Debe mostrar a los clientes conectados.

Además, como no mencionó un sistema operativo, estoy ejecutando comandos de estilo RHEL. Avísame si tienes algo diferente.

EDITAR después de más información
OK, viendo su salida, este es su problema: no tiene un servidor de estrato 1. De hecho, la "Luna" está usando su reloj local. Se informa a sí mismo como un servidor del estrato 16. Para su referencia, un servidor Stratum1 tendría un GPS local o un reloj atómico. ¿Tienes uno de esos? De lo contrario, Moon necesita sincronizar su reloj con OTRO servidor ntp. Si no tiene acceso a la red, deberás evadir su estrato. (Esto requiere que no te preocupes demasiado por el tiempo "verdadero". Lo cual no es cierto, pero cualquiera que lea esto debería tener en cuenta eso).

En la luna, añadir la siguiente línea a su archivo ntp.conf: fudge 127.127.1.0 stratum 10. Esto hará que informe su reloj local como estrato 10. Lo que hará que todos los demás servidores lo usen sobre su reloj de estrato 16 local.

--Christopher Karel

— Christopher Karel
fuente

Se agregaron resultados a la pregunta principal.

— fwgx

de acuerdo con Christopher. muchos conceptos erróneos sobre Strata ntp.org/ntpfaq/NTP-s-algo.htm

— dbasnett

3

Puede estar fuera de tema, un servidor Stratum 2 local requiere conexión a un servidor Stratum 1 y dentro de su red aislada, no tiene uno.

Puede obtener un módulo GPS barato y una Raspberry Pi, una computadora de placa única con un consumo mínimo de energía y una amplia capacidad de interfaz. Conecte su módulo GPS a la Raspberry Pi y únase a la Pi a su red, con el software adecuado, puede ser su servidor Stratum 1 NTP con su servidor Stratum 2, o ya que lo tiene dentro de su red en cada computadora, sincronice el tiempo.

2

NTPd establecerá su propio estrato según:

Si no se ha evaluado la deriva del reloj local, establezca el estrato en 16. Este proceso tarda unos 15 minutos en un servidor normal, después de lo cual continúa con el siguiente paso.
Conéctese a todos los servidores de tiempo configurados, evalúe cuáles son confiables (y por lo tanto preferidos), establezca el estrato local en el estrato de servidor confiable más bajo más uno. Entonces, si el servidor confiable más bajo encontrado es 1, entonces local será 2.

(Este no es necesariamente el orden de los eventos, sino el orden en que se procesan con el propósito de establecer el estrato local).
(Además, el estrato 16 no significa necesariamente que no esté sincronizado).

— Chris S
fuente

1

¿Podría ser que debido a que Moon es una máquina Windows XP Pro x64 que usa el servicio W32Time NTP predeterminado, que en realidad es Simple NTP (SNTP), que RackCard23 no lo ve como un servidor NTP adecuado, por lo que nunca establecerá su estrato en otra cosa? de 16?

— fwgx

Oh, no vi esto antes de editar mi publicación. Esto es bastante probable. ¿Alguna razón para no usar un cliente ntp adecuado en la parte superior de su jerarquía? (Windows o Unix)

— Christopher Karel

2

Como una especie de lado, incluiré un análisis de su salida ntpq. Solo para ayudar a solucionar problemas genéricos en el futuro, para usted y para otros.

Primero, desde su servidor:

[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 primera columna indica los dos servidores con los que esta máquina está configurada para sincronizarse. Es notable la falta de *o +eso indicaría un par sincronizado, o candidatos secundarios. Esto significa que su servidor no va a utilizar las entradas aquí, pero al menos se está registrando con ellas.

La columna tres, "st", indica el estrato de esos servidores. En este caso, eso indica que ambas máquinas están usando su reloj local. (estrato predeterminado de 16) Las últimas tres columnas indicarían qué tan lejos están los dos relojes. Ya sea en un valor de "diferencia de segundos en los relojes", o la latencia entre las dos máquinas, a la diferencia en esa latencia. Aquí, los números más altos son peores.

El motivo de las entradas no sincronizadas como esta puede depender de algunos factores: si el desplazamiento en los relojes es demasiado, entonces ntp ni siquiera lo intentará, ya que introduciría un salto demasiado grande en la hora local. Si la inquietud llega a ser mala, el cliente se desincronizará, hasta que las cosas se estabilicen. (Esto suele ser temporal y, sin embargo, recurrente) Alternativamente, como en su caso, si los servidores configurados tienen valores de estrato iguales o superiores, lo que indica que son menos confiables como fuentes de tiempo, entonces el cliente no los usará.

--Christopher Karel

— Christopher Karel
fuente