ntpd: time correction [...] exceeds sanity limit???

[7.e.Q]

Hallo,

ich versuche gerade, auf meinen Systemen hier eine Zeitsynchronisation hinzustellen. Aber der NTP Daemon auf dem Client System kackt immer ab mit folgender Fehlermeldung im Log:



19 Jul 11:31:07 ntpd[675]: frequency initialized -224.321 PPM from /var/cache/ntp.drift
19 Jul 11:35:26 ntpd[675]: synchronized to 136.1.255.7, stratum=2
19 Jul 11:42:58 ntpd[675]: time correction of 63158401 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.



letzteres hab ich getan. Ich hab die Uhr manuell mit der des Time Servers abgeglichen (der Time Server ist ein Windowsrechner hier im LAN), also mir die Uhr angeschaut und sie im Linux manuell gestellt. Jetzt soll der NTP die Uhren synchronisieren und beendet sich mit oben genannter Fehlermeldung. Das kann aber gar nicht sein, daß der da 63mio Sekunden korrigieren muss. Das ist völliger Unsinn.

Was läuft da verkehrt?

[pitu]

schick doch mal deine ntp.conf, aber bitte in "code" anstatt in "quote"

[7.e.Q]

Quote? Hö? Benutze ich doch gar nicht... egal... :ugly:

doa:



#NTP Configuration

server 136.1.255.1
server 136.1.255.7
server 136.1.255.27

logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift

[pitu]

ne, ich sags nur zur vorsicht. Die Ausgaben von irgendwelchen dingen am PC kann man dann besser lesen, als in quote oder gar nur kopiert, wie es viele machen...

Tja, das sieht doch sehr sehr gut aus ... pass mal auf, nimm mal folgende config und stell die dann irgendwann mal auf deine server um:



server 130.149.17.21 burst minpoll 12 maxpoll 13

logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift


zur Erläuterung: das Ding sind oeffentliche Server und es ist recht ... sagen wir unhöflich dort alle paar minuten oder gar sekunden anzuklopfen.

Deswegen minpoll und maxpoll diese option basiert auf 2 und verdoppelt sich so und so oft, also minpoll 12 heist 12 mal 2 verdoppelt, maxpoll 13 also 13 mal verdoppelt, damit hast du 4096 Sekunden bei minpoll 12, also ca. jede Stunde mindestens eine Abfrage und 8192 Sekunden bei maxpoll 13 also etwas mahr als alle 2 Stunden spätestens.

burts heisst, dass er alle 8 Anfragen die er sendet um drift und jitter usw zu bestimmen ziemlich schnell hintereinander sendet. War ursprünglich für modemkonfig gedacht.

schau dir dann mal den befehl "ntpq" an, gib da mal "peers" ein, da kannst du dann deinen server beobachten ...

Spaeter stellst du dann deine hauseigenen server dazu und noch spaeter nimmst du den oeffentlichen raus, wenn du es so haben willst ... oder lass ihn mit drin, schadet ja nix, nur dreh di minpoll beim oeffentlichen bitte nicht nach unten, in der vergangenheit wurden viele oeffentliche timeserver abgeschaltet, weil die netzlast durch unbedachte nutzer zu hoch war.

[7.e.Q]

Hmm... okay, probier ich so mal aus.

Da unsere Systeme, die sich auf den (ausschließlich im LAN befindlichen) Server synchronisieren sollen, keinerlei Internet-Anbindung, nur LAN haben, ist ein öffentlicher Server in der Auflistung doch nicht notwendig, kann dann ja von vornherein ausgelassen werden, oder? Und damit kann ich auch das minpoll und maxpoll durchaus ein paar Stufen runter drehen, oder?

Ist dies denn der Lösungsweg des oben beschriebenen Problems?

Ich danke schonmal für deine Hilfe

[pitu]

ich hab den oeffentliche Server vogeschlagen weil es vielleicht an der anbindung an den Windowsserver liegt, vielleicht verstehen die sich nicht richtig. Wenn du dich aber ueber den oeffentlich synchronisieren koenntest, haettest du in drift und jitter schon mal gut eingestellte werte und der windowsserver meckert dann vielleicht nicht mehr, oder so, aber dieser loesungsweg ist dir leider verschlossen ... :-( dann kann ich dir im moment nicht weiterhelfen, da ich solche probleme nie hatte und auch keinen windowsserver benutze

[7.e.Q]

Hmm... es passiert ja nicht nur auf einem Windows Server. Auf einigen Systemen befindet sich auch Linux. Und selbst der Abgleich damit führt zu dem selben Ergebnis...

[pitu]

also du meinst, du hast auch linux-timeserver ud die liefern das gleiche ergebniss auf den clients?

schick doch mal eine ntp.conf von einem linux-server ...

[7.e.Q]

Die auf dem Server (mit 2 NICs: 136.1.255.13 und 10.1.1.100) hab ich jetzt so eingestellt:


#NTP Configuration

server 136.1.255.7 burst minpoll 7 maxpoll 8

logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift



die Config auf den 8 Linux Clients (mit je 1 NIC: 10.1.1.101 - 10.1.1.108, die alle nur mit dem Linux Server abgleichen):


#NTP Configuration

server 10.1.1.100 burst minpoll 7 maxpoll 8

logfile /var/log/ntp.log
driftfile /var/cache/ntp.drift





So... jetzt stimmts (also der Post, mein Problem ist noch nicht gelöst). :ugly:

[pitu]

so, wenn du private server hast brauchst du poll minoll und maxpoll nicht.

was meldetet denn "ntpq" auf dem server, wenn du peers eingibst?

[7.e.Q]

ntpq -p auf dem Server (10.1.1.100):



ISTS [~]# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
136.1.255.7 129.103.166.60 2 u 7 64 1 1.008 40997.7 0.004



oh... diesmal scheint's funktioniert zu haben. Nachdem "when" "poll" überschritten hatte, sieht die ntpq -p Ausgabe so aus:


ISTS [~]# ntpq -p
remote refid st t when poll reach delay offset jitter
================================================== ============================
136.1.255.7 .STEP. 16 u 294m 64 0 0.000 0.000 4000.00



nee, auf dem Server hat sich der Daemon jetzt wieder verabschiedet... ich versteh das nicht. :(

[pitu]

sag mal, wo genau ist der urspring von eurem timeserver; beschreib doch mal den ganzen verlauf ...

aehm, ok, das schein alles company netz zu sein, ist dein 136.1.255.7 der hauptserver deine company (F...) bzw ist das der der von deinem standort aus als hauptserver erreichbar ist?

[7.e.Q]

Wir haben hier zwar ein Firmen-Netz, aber das hat damit nichts zu tun (das mit den 129er IPs). Ich versuch mal, unsere Netz-Topologie ein wenig zu erklären:

Der Server 136.1.255.7 ist hier im Netz unser sogenannter IWAN (ISTS WAN Service). Mit diesem Server sollen sich alle Systemeinheiten synchronisieren. Jede Systemeinheit besteht aus mehreren Baugruppen. Jeweils eine dieser Baugruppen fungiert quasi als Bridge zwischen zwei Netzen. Dem normalen LAN hier (136.1.0.0/16) und einem je Systemeinheit internen Netz mit 10.1.1.100er IP Adressen. Die erste Baugruppe je Systemeinheit hat immer zwei IP Adressen, einmal eine aus dem 136.1.0.0/16 Netz und auf der anderen Seite (Systemeinheiten intern) die 10.1.1.100. Letztere ist von außen nicht erreichbar, sondern nur innerhalb der Systemeinheit vergeben. Darum darf sie bei uns im LAN auch mehrfach vorkommen. Das Bild im Anhang verdeutlicht hoffentlich ein bisschen den Aufbau. Die PCs sind nur die Bedienungssysteme für das ganze Konzept und haben für dieses Thema keine Bewandnis. Die PULs (10.1.1.100 intern) sollen sich über ihre 136er IP mit dem IWAN synchronisieren, und die restlichen Baugruppen innerhalb einer Systemeinheit mit ihrer jeweiligen PUL, welche - wie oben beschrieben - sowohl als Client, als auch als Server fungieren muss.

Klingt kompliziert, ist es aber nicht...

[pitu]

So meinte ich das nicht ... sorry, war nimmer da, hast du es gloest inzwischen?

Was ich meinte, so wie das aussieht, habt ihr ein ganzes Class B netz (wenn ich mich jetzt recht erinnerer oder wuerfel ich da etwas durcheinander?).

Bei uns ist das so, wir haben ein eigenes Netz von offiziellen Adressen. Unser Standort hat einen eigenen ntp-Server, der seine Zeit aber von dem Hauptserver in deutschland bekommt.

Wie ist das bei euch, der Server von dem du die Zeit bekommst, steht der in deutschland und wenn, steht der an eurem standort? und wenn beides ja, was ist das für ein server und hast du dort eingriffsmöglichkeiten?

Ansonsten: ummal gegen oeffentliche server su connecten, hinter deiner firewall:
http://proxytunnel.sourceforge.net/
http://desproxy.sourceforge.net/

desproxy hab ich selber eingesetzt ...

[7.e.Q]

Um nochmal Klarheit zu schaffen: es geht nicht darum, die exakte Uhrzeit in unser Netz zu bekommen, sondern lediglich darum, die Uhren aller Systemeinheiten (siehe Bild oben) und dem IWAN synchron zu bekommen.

Der NTP Server (genannt IWAN), mit dem sich alle Schnittstellenbaugruppen (PUL) der Systemeinheiten synchronisieren sollen, steht ebenfalls hier vor Ort und wird von uns verwaltet.

Das hat nichts mit dem Internet oder dem offiziellen Firmennetz zu tun, sondern ist ein bürointernes Klasse-B-Netz (136.1.0.0/16). Parallel dazu gibt es eine Reihe anderer Klasse-C-Netze (10.1.1.0/24), die sich aber nur intern in jeder einzelnen Systemeinheit befinden (siehe Bild).

Wir benötigen keinen Zugang nach draußen, keine exakte Uhrzeit, sondern ausschließlich Synchronität zwischen den Systemeinheiten, den darin befindlichen Baugruppen und dem IWAN. Dabei ist die absolute Uhrzeit völlig nebensächlich. Der kann auch ruhig auf 0:34 stehen, wenn's eigentlich Nachmittag ist. Hauptsache, der ganze Haufen Systeme läuft synchron.

Die PULs innerhalb der Systemeinheiten sind direkt über Ethernet mit dem IWAN verbunden. Die DIUs innerhalb der Systemeinheiten sind über einen VME-Bus nur mit den jeweils anderen Baugruppen innerhalb der selben Systemeinheit verbunden. Eine direkte Verbindung zwischen einer DIU und dem IWAN besteht nicht.

Es soll sich nun die jeweilige PUL einer Systemeinheit mit dem IWAN und die DIUs innerhalb der jeweiligen Systemeinheit mit ihrer PUL synchronisieren. Anders geht's hier nicht.

Die PUL hat VME-Bus-seitig immer die IP 10.1.1.100, die DIUs sind entsprechend durchnummeriert (siehe Bild). Auf Ethernet-Seite hat die PUL immer eine eindeutige IP im 136.1.0.0/16er Klasse-B-Netz.

Ich hoffe, dies ist so ein bisschen verständlicher. :) Ist nicht einfach, ich weiß.

[pitu]

Sorry, aber ich bin davon ausgegangen, dass dieses Netz der Firma Ford gehört und wollte daher etwas über den Aufbau wissen.

Ausserdem ging es mir nicht darum, dass du von aussen die Zeit kriegst, sondern um festzustellen, wo der Fehler liegt. an die ofiziellen timeserver im internet connecten sich 1000e Server ohne Fehler, es gin mir nur um einen Loesungsweg fuer Dein Problem.

Was ist das eingentlich für ein System, der IWAN?

[7.e.Q]

Brauchst dich nicht entschuldigen. Wenn du es falsch verstanden hast, hab ich es schlecht erklärt. Ist also allein meine Schuld! *peace* :D

Das ganze System ist ziemlich proprietär. IWAN ist einfach nur eine Bezeichnung der Serversoftware, die wir entwickeln, um unsere Systemeinheiten mit Daten zu versorgen. Es ist ein Dienst, der auf dem eigentlichen Windows 2000 Server läuft. Da es für uns im Team einfacher ist, wird von uns der Windows 2000 Server allgemein als IWAN bezeichnet, da dieser Dienst seine primäre Aufgabe ist. Als sekundäre Aufgabe kommt nun noch der Time Service dazu.

Ich bin dir natürlich für jede Hilfestellung dankbar. Auch in Form von Ideen, Geistesblitzen quasi, die dazu führen, daß wir - wenn auch zufällig - die richtige Richtung einschlagen. :)

Inzwischen hat sich ein Kollege des Problems angenommen und scheint Fortschritte zu machen. Ich musste mich aufgrund unvorhergesehener Probleme wieder der Weiterentwicklung des VME-Netzwerktreibers neverending Story DPN widmen. *grmpf*

Also wenn du - oder selbstverständlich auch andere - noch Ideen hast, dann immer her damit ;)


PS: äh, wie bist du denn darauf gekommen, daß das Netz der Firma Ford gehört? :confused:

[pitu]

Also wenn ihr schon netze benutz, dann solltet ihr schon wissen welche ;)



tambu:~ # whois 136.1.255.7

OrgName: Ford Motor Company
OrgID: FORDMO
Address: P.O. Box 2053, RM E-1121
City: Dearborn
StateProv: MI
PostalCode: 48121-2053
Country: US

NetRange: 136.1.0.0 - 136.140.255.255
[...]