/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
NTP opsætning
Fra : Michael Jenner


Dato : 16-06-02 20:44

Hvis man ikke ønsker at sync' ud-af-huset hvordan kan opsætningen så se ud?

Jeg har overvejet følgende opsætning:

3 lokale servere.

ntp1.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
peer ntp2.lan
peer ntp3.lan

ntp2.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
peer ntp1.lan
peer ntp3.lan

ntp3.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
peer ntp1.lan
peer ntp2.lan

Til mit formål er PC uret tilstrækkeligt nøjagtigt - så umiddelbart
syntes det at være en fornuftig løsning.

Kommentarer udbedes mht.:

1. Opsætningen generelt.

2. Kan man automatisk få ntp til at informere hvis et af urene kommer ud
af trit med de andre?

3. Kan man, via cron job, få ntpdate til at hente mere korrekt tid fra
ntp server uden for huset og automatisk opdatere tiden på de tre
ntp-servere. Det strider vist imod ntp's måde at fungere på, men ville
IMHO være en god feature. Jeg forestiller mig noget i retning af
følgende script:

/etc/init.d/ntp stop
ntpdate ntp1.tele.dk
/etc/init.d/ntp start

og tilsvarende på de øvrige to lokale ntp servere - blot tilgår de "kun"
den der har adgang ud af huset:

ntp1.lan --> Internet
ntp2.lan --> ntp1.lan
ntp3.lan --> ntp2.lan

Man kan så placere ntp1.lan i DMZ eller lignende.

Mvh Michael


 
 
Hans Jørgen Jakobsen (17-06-2002)
Kommentar
Fra : Hans Jørgen Jakobsen


Dato : 17-06-02 07:49

On Sun, 16 Jun 2002 21:44:21 +0200, Michael Jenner wrote:
> Hvis man ikke ønsker at sync' ud-af-huset hvordan kan opsætningen så se ud?
>
> Jeg har overvejet følgende opsætning:
>
> 3 lokale servere.
>
> ntp1.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> peer ntp2.lan
> peer ntp3.lan
>
> ntp2.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> peer ntp1.lan
> peer ntp3.lan
>
> ntp3.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> peer ntp1.lan
> peer ntp2.lan
>
> Til mit formål er PC uret tilstrækkeligt nøjagtigt - så umiddelbart
> syntes det at være en fornuftig løsning.
Du skal være opmærksom på at der er 2 ure i en PC.
1) TOD chip "BIOS" klokken, som kun bruges ved opstart.
2) Operativsystem klokken som vedligeholde af OS.
1 er ofte meget mere nøjagtig end 2.
(Der kan i OS være noget interaktion mellem 1 og 2 men det
kan oftest bringes til at fungere som man ønsker)
>
> Kommentarer udbedes mht.:
>
> 1. Opsætningen generelt.
Ret stratum til 8 10 12. Så opnår du at der er en som styrer de andre.
I ovenstående vil de ikke synkronisere til hinanden da de andre ikke vil
være bedre den den selv.

>
> 2. Kan man automatisk få ntp til at informere hvis et af urene kommer ud
> af trit med de andre?
Normalt er det ikke et problem når først NTP kører. Du kan evt enable
statistikker (peerstats).

> 3. Kan man, via cron job, få ntpdate til at hente mere korrekt tid fra
> ntp server uden for huset og automatisk opdatere tiden på de tre
> ntp-servere. Det strider vist imod ntp's måde at fungere på, men ville
> IMHO være en god feature. Jeg forestiller mig noget i retning af
> følgende script:
>
> /etc/init.d/ntp stop
> ntpdate ntp1.tele.dk
> /etc/init.d/ntp start
>
Jeg vil nu nok foretrække at have det kørende hele tiden. Der skal under
alle omstændigheder laves hul i FW.
Brug også ntp2.tele.dk aht redundans.
Det er vigtigt at få lavet en drifts-file så ntpd ved hvad frevensfejlen er på
maskinen.
> og tilsvarende på de øvrige to lokale ntp servere - blot tilgår de "kun"
> den der har adgang ud af huset:
NEJ lad være med det. det klarer ntpd! (Medmindre diff > ca. 1000 sec.)

/hjj

Michael Jenner (20-06-2002)
Kommentar
Fra : Michael Jenner


Dato : 20-06-02 21:53

