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 [email protected] 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 [email protected] 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
Respuestas:
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
fuente
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.
fuente
NTPd establecerá su propio estrato según:
(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).
fuente
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:
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
fuente