Discussion:
Zeitserver-Probleme? (NTP, Chrony, Kiss of Death)
(zu alt für eine Antwort)
Peter Schneider
2006-05-09 21:48:13 UTC
Permalink
Hallo Group,

heute morgen stellte ich fest, dass die Uhr des fli um etwa 45 Minuten vor
ging. Nanu, dachte ich da noch und mehr nicht.
Als ich dann ins Büro kam, stellte ich eine mordsmäßige Uhrenabweichung bei
einem Server fest. Ins Log des NTP-Client dort geschaut erblickte ich, dass
"pool.ntp.org" am 6.5.06 um 10:00 Uhr (!) einen "Kiss of Death" geschickt
hatte mit dem Code "STEP".

Nachgeschaut: "A step change in system time has occurred, but the
association has not yet resynchronized"
Na, sowas. Daraufhin beendete sich der NTP-Client. Seitdem lief die Uhr aus
dem Ruder.

Gemäß der entsprechenden rfc
(http://www.eecis.udel.edu/~mills/database/rfc/rfc-xxxx.pdf) ist das
Abschalten auch das vorschriftsmäßige Verhalten für NTP-Clients, denn das
Paket bedeutet: "Stop bothering me and go someplace else!" Da "pool.ntp.org"
der einzige Timerserver in der Liste der bekannten Server war, hatte sich
dann der NTP-Client beendet.

Leider weiß ich nicht, ob und wo chrony im fli4l ein Log anlegt und kann das
Verhalten deswegen nicht nachprüfen, aber ich habe den starken Verdacht,
dass das gleiche Kiss-of-Death-Paket auch auf dem fli4l den NTP-Client
lahmgelegt hat.

Dort ist die Default-Config mit "pool.ntp.org" konfiguriert.
Die Schwierigkeit scheint ja nun, dass der NTP-Client offenbar pool.ntp.org
nicht erneut anfragt, wenn er von irgendeinem NTP-Server aus dem Pool ein
Kiss-of-Death-Packet erhält.

Ist das Problem nachvollziehbar oder meint ihr, dass meine beiden
Zeitprobleme heute zufällig waren?
Hatte jemand von Euch ähnliche Probleme? Gibt es einen Vorschlag für einen
Workaround?

Zufall oder nicht: Heute abend gingen in einem Großteil von Hannover die
Straßenlaternen nicht korrekt an. Da dachte ich: Hat die Steuerung
vielleicht ebenfalls Probleme mit pool.ntp.org gehabt?

Liebe Grüße
Peter Schneider, Hannover.
Jim Meba
2006-05-10 07:12:50 UTC
Permalink
Hi,
Post by Peter Schneider
Hallo Group,
heute morgen stellte ich fest, dass die Uhr des fli um etwa 45 Minuten vor
ging. Nanu, dachte ich da noch und mehr nicht.
Als ich dann ins Büro kam, stellte ich eine mordsmäßige Uhrenabweichung bei
einem Server fest. Ins Log des NTP-Client dort geschaut erblickte ich, dass
"pool.ntp.org" am 6.5.06 um 10:00 Uhr (!) einen "Kiss of Death" geschickt
hatte mit dem Code "STEP".
pool.ntp.org sind _viele_ Server: dig pool.ntp.org
;; ANSWER SECTION:
pool.ntp.org. 581 IN A 130.206.130.95
pool.ntp.org. 581 IN A 192.36.143.153
pool.ntp.org. 581 IN A 203.63.6.1
pool.ntp.org. 581 IN A 204.9.55.254
pool.ntp.org. 581 IN A 213.28.138.38
pool.ntp.org. 581 IN A 216.52.237.153
pool.ntp.org. 581 IN A 24.130.207.189
pool.ntp.org. 581 IN A 60.56.119.79
pool.ntp.org. 581 IN A 62.236.120.71
pool.ntp.org. 581 IN A 80.48.4.3
pool.ntp.org. 581 IN A 80.242.32.5
pool.ntp.org. 581 IN A 87.75.128.50
pool.ntp.org. 581 IN A 130.102.128.23

Da kanns schon mal sein, dass einer mal etwas buggy ist.
Post by Peter Schneider
Nachgeschaut: "A step change in system time has occurred, but the
association has not yet resynchronized"
Na, sowas. Daraufhin beendete sich der NTP-Client. Seitdem lief die Uhr aus
dem Ruder.
Uuhhhps.
Post by Peter Schneider
Gemäß der entsprechenden rfc
(http://www.eecis.udel.edu/~mills/database/rfc/rfc-xxxx.pdf) ist das
Abschalten auch das vorschriftsmäßige Verhalten für NTP-Clients, denn das
Paket bedeutet: "Stop bothering me and go someplace else!" Da "pool.ntp.org"
der einzige Timerserver in der Liste der bekannten Server war, hatte sich
dann der NTP-Client beendet.
Huch?
Chrony verwendet normalerweise 3 Stück aus dem "Pool".
Nachschauen kann man dies mit "chronyc sources" auf dem Fli4l.
Aber falls einer ein KoD schickt, könnte sich Chrony einfach beenden.
Müsste man jetzt in der Doku oder gar im Source nachschauen,
wie KoD behandelt wird.
Post by Peter Schneider
Leider weiß ich nicht, ob und wo chrony im fli4l ein Log anlegt und kann das
Verhalten deswegen nicht nachprüfen, aber ich habe den starken Verdacht,
dass das gleiche Kiss-of-Death-Paket auch auf dem fli4l den NTP-Client
lahmgelegt hat.
Möglich.
Post by Peter Schneider
Dort ist die Default-Config mit "pool.ntp.org" konfiguriert.
Die Schwierigkeit scheint ja nun, dass der NTP-Client offenbar pool.ntp.org
nicht erneut anfragt, wenn er von irgendeinem NTP-Server aus dem Pool ein
Kiss-of-Death-Packet erhält.
Er sollte die spezielle IP nicht mehr nachfragen,
nicht aber den kompletten Pool.
Post by Peter Schneider
Ist das Problem nachvollziehbar oder meint ihr, dass meine beiden
Zeitprobleme heute zufällig waren?
Hatte jemand von Euch ähnliche Probleme? Gibt es einen Vorschlag für einen
Workaround?
de.pool.ntp.org verwenden ;-)

CHRONY_TIMESERVER_N='3'
CHRONY_TIMESERVER_1='de.pool.ntp.org'
CHRONY_TIMESERVER_2='de.pool.ntp.org'
CHRONY_TIMESERVER_3='de.pool.ntp.org'

Diese Server sind "dichter" dran.
Es werden dann 3 aus der Liste gewählt, und mit dem Besten der 3
synchronisiert.
Post by Peter Schneider
Zufall oder nicht: Heute abend gingen in einem Großteil von Hannover die
Straßenlaternen nicht korrekt an. Da dachte ich: Hat die Steuerung
vielleicht ebenfalls Probleme mit pool.ntp.org gehabt?
ROTFL!

-- Jim
Christian Kelinski
2006-05-10 07:48:17 UTC
Permalink
Hi,
Post by Jim Meba
de.pool.ntp.org verwenden ;-)
CHRONY_TIMESERVER_N='3'
CHRONY_TIMESERVER_1='de.pool.ntp.org'
CHRONY_TIMESERVER_2='de.pool.ntp.org'
CHRONY_TIMESERVER_3='de.pool.ntp.org'
Diese Server sind "dichter" dran.
Es werden dann 3 aus der Liste gewählt, und mit dem Besten der 3
synchronisiert.
Am besten gleich