Hans Jørgen Jakobsen wrote:
> On Sun, 16 Jun 2002 21:44:21 +0200, Michael Jenner wrote:
>
>>Hvis man ikke ønsker at sync' ud-af-huset hvordan kan opsætningen så se ud?
>>
>>Jeg har overvejet følgende opsætning:
>>
>>3 lokale servere.
>>
>>ntp1.lan:
>>-----------------
>>server 127.127.1.0
>>fudge 127.127.1.0 stratum 10
>>peer ntp2.lan
>>peer ntp3.lan
>>
>>ntp2.lan:
>>-----------------
>>server 127.127.1.0
>>fudge 127.127.1.0 stratum 10
>>peer ntp1.lan
>>peer ntp3.lan
>>
>>ntp3.lan:
>>-----------------
>>server 127.127.1.0
>>fudge 127.127.1.0 stratum 10
>>peer ntp1.lan
>>peer ntp2.lan
>>
>>Kommentarer udbedes mht.:
>>
>>1. Opsætningen generelt.
>
> Ret stratum til 8 10 12. Så opnår du at der er en som styrer de andre.
> I ovenstående vil de ikke synkronisere til hinanden da de andre ikke vil
> være bedre den den selv.

Fordelen ved den løsning er selvfølgelig at man er sikker på at serverne
er i sync, og at man kun skal stille uret et sted. Men alle urene går
forkert hvis stratum 8 uret går forkert.

Ved at ntp serverne har samme stratum vil de få samme vægt hos
klienterne og sandsynligheden for at urene på klienterne går korrekt er
noget bedre. Ulempen er selvfølgelig at man skal holde øje med urene på
de tre servere.

Ved at bruge server 127.127.1.0 bruger man vel hardware uret i maskinen?
- eller er det o.s. uret?

>>2. Kan man automatisk få ntp til at informere hvis et af urene kommer ud
>>af trit med de andre?
>
> Normalt er det ikke et problem når først NTP kører. Du kan evt enable
> statistikker (peerstats).

Dokumentationen er ikke fantastisk ... heller ikke på det punkt. Mere
detaljerede input er velkomne. Man kan selvfølgelig altid bruge ntpdate
og lade et bash script lave lidt statistik - hvis største difference er
større end xxx sekunder så gives besked via email ... men eh ...

Mvh Michael


Michael Jenner (20-06-2002)
Kommentar
Fra : Michael Jenner


Dato : 20-06-02 22:01

Forøvrigt. Hvor meget trafik genererer et NTP system?

F.eks. med anvendelse af 3 lokale ntp servere og 6 forskellige externe
ntp servere, som det anbefales at bruge i dok.

Jeg er klar over at de 3 lokale kun bruger en extern "aktivt" hver især,
og at de andre er backup. Men hvor tit checkes ud af huset om backup ntp
serveren er bedre?

Det kan IMHO virke lidt som spild af god båndbredde at bruge "for meget"
krudt på ntp.

Mvh Michael


Karsten Thygesen (21-06-2002)
Kommentar
Fra : Karsten Thygesen


Dato : 21-06-02 11:44

Michael Jenner <mj@kom.auc.dk> writes:

> Forøvrigt. Hvor meget trafik genererer et NTP system?
>
> F.eks. med anvendelse af 3 lokale ntp servere og 6 forskellige externe
> ntp servere, som det anbefales at bruge i dok.
>
> Jeg er klar over at de 3 lokale kun bruger en extern "aktivt" hver
> især, og at de andre er backup. Men hvor tit checkes ud af huset om
> backup ntp serveren er bedre?
>
> Det kan IMHO virke lidt som spild af god båndbredde at bruge "for
> meget" krudt på ntp.

Det er ikke tit. Med ntpq kan du spørge den, hvor ofte den farer
ud. Efter tiden er faldet lidt på plads, så er den helt nede på typisk
en pakke for hver 1024'ende sekund til både de primære og sekundære
kilder.

Det er intet....

Karsten

Michael Jenner (23-06-2002)
Kommentar
Fra : Michael Jenner


Dato : 23-06-02 08:59

Karsten Thygesen wrote:
> Michael Jenner <mj@kom.auc.dk> writes:
>
>
>>Forøvrigt. Hvor meget trafik genererer et NTP system?
>>
>>F.eks. med anvendelse af 3 lokale ntp servere og 6 forskellige externe
>>ntp servere, som det anbefales at bruge i dok.
>>g
>>Jeg er klar over at de 3 lokale kun bruger en extern "aktivt" hver
>>især, og at de andre er backup. Men hvor tit checkes ud af huset om
>>backup ntp serveren er bedre?
>>
>>Det kan IMHO virke lidt som spild af god båndbredde at bruge "for
>>meget" krudt på ntp.
>
>
> Det er ikke tit. Med ntpq kan du spørge den, hvor ofte den farer
> ud. Efter tiden er faldet lidt på plads, så er den helt nede på typisk
> en pakke for hver 1024'ende sekund til både de primære og sekundære
> kilder.
>
> Det er intet....
>
> Karsten

Det er jo intet ... bortset fra på et ISDN dial-up netværk hvor man
ønsker at begrænse usynkroniserede services fra periodisk at åbne
linien. Jeg har checket op på det og det ser ud til at man kan ændre
defaults med minpoll og maxpoll - f.eks:

server ntp1.tele.dk burst minpoll 17 maxpoll 10

Giver noget i retning af hyppigste check ud af huset er hvert 2^10
sekund ~= 17. minutter og langsomste poll noget med 2^17 ~= 36 timer -
hvilket skulle være rigeligt.

Mvh Michael


Hans Jørgen Jakobsen (21-06-2002)
Kommentar
Fra : Hans Jørgen Jakobsen


Dato : 21-06-02 20:38

On Thu, 20 Jun 2002 22:52:30 +0200, Michael Jenner wrote:
> Hans Jørgen Jakobsen wrote:
>> On Sun, 16 Jun 2002 21:44:21 +0200, Michael Jenner wrote:
>>
>
> Fordelen ved den løsning er selvfølgelig at man er sikker på at serverne
> er i sync, og at man kun skal stille uret et sted. Men alle urene går
> forkert hvis stratum 8 uret går forkert.
Men de går ens og det er ofte det vigtigste at man kan sammenligne tidsstempler
på tværs af maskiner uden at skulle til at lave en større udredning af hvor
meget forkert en given klokke var på et givet tidspunkt.
>
> Ved at ntp serverne har samme stratum vil de få samme vægt hos
> klienterne og sandsynligheden for at urene på klienterne går korrekt er
> noget bedre. Ulempen er selvfølgelig at man skal holde øje med urene på
> de tre servere.
Man vil ofte foretrække at der bliver synkroniseret til den samme hele tiden.
Ellers kan man risikere at ntpd står og hopper mellem servere med samme stratum.
Du kan IKKE lave noget der er bedre ntpd til at hold tiden synkroniseret!
>
> Ved at bruge server 127.127.1.0 bruger man vel hardware uret i maskinen?
> - eller er det o.s. uret?
OS
>
>>>2. Kan man automatisk få ntp til at informere hvis et af urene kommer ud
>>>af trit med de andre?
>>
>> Normalt er det ikke et problem når først NTP kører. Du kan evt enable
>> statistikker (peerstats).
>
> Dokumentationen er ikke fantastisk ... heller ikke på det punkt. Mere
> detaljerede input er velkomne. Man kan selvfølgelig altid bruge ntpdate
> og lade et bash script lave lidt statistik - hvis største difference er
> større end xxx sekunder så gives besked via email ... men eh ...
>
Her er nogle linier jeg har brugt på en xntpd server (version 3)
statsdir /home/hjj/ntpstat/
statistics loopstats peerstats
filegen loopstats file loopstats type day link enable
filegen peerstats file peerstats type day link enable
Jeg ved ikke om de virker på ntpd (version 4)

Det letteste er nu at lade ntp gøre arbejdet i stedet for at opfinde nogle
specielle opsætninger.
/hjj


Michael Jenner (23-06-2002)
Kommentar
Fra : Michael Jenner


Dato : 23-06-02 08:59

Hans Jørgen Jakobsen wrote:
> On Thu, 20 Jun 2002 22:52:30 +0200, Michael Jenner wrote:
>
>>Hans Jørgen Jakobsen wrote:
>>
>>>On Sun, 16 Jun 2002 21:44:21 +0200, Michael Jenner wrote:
>>>
>>
>>Fordelen ved den løsning er selvfølgelig at man er sikker på at serverne
>>er i sync, og at man kun skal stille uret et sted. Men alle urene går
>>forkert hvis stratum 8 uret går forkert.
>
> Men de går ens og det er ofte det vigtigste at man kan sammenligne tidsstempler
> på tværs af maskiner uden at skulle til at lave en større udredning af hvor
> meget forkert en given klokke var på et givet tidspunkt.

