NTP fudge red estrato fuente

¿Es posible configurar ntpdpara evitar el nivel de estrato de una fuente de red?

A primera vista, pensé que la fudgedirectiva podría lograr esto, sin embargo, después de navegar por las ntp.conf(5)páginas del manual, descubrí que esta directiva solo se aplica a los Relojes de referencia.

Algunos detalles:

Tengo un servidor local ejecutándose ntpdcomo fuente de tiempo principal para clientes en la LAN. Este servidor apunta al grupo ntp.org y, por lo general, mantiene un nivel de estrato 3.

Además de mi servidor principal, tengo un dispositivo de red de terceros cuyo trabajo principal es sincronizar los relojes de pared de forma inalámbrica a través de. Transmisión de RF. La especificación del dispositivo dice que es un "servidor de tiempo compatible con RFC2030", pero por lo demás es más o menos una caja negra. He configurado el dispositivo para usar mi servidor principal, ya que es la única fuente de tiempo:

caja negra config http://www.freeimagehosting.net/uploads/21bafb12bd.png

Mi problema surgió cuando configuré ntpden mi computadora personal para usar mi servidor NTP principal y el transmisor inalámbrico como fuentes de tiempo. Al consultar mi ntpd local, noté que la "caja negra" (10.xxZ) era la fuente de tiempo preferida:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
x10.x.x.X        69.164.222.108   3 u   48   64  177    0.501  370.029   1.530
*10.x.x.Z        10.x.x.Z         2 u   50   64  377    1.354  -23.681  14.179

Dado que 10.x.x.Zla única fuente de tiempo del servidor es el servidor 10.x.x.X(que es el estrato 3), debería ser el estrato 4. Creo que el fabricante ha codificado su nivel de estrato.

¿Hay alguna forma de hacer que mi máquina favorezca el servidor "bueno" (10.xxX) a pesar de su nivel de estrato más alto? También probé la preferdirectiva en mi ntp.confarchivo local , pero en vano, la pequeña caja negra siempre gana: /

Por lo que vale, mi máquina local ejecuta Mac OS X 10.6.

$ ntpq -c rv | grep version
version="ntpd 4.2.4p4@1.1520-o Mon May 18 19:38:25 UTC 2009 (1)",

Después de un poco más de investigación, parece "fraudulento" el nivel de estrato de una fuente de red no es posible. Así que seguí adelante e intenté la respuesta de dtoubeli . Para mi sorpresa, el simple hecho de convertir mi servidor de hora local en un estrato de nivel 2 (igual al dispositivo de un tercero) no siempre hizo que fuera la fuente de tiempo preferida. Mi ntpd local todavía los gobernaría a ambos como "señales falsas". Por qué razón, no estoy seguro, pero supongo que fueron las dos únicas fuentes de tiempo, y sus tiempos estaban muy lejos.

El mayor problema aquí es el hecho de que mi dispositivo de terceros no parece tener un tiempo muy constante, de hecho, fluctúa mucho. La solución a mi problema fue agregar varias otras fuentes de tiempo precisas (pool.ntp.org) a mi /etc/ntp.conf. Ahora mi servidor local siempre se elige como la fuente de tiempo preferida, a menudo a pesar de tener un nivel de estrato más alto que algunos de los servidores del grupo.

Puede intentar ejecutar su ntpd local en el estrato 2. En lugar de apuntarlo a pool.ntp.org, simplemente cree una lista de 5-7 servidores del estrato 1 y agréguelos directamente a la configuración. Con el servidor de referencia en el estrato 1, el suyo se ejecutará en el estrato 2. Entonces su preferopción puede funcionar.

Sin embargo, desde mi experiencia, el nivel de estrato no siempre es el factor ganador en la elección de la fuente primaria. Creo que la latencia y la inquietud también tienen una influencia significativa. Me di cuenta en varias ocasiones de que el servidor de estrato inferior fue elegido como fuente primaria, aunque había varios servidores de estrato superior disponibles solo porque tenía la latencia más baja. Es por eso que no puedo garantizar que el enfoque sugerido funcione.

Tengo una fuente de tiempo GPS de hardware de "alto estrato (10)" en nuestra red local que me da un estado de falsetick (x) en ntpq, descubrí que usar server [x.x.x.x] true(x = dirección IP) en ntp.conf omitirá la comprobación de falsetick, permitiendo que sea un posible candidato. Parece que el número de estrato no siempre significa mayor prioridad.

Si no le gusta este servidor 10.xxZ como referencia, este debería ser el truco:

server 10.x.x.Z noselect 

Esto es útil si el servidor solo debe usarse por razones de monitoreo. Alternativamente, también puede configurar:

server 10.x.x.X prefer

Por lo tanto, 10.xxZ no se utilizará si 10.xxX está disponible.

Una razón por la que se prefiere es que su otro servidor de tiempo ha sido inaccesible recientemente. Ver la columna de alcance?