CHRONY_TIMESERVER_1='1.de.pool.ntp.org'
CHRONY_TIMESERVER_2='2.de.pool.ntp.org'
CHRONY_TIMESERVER_3='3.de.pool.ntp.org'

da chrony die Namen gleich zu Beginn alle auf einmal auflöst und sich
dann merkt. Es ist aber nicht auszuschliessen, das zwei oder mehr zur
gleichen IP auflösen[*]. Dann ist so ein Kiss of Death wirklich tödlich,
bleiben ja weniger (oder keine) Server übrig, die antworten könnten.
Wird übrigens auch so auf www.pool.ntp.org empfohlen.

Christian

* Gerade mal mit nslookup in einem Mini-Script ausprobiert. Meist gehts
gut, mannchmal werden bei 2 von 3 nslookups gleiche IPs zurück
geliefert, das alle 3 gleich sind ist auch vorgekommen...
Peter Schneider
2006-05-10 21:09:27 UTC
Permalink
Hallo Christian, hallo Jim,

ich habe meine Chrony-Konfiguration entsprechend geändert. Vielen Dank für
die Tipps.

Was es alles für coole Fehlermöglichkeiten gibt...

Gruß
P.
Post by Christian Kelinski
Hi,
Post by Jim Meba
de.pool.ntp.org verwenden ;-)
CHRONY_TIMESERVER_N='3'
CHRONY_TIMESERVER_1='de.pool.ntp.org'
CHRONY_TIMESERVER_2='de.pool.ntp.org'
CHRONY_TIMESERVER_3='de.pool.ntp.org'
Diese Server sind "dichter" dran.
Es werden dann 3 aus der Liste gewählt, und mit dem Besten der 3
synchronisiert.
Am besten gleich
CHRONY_TIMESERVER_1='1.de.pool.ntp.org'
CHRONY_TIMESERVER_2='2.de.pool.ntp.org'
CHRONY_TIMESERVER_3='3.de.pool.ntp.org'
da chrony die Namen gleich zu Beginn alle auf einmal auflöst und sich dann
merkt. Es ist aber nicht auszuschliessen, das zwei oder mehr zur gleichen
IP auflösen[*]. Dann ist so ein Kiss of Death wirklich tödlich, bleiben ja
weniger (oder keine) Server übrig, die antworten könnten. Wird übrigens
auch so auf www.pool.ntp.org empfohlen.
Christian
* Gerade mal mit nslookup in einem Mini-Script ausprobiert. Meist gehts
gut, mannchmal werden bei 2 von 3 nslookups gleiche IPs zurück geliefert,
das alle 3 gleich sind ist auch vorgekommen...
Jim Meba
2006-05-10 07:32:04 UTC
Permalink
Hi,
Hi,
Post by Peter Schneider
Hallo Group,
heute morgen stellte ich fest, dass die Uhr des fli um etwa 45 Minuten vor
ging. Nanu, dachte ich da noch und mehr nicht.
[...]
Ist das Problem nachvollziehbar oder meint ihr, dass meine beiden
Zeitprobleme heute zufällig waren?
Hatte jemand von Euch ähnliche Probleme? Gibt es einen Vorschlag für einen
Workaround?
Nachtrag: Falls sich chronyd wirklich beendet hat (ps aux),
kann man ihn mit "chronyd -r" auf der Routerkonsole einfach neu starten.