Enig.

>>Ved at ntp serverne har samme stratum vil de få samme vægt hos
>>klienterne og sandsynligheden for at urene på klienterne går korrekt er
>>noget bedre. Ulempen er selvfølgelig at man skal holde øje med urene på
>>de tre servere.
>
> Man vil ofte foretrække at der bliver synkroniseret til den samme hele tiden.
> Ellers kan man risikere at ntpd står og hopper mellem servere med samme stratum.
> Du kan IKKE lave noget der er bedre ntpd til at hold tiden synkroniseret!

Jeg forsøger vel egenligt heller ikke at bruge noget alternativt til ntp
- jeg prøver blot at bruge ntp uden højkvalitets tidskilde (gps,
radio-styret eller lignende) ... men jeg er efterhånden kommet til den
konklusion at sikkerhedsproblemet med ntp næppe er så stort at det er
besværet værd.

I hvilken situation vil ntpd begynde at hoppe mellem servere?

Tak for de mange input. Jeg tror jeg er landet på følgende konfiguration:

ntp1.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 8
peer ntp2.lan
peer ntp3.lan
server ntp1.tele.dk minpoll 17 maxpoll 16
server ntp2.tele.dk minpoll 17 maxpoll 16

ntp2.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
peer ntp1.lan
peer ntp3.lan

ntp3.lan:
-----------------
server 127.127.1.0
fudge 127.127.1.0 stratum 12
peer ntp1.lan
peer ntp2.lan

Fælles for alle:
--------------------
statistics loopstats peerstats
filegen loopstats file loopstats type day link enable
filegen peerstats file peerstats type day link enable
restrict default notrust nomodify
restrict ntp1.lan nomodify
restrict ntp2.lan nomodify
restrict ntp3.lan nomodify
restrict ntp1.tele.dk nomodify
restrict ntp2.tele.dk nomodify
restrict 127.0.0.1

Og så åbner jeg firewall for adgang mellem ntp1/2.tele.dk og ntp1.lan,
udp port 123 i begge retninger.

Og overvejer om bøvlet med keys are besværet værd?

Men i og med ntp2.lan og ntp3.lan ikke har adgang til en lav-stratums
server bliver de vel nærmest degraderede til klienter og jeg kan ikke se
fordelen ved at de indgår som peer med ntp1.lan?

- Bortset fra at konfigurationen nu har mindst 3 lokale servere som
anbefalet i dokumentationen, og i den sjældne situation hvor tele dk's
net er nede i mere end 36 timer Eller i den situation hvor ntp1.lan
er nede i længere tid. Andre?

Når jeg får en ADSL løsning ændrer jeg minpoll og maxpoll tilbage til
default.

Mvh Michael


Hans Jørgen Jakobsen (24-06-2002)
Kommentar
Fra : Hans Jørgen Jakobsen


Dato : 24-06-02 20:37

On Sun, 23 Jun 2002 09:58:53 +0200, Michael Jenner wrote:
> Hans Jørgen Jakobsen wrote:
>
> I hvilken situation vil ntpd begynde at hoppe mellem servere?
Når der er en række servere med samme stratum, som er næsten
lige gode.
>
> Tak for de mange input. Jeg tror jeg er landet på følgende konfiguration:
>
> ntp1.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 8
> peer ntp2.lan
> peer ntp3.lan
> server ntp1.tele.dk minpoll 17 maxpoll 16
> server ntp2.tele.dk minpoll 17 maxpoll 16

Jeg ville umiddelbart tro at minpoll skulle være <= maxpoll.

En sideeffekt vil være at tid til første synkronisering vil være
5*2^17 sekunder. (Der skal laves 5 (4?) poll inden ntpd tror
den ved hvad klokken er)

Hvis drift i pollperiode overstiger 128 ms vil
den nok aldrig synkronisere fordi offset bliver for stor. Det kan
du risikere hvis du starter med en ukalibreret maskine.

Forslag: Start uden minpoll parameter. Hvis det kører ordentlig
vil poll alligevel hurtigt kravle op.

Hvis du har en opkaldt forbindelse:
Se på burst parameter. (jeg har ingen erfaring)
Man kan også overveje at lave det sådan at ntp pakker
IKKE kan bringe forbindelse op. evt kombineret med at
man sætter et lavt maxpoll, så man er sikker på at
man får sendt nogen ntppakker når forbindelsen kommer
op i anden anledning.
> ntp2.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> peer ntp1.lan
> peer ntp3.lan
>
> ntp3.lan:
> -----------------
> server 127.127.1.0
> fudge 127.127.1.0 stratum 12
> peer ntp1.lan
> peer ntp2.lan
>
> Fælles for alle:
> --------------------
> statistics loopstats peerstats
> filegen loopstats file loopstats type day link enable
> filegen peerstats file peerstats type day link enable
> restrict default notrust nomodify
> restrict ntp1.lan nomodify
> restrict ntp2.lan nomodify
> restrict ntp3.lan nomodify
> restrict ntp1.tele.dk nomodify
> restrict ntp2.tele.dk nomodify
> restrict 127.0.0.1
man side antyder at man ikke kan bruge symbolske navne i restrict
(http://www.eecis.udel.edu/~ntp/ntp_spool/html/accopt.htm)

Da der engang var en fejl i ntpd var en del af standardkonfigurationen:
restrict default noquery
restrict 127.0.0.1

ie noquery isf nomodify
Det ville jeg i det mindste gøre mod de externe servere.
(Og som administrator af ntp1/2.tele.dk vil vi normalt ikke give os til
at lave queries mod klienter, så det generer ikke mig

>
> Men i og med ntp2.lan og ntp3.lan ikke har adgang til en lav-stratums
> server bliver de vel nærmest degraderede til klienter og jeg kan ikke se
> fordelen ved at de indgår som peer med ntp1.lan?

Det kan godt være at du har et point der.
(det er muligt at der i opstartsfasen af ntp1.lan vil være synkronisering
med ntp2/3.lan)
(Jeg kommer iøvrigt i tvivl om der skal en prefer på fudge statement.
Måske er det kun når man skal til at lege med broadcast?)

Iøvrigt skal du i start af ntp1.lan have en
ntpdate ntp1.tele.dk ntp2.tele.dk ntp2.lan ntp3.lan
(det vil sikre at klokken hives nogenlunde på plads inden ntpd startes)
/hjj

Michael Jenner (25-06-2002)
Kommentar
Fra : Michael Jenner


Dato : 25-06-02 00:07

Hans Jørgen Jakobsen wrote:
> On Sun, 23 Jun 2002 09:58:53 +0200, Michael Jenner wrote:
>
>>Hans Jørgen Jakobsen wrote:
>>
>>I hvilken situation vil ntpd begynde at hoppe mellem servere?
>
> Når der er en række servere med samme stratum, som er næsten
> lige gode.

Ok, men jeg skulle vist have spurgt: Er det et problem? Det burde IMHO
ikke være et problem for ntp, altså at den har adgang til næsten lige
gode tids-servere. Det burde nærmere være en fordel? Med mindre urene
ser lige gode ud, men er meget forskellige ... som indrømmet måske kan
forekomme hvis man opretter et lokalt netværk udelukkende baseret på pc ure.

>>Tak for de mange input. Jeg tror jeg er landet på følgende konfiguration:
>>
>>ntp1.lan:
>>-----------------
>>server 127.127.1.0
>>fudge 127.127.1.0 stratum 8
>>peer ntp2.lan
>>peer ntp3.lan
>>server ntp1.tele.dk minpoll 17 maxpoll 16
>>server ntp2.tele.dk minpoll 17 maxpoll 16
>
>
> Jeg ville umiddelbart tro at minpoll skulle være <= maxpoll.

Ups ja, det burde være:

server ntp1.tele.dk burst minpoll 16 maxpoll 17
server ntp2.tele.dk burst minpoll 16 maxpoll 17

> En sideeffekt vil være at tid til første synkronisering vil være
> 5*2^17 sekunder. (Der skal laves 5 (4?) poll inden ntpd tror
> den ved hvad klokken er)

Ok, det er jo ikke optimalt. En bedre opsætning er nok:

minpoll 6 maxpoll 17

> Hvis drift i pollperiode overstiger 128 ms vil
> den nok aldrig synkronisere fordi offset bliver for stor. Det kan
> du risikere hvis du starter med en ukalibreret maskine.

Ja, det kan jeg godt se kan være et problem. Jeg mener at have læst at
offset større end 1000 s (sanity level) bevirker at ntp opgiver at
synkronisere. Hvis jeg forstår det korrekt er risikoen ved en for høj
maxpoll at en stor drift kan bevirke at "skidtet" holder op med at
synkronisere. Det ville være rart med et par user-alert features i ntp
men ... Minimums krav til pc urene må være:

1000 / 2^17 = 7.6 ms per sekund (maksimalt tilladelig drift per sekund)
1000 / 2^13 = 122 ms per sekund
1000 / 2^10 = 977 ms per sekund

Og hvis man misser blot en enkelt pakke så bliver kravene endnu skrappere.

Det kan godt være jeg skal holde mig fra maxpoll på 17 - hvis ovennævnte
er sandt. Jeg ender snart på default poll parametre:

minpoll 6 maxpoll 10

Det virker som om de er ret fornuftigt valgte

Hvad er typisk drift for et alm. pc ur? (Jeg har endnu ikke en ntp kørende)

> Forslag: Start uden minpoll parameter. Hvis det kører ordentlig
> vil poll alligevel hurtigt kravle op.
>
> Hvis du har en opkaldt forbindelse:
> Se på burst parameter. (jeg har ingen erfaring)

Ja den virker oplagt til formålet.

> Man kan også overveje at lave det sådan at ntp pakker
> IKKE kan bringe forbindelse op. evt kombineret med at

Med ip filtre? Det kræver vist at ip filtrene kan kigge på mere end
afsender/modtager adresser og protokol type.

> man sætter et lavt maxpoll, så man er sikker på at
> man får sendt nogen ntppakker når forbindelsen kommer
> op i anden anledning.

God ide, det vil jeg prøve.

>>restrict ntp1.tele.dk nomodify
>>restrict ntp2.tele.dk nomodify
>>restrict 127.0.0.1
>
> man side antyder at man ikke kan bruge symbolske navne i restrict
> (http://www.eecis.udel.edu/~ntp/ntp_spool/html/accopt.htm)

Jeg vidste det egenligt godt - det var lettere at skrive med navne.

> Da der engang var en fejl i ntpd var en del af standardkonfigurationen:
> restrict default noquery
> restrict 127.0.0.1
>
> ie noquery isf nomodify
> Det ville jeg i det mindste gøre mod de externe servere.
> (Og som administrator af ntp1/2.tele.dk vil vi normalt ikke give os til
> at lave queries mod klienter, så det generer ikke mig

Hehe ... interessant oplysning der! Det gør jo ikke denne snak mindre
interessant, tværtimod

Lyder som et godt forslag - så vidt jeg lige kunne læse er noquery mere
begrænsende end nomodify så ja.

>>Men i og med ntp2.lan og ntp3.lan ikke har adgang til en lav-stratums
>>server bliver de vel nærmest degraderede til klienter og jeg kan ikke se
>>fordelen ved at de indgår som peer med ntp1.lan?
>
> Det kan godt være at du har et point der.
> (det er muligt at der i opstartsfasen af ntp1.lan vil være synkronisering
> med ntp2/3.lan)
> (Jeg kommer iøvrigt i tvivl om der skal en prefer på fudge statement.
> Måske er det kun når man skal til at lege med broadcast?)

Fra dokumentationen (driver 127.127.1.x):

In the default mode the behavior of the clock selection algorithm is
modified when this driver is in use. The algorithm is designed so that
this driver will never be selected unless no other discipline source
is available. This can be overridden with the prefer keyword of the
server configuration command, in which case only this driver will be
selected for synchronization and all other discipline sources will be
ignored. This behavior is intended for use when an external discipline
source controls the system clock.

Det lyder ikke som om jeg skal bruge prefer, da den så sætter alm. ntp
opførsel ud af kraft. Så vidt jeg kan se giver konfigurationen nu
følgende situation:

ntp1.lan (stratum 8) bruger ntp1.tele.dk eller ntp2.tele.dk (den anden
som første backup), og den har ntp2.lan, ntp3.lan og pc uret som backup
(hhv. 2., 3. og 4. backup-mulighed).

ntp2.lan (stratum 10) bruger ntp1.lan, ntp3.lan som første backup, pc
uret som sidste backup.

ntp3.lan (stratum 12) bruger ntp1.lan, ntp2.lan som første backup, pc
uret som sidste backup.

De lokale klienter bruger ntp1.lan, ntp2.lan som første backup, ntp3.lan
som sidste backup-mulighed.

Men hvad sker der i det øjeblik ntp1.tele.dk og ntp2.tele.dk ikke er
tilgængelige? ntp1.lan havde før stratum 2 (1+ntp1.tele.dk) - vil den
degradere sit stratum? Og de andre ntp servere vil måske også degradere
deres stratum? Måske indtil de finder ud af at der ikke findes nogle
disciplinerede ure - og pc uret i ntp1.lan vil vinde, hvorefter stratum
vil blive ntp1.lan(8), ntp2.lan(9) og ntp3.lan(9), eller?

Omvendt ser det ud til at "prefer" udelukker alle andre end pc uret,
inklusiv ntp1.tele.dk og ntp2.tele.dk, hvorfor det ikke virker som en
option.

Iøvrigt indikerer ovenstående text fra dok. at man faktisk skal køre med
mindst 4 lokale ntp servere som indgår i et peer netværk - for at de
hver især har adgang til mindst 3 servere - da uret i hver enkelt host
ikke også indgår.

Jeg er efterhånden tilbage i en mere minimalistisk opsætning:

ntp1.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 8
server ntp1.tele.dk
server ntp2.tele.dk

ntp2.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server ntp1.lan
peer ntp3.lan

ntp3.lan
--------
server 127.127.1.0
fudge 127.127.1.0 stratum 12
server ntp1.lan
peer ntp2.lan

+restrict linier.

Om ntp3.lan er med eller ej, betyder vist ikke det store.

Hvis man har to subnet med usikker forbindelse kan serverne med fordel
anbringes:

Subnet#1 (med adgang til Internet): ntp1.lan
Subnet#2 (uden adgang til Internet): ntp2.lan og ntp3.lan

> Iøvrigt skal du i start af ntp1.lan have en
> ntpdate ntp1.tele.dk ntp2.tele.dk ntp2.lan ntp3.lan
> (det vil sikre at klokken hives nogenlunde på plads inden ntpd startes)

Ja, det kan fint indbygges i /etc/init.d/ntp scriptet.

Mvh Michael


Hans Jørgen Jakobsen (25-06-2002)
Kommentar
Fra : Hans Jørgen Jakobsen


Dato : 25-06-02 22:05

On Tue, 25 Jun 2002 01:06:51 +0200, Michael Jenner wrote:
> Hans Jørgen Jakobsen wrote:
>> On Sun, 23 Jun 2002 09:58:53 +0200, Michael Jenner wrote:
>>
>>>Hans Jørgen Jakobsen wrote:
>>>
>>>I hvilken situation vil ntpd begynde at hoppe mellem servere?
>>
>> Når der er en række servere med samme stratum, som er næsten
>> lige gode.
>
> Ok, men jeg skulle vist have spurgt: Er det et problem? Det burde IMHO
> ikke være et problem for ntp, altså at den har adgang til næsten lige
> gode tids-servere. Det burde nærmere være en fordel? Med mindre urene
> ser lige gode ud, men er meget forskellige ... som indrømmet måske kan
> forekomme hvis man opretter et lokalt netværk udelukkende baseret på pc ure.
Man finder ud af hen af vejen om det er et problem.
>
(lidt for meget klippet væk)
>
> Ja, det kan jeg godt se kan være et problem. Jeg mener at have læst at
> offset større end 1000 s (sanity level) bevirker at ntp opgiver at
> synkronisere. Hvis jeg forstår det korrekt er risikoen ved en for høj
> maxpoll at en stor drift kan bevirke at "skidtet" holder op med at
> synkronisere. Det ville være rart med et par user-alert features i ntp
> men ... Minimums krav til pc urene må være:
>
> 1000 / 2^17 = 7.6 ms per sekund (maksimalt tilladelig drift per sekund)
> 1000 / 2^13 = 122 ms per sekund
> 1000 / 2^10 = 977 ms per sekund
(læs lige den linie igen: 977 ms pr 1000 ms
>
1000 sekunder er grænsen for at ntpd exiter.
Når offset overstiger 128 ms vil klokken bliver "reset" (efter en mindre
justering af driftværdien) og forsøg på synkronisering starter helt forfra.
Så hvis ( drift i (5 *pollinterval) ) > 128 ms vil man ser hop i tiden.

ntpd vil have drift (frekvensfejl) mindre end 500 ppm.
Det kan være en god ide inden man starter ntpd op at bruge ntpdate til at
checke at drift er mindre en 500 ppm og beregne en værdi til at putte i
driftfile. Et par ntpdate med nogen timers mellemrum giver et godt estimat.
Hvis drift er over 500 ppm kan der være behov for at lege med tickadj.

ntpd kan let være op til et døgn om at få sig skudt ind en fornuftig
driftværdi hvis den er langt fra startværdien (0.0)
>
> Men hvad sker der i det øjeblik ntp1.tele.dk og ntp2.tele.dk ikke er
> tilgængelige? ntp1.lan havde før stratum 2 (1+ntp1.tele.dk) - vil den
> degradere sit stratum? Og de andre ntp servere vil måske også degradere
> deres stratum? Måske indtil de finder ud af at der ikke findes nogle
> disciplinerede ure - og pc uret i ntp1.lan vil vinde, hvorefter stratum
> vil blive ntp1.lan(8), ntp2.lan(9) og ntp3.lan(9), eller?

Jeps bortset fra at stratum af ntp1.lan bliver 9 fordi der også bliver
lagt 1 til den interne klokkes stratum. (Og stratum af den interne klokke
i ntp2.lan er sat til 10 for at den ikke skal konkurrere med ntp1.lan)

>
> Om ntp3.lan er med eller ej, betyder vist ikke det store.
Kun som den sidste mulighed for synkronisering.
fx hvis man mister forbindelsen til Internettet og ntp1.lan og ntp2.lan
går ned. Ved genstart kan de synkronisere til ntp3.lan.

/hjj

N/A (30-06-2002)
Kommentar
Fra : N/A


Dato : 30-06-02 11:48



Hans Jørgen Jakobsen (30-06-2002)
Kommentar
Fra : Hans Jørgen Jakobsen


Dato : 30-06-02 11:48

On Wed, 26 Jun 2002 22:58:15 +0200, Michael Jenner wrote:
> Hans Jørgen Jakobsen wrote:
>
>> Når offset overstiger 128 ms vil klokken bliver "reset" (efter en mindre
>> justering af driftværdien) og forsøg på synkronisering starter helt forfra.
>> Så hvis ( drift i (5 *pollinterval) ) > 128 ms vil man ser hop i tiden.
>
> "Reset", vil det sige at o.s. uret stilles af ntp? - hvorefter synk.
> algoritmen starter forfra.
Ja
>
> Hvor tit opdaterer ntp egenligt o.s. uret? Efter hvert poll? Hvis
> nødvendigt?
Næppe efter hver poll da en ntpd kan have mange peer/servers.
Lidt læsning på hvordan loopfilteret virker (rfc1305)vil måske^H^H^H^H^H
give et svar.
Såvidt jeg husker/gætter er der en tidskonstant der dynamisk justeres
som giver hvor hurtigt ntpd er til at ændre tiden.
>
>
>> ntpd vil have drift (frekvensfejl) mindre end 500 ppm.
>
> Hvad sker der hvis den ikke har det? Exit'er den?
Kun exit hvis over 1000 sec. Ellers reset når over 128 ms.
>
>
>> Hvis drift er over 500 ppm kan der være behov for at lege med tickadj.
>
> Ok, så man speeder o.s. uret op (eller ned) med tickadj? Eller er det
> ntp's opdatering af o.s. uret?
Der er forskellige impl. af klokken i kernen.
Nogle kører med et tick(interupt) ca hvert 10 ms. I den forbindelse er der en
variable som siger hvormange microsekunder uret skal forøges med (typisk 10000).
Ved at justere den kan den værste frekvensfejl fjernes.
Har dog ikke haft nødvendigt at justere på nyere hurtigere maskiner.
/hjj

Søg
Reklame
Statistik
Spørgsmål : 177557
Tips : 31968
Nyheder : 719565
Indlæg : 6408886
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste