Strato sorgente di rete Nud Fudge


9

È possibile configurare ntpdper confondere il livello dello strato di una sorgente di rete?

A prima vista, ho pensato che la fudgedirettiva potesse raggiungere questo obiettivo, tuttavia dopo aver sfogliato le ntp.conf(5)pagine man, ho scoperto che questa direttiva si applica solo agli orologi di riferimento.

Alcuni dettagli:

Ho un server locale in esecuzione ntpdcome l'origine temporale principale per i client sulla LAN. Questo server è puntato sul pool ntp.org e di solito mantiene uno strato 3.

Oltre al mio server principale, ho un dispositivo di rete di terze parti il ​​cui compito principale è la sincronizzazione wireless degli orologi da parete. Trasmissione RF. Le specifiche del dispositivo indicano che si tratta di un "Time Server conforme RFC2030", ma per il resto è praticamente una scatola nera. Ho configurato il dispositivo per utilizzare il mio server principale in quanto è solo la fonte temporale:

black box config http://www.freeimagehosting.net/uploads/21bafb12bd.png

Il mio problema è emerso quando mi sono configurato ntpdsul mio computer per utilizzare sia il mio server NTP principale, sia il trasmettitore wireless come fonti di tempo. Quando ho interrogato il mio ntpd locale, ho notato che la "scatola nera" (10.xxZ) era l'origine temporale preferita:

$ 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

Dato che 10.x.x.Zl'unica fonte di tempo del server è il server 10.x.x.X(che è lo strato 3), dovrebbe essere lo strato 4. Credo che il produttore abbia codificato il suo livello di strato.

Esiste un modo per convincere la mia macchina a favorire il server "buono" (10.xxX) nonostante sia a livello di strato superiore? Ho anche provato la preferdirettiva nel mio ntp.conffile locale , ma invano la piccola scatola nera vince sempre: /

Per quello che vale, il mio computer locale esegue 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)",

Questa domanda è sufficientemente esoterica che raccomanderei di porre invece sul newsgroup USENET comp.protocols.time.ntp, o equivalentemente sulla mailing list delle domande su lists.ntp.org . Probabilmente suggeriranno di aggiungere più server, poiché i client avranno difficoltà a decidere tra due server. Oltre a ciò, non sono sicuro di quale risposta avranno sulla manipolazione degli strati.
justarobert,

Risposte:


6

Dopo alcune ulteriori ricerche sembra "confondere" il livello di strato di una sorgente di rete non è possibile. Quindi sono passato e ho provato la risposta di dtoubeli . Con mia sorpresa, il semplice fatto di rendere il mio server dell'ora locale uno strato 2 di livello (uguale al dispositivo di terze parti) non sempre lo ha reso l'origine temporale preferita. Il mio ntpd locale li governerebbe comunque entrambi come "false tick". Per quale motivo, non ne sono sicuro, ma sto indovinando perché erano le uniche due fonti di tempo e i loro tempi erano così lontani.

Il problema più grande qui è il fatto che il mio dispositivo di terze parti non sembra contenere un tempo molto coerente, in realtà fluttua molto. La soluzione al mio problema era l'aggiunta di diverse altre fonti temporali accurate (pool.ntp.org) al mio /etc/ntp.conf. Ora il mio server locale viene sempre scelto come origine temporale preferita, spesso volte nonostante abbia un livello di strato superiore rispetto ad alcuni dei server nel pool.


4

Potresti provare a eseguire il tuo ntpd locale su strato 2. Invece di puntarlo a pool.ntp.org basta creare un elenco di 5-7 server di strato 1 e aggiungerli direttamente alla configurazione. Con il server di riferimento sullo strato 1, il tuo sarà eseguito sullo strato 2. L' preferopzione potrebbe funzionare.

Tuttavia, dalla mia esperienza, il livello dello strato non è sempre il fattore vincente nelle elezioni di fonte primaria. Penso che anche la latenza e il jitter abbiano un'influenza significativa. Avevo notato in diverse occasioni che il server dello strato inferiore era stato eletto come fonte primaria anche se c'erano diversi server dello strato superiore disponibili solo perché aveva la latenza più bassa. Questo è il motivo per cui non posso garantire che l'approccio suggerito funzionerà.


2

Ho una sorgente di tempo GPS "high stratum (10)" hardware nella nostra rete locale che mi dà uno stato di falsetick (x) in ntpq, ho scoperto che l'uso di server [x.x.x.x] true(x = indirizzo IP) in ntp.conf aggirerà il controllo del falsetick, permettendogli di essere un possibile candidato. Sembra che il numero di strato non significhi sempre una priorità più alta.


1

Se non ti piace questo server 10.xxZ come riferimento, questo dovrebbe fare il trucco:

server 10.x.x.Z noselect 

Ciò è utile se il server deve essere utilizzato solo per motivi di monitoraggio. in alternativa puoi anche configurare:

server 10.x.x.X prefer

Pertanto, 10.xxZ non verrà utilizzato se 10.xxX è disponibile.


0

Uno dei motivi per cui è preferibile che l'altro time server non sia stato raggiungibile di recente. Vedi la colonna di portata?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.