Falls er nicht gleich online geht,
kann man ihn dann mit:
chronyc
password dummy
online
quit

"online" schicken. Normalerweise wird das in ip-up gemacht.

-- Jim
Ulrich Mietke
2006-05-10 12:08:59 UTC
Permalink
Hallo Peter, hallo *,

"Peter Schneider" schrieb ...
Post by Peter Schneider
heute morgen stellte ich fest, dass die Uhr des fli um etwa
45 Minuten vor ging. Nanu, dachte ich da noch und mehr nicht.
Als ich dann ins Büro kam, stellte ich eine mordsmäßige
Uhrenabweichung bei einem Server fest. Ins Log des NTP-Client
dort geschaut erblickte ich, dass "pool.ntp.org" am 6.5.06 um
10:00 Uhr (!) einen "Kiss of Death" geschickt hatte mit dem Code "STEP".
...
Ist das Problem nachvollziehbar oder meint ihr, dass meine beiden
Zeitprobleme heute zufällig waren?
Hatte jemand von Euch ähnliche Probleme? Gibt es einen Vorschlag für einen
Workaround?
CHRONY_TIMESERVER_1='ptbtime1.ptb.de'
CHRONY_TIMESERVER_2='ptbtime2.ptb.de'

liefert die amtliche Uhrzeit der Bundesrepublik Deutschland.


Grundsätzlich sollte man bei betriebsnotwendigen Daten auf eine
vertrauenswürdige Quelle achten. Die Auswahl einem Anderen zu überlassen ist
in diesem Fall keine gute Idee.
Post by Peter Schneider
Zufall oder nicht: Heute abend gingen in einem Großteil von Hannover die
Straßenlaternen nicht korrekt an. Da dachte ich: Hat die Steuerung
vielleicht ebenfalls Probleme mit pool.ntp.org gehabt?
Unwahrscheinlich. Die haben einige eigene Mutteruhren die sich mit der PTB
synchronisieren.

Gruß
Uli
Jim Meba
2006-05-10 23:09:49 UTC
Permalink
Hi,
Post by Ulrich Mietke
CHRONY_TIMESERVER_1='ptbtime1.ptb.de'
CHRONY_TIMESERVER_2='ptbtime2.ptb.de'
liefert die amtliche Uhrzeit der Bundesrepublik Deutschland.
Du kennst die Policy von ptbtime*.ptb.de?
Wenn die jeder benutzen würde, wären sie dauernd überlastet.
Deswegen gibt es den Pool bei ntp.org.
Post by Ulrich Mietke
Grundsätzlich sollte man bei betriebsnotwendigen Daten auf eine
vertrauenswürdige Quelle achten. Die Auswahl einem Anderen zu überlassen ist
in diesem Fall keine gute Idee.
Sooo unzuverläsig ist pool.ntp.org nicht.

-- Jim

Loading...