ich habe den Eindruck, als ob Rheinufer-Knoten ohne IPv4 (via WAN) derzeit eine nach dem Mond gehende Uhrzeit haben.
Zumal der einzige ntp-Server „ntp1.ptb.de“ aus der Config allem Anschein nicht per IPv6 erreichbar ist, zumindest nicht über den DNS-AAAA im Rheinufer.
Ein testweises Umstellen auf ntp0.ipv6.fau.de brachte dann eine gestellt Systemuhr.
(ich weiss nicht ob das jetzt wichtig ist, aber ich vermute dass ein Teil der Zeitkalkulation der Alfred-Angaben von einer korrekten Systemzeit abhängen und das dann auch bis in die ffmap durchschlägt.)
Grundsätzlich ist es schlechte Praxis die Tier 1 NTP Zeitserver von hunderten Routern anzusprechen. Entweder man setzt selber nen NTP Server auf der via IPv4/IPv6 erreichbar ist, oder man verwendet die Pool Server des NTP Projekts. 2.de.pool.ntp.org löst sowohl auf IPv4 als auch IPv6 auf. Das Pool Projekt selber verwendet DNS Round Robin, so das die Last entsprechend verteilt wird und die Zeit von dort ist für unsere Zwecke genau genug.
Die Diskussion hatten wir schon vor ein paar Monaten (vor dem letzten Build, als Rheinufer komplett duster war)
Da sind dann zwar die ULA-Adressen entfernt worden, aber der verbliebene NTP (obiger) wurde nicht angetastet.
Ich vermute mal, dass es dafür Gründe gab.
Da IPv6 NTP Traffic manchmal sehr buggy ist gibt es nur wenige Pools mit IPv6, siehe dazu unsere site.conf:
--[[ NTP settings
Synchronize the time of the nodes
timezone: Timezone of your community
http://wiki.openwrt.org/doc/uci/system#time.zones
ntp_servers: List of NTP-Servers to query. You can use any public and/or your private NTP-Servers of your community.
http://www.pool.ntp.org/zone/de
#############
# NOTE: http://news.ntppool.org/2013/06/ipv6-monitoring-problems-for-g.html
# > As you might know only "2.pool.ntp.org" (and 2.debian.pool.ntp.org, etc)
# > returns AAAA records currently.
#############
]]
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3',
ntp_servers = {
'host 2.pool.ntp.org',
},
Das Gerücht, dass man keine Stratum-1-Server nutzen sollte hält sich hartnäckig. Das war vielleicht früher so als es noch kein NTP-Pool-Projekt gab. Insbesondere die PTB-Server sind explizit für den Normalanwendergebrauch gedacht. Am Ende ist dieses Institut eben staatlich davon betreut worden, die Uhren Deutschlands synchron zu halten. Wenn die Server an ihre Belastungsgrenze kommen oder ungenau werden, werden einfach neue aufgestellt. Bei größeren Installationen wird lediglich eine Benachrichtigung an ntp-admin@ptb.de gewünscht.
Hatte irgendwo nochmal auf einer Webseite einen veröffentlichten E-Mail-Verkehr gesehen, wo die Admins das bestätigt haben, aber die finde ich nicht mehr. Wer Lust hat kann ja nochmal selbst eine Anfrage an o.g. Mailadresse stellen.
Im Gegensatz dazu sollte man keine pool.ntp.org-Domains in Firmwares hardcoden. Dort benötigt man ein Vendorpräfix, damit die bei Fehlern in der Software der Traffic besonders gehandelt werden kann. Man kann aber das openwrt-Vendor-Präfix benutzen.
Mir gehts einfach darum, das es wichtigere Dienste gibt die eine Uhrzeit von einem Stratum1 Server beziehen müssen als unsere Freifunk Knoten. Wir machen ja schließlich kein Speedtrading. Davon abgesehen sind die PTB Server genauso im Pool drinne wie andere Server auch und wird dadurch auch bestimmt von dem einen oder anderen Knoten über die Pool URL angesprochen.
Trotzdem sollten wir Freifunker die Resource Public NTP Stratum1 Server schonen und dafür entweder die Pool Server benutzen, oder selber diesen Dienst im Netz zur Verfügung stellen, z.B. auf den Supernodes/Gateways. Ist ja nun wirklich kein Hexenwerk.
Nein, das ist Teufelswerk.
Das hatten wir doch am Rheinufer und war (mit) ein Grund, warum bei Netzinstabilitäten sich die Sache aufgeschaukelt hat bis zum totalen Netzzusammenbruch.
(Siehe verlinkter Thread oben, da warst Du doch auch aktiv! Ist das Grauen schon verblasst?)
Ich sehe jetzt nicht wieso die Timeserver was mit Netz Instabilität zu tun gehabt haben. Aber egal. NTP ist nun wirklich easy aufzusetzen und zu betreiben bzw. die angegebenen Pool Server zu verwenden.
In Kombination mit IPv6 hatte das damals einen Broadcaststurm verursacht. Einige Nodes haben halt tausende Anfragen pro Sekunde an nicht-existente NTP-Server gestellt. Wenn man die angefragte Adresse gehighjackt hat, und dort NTP geboten hat, haben die sich nach Ankunft der erwarteten Replies wieder eingekriegt.
Wurde nicht weiter debuggt bzw. es konnte abschließend nicht genau geklärt werden. Vielleicht ein Problem mit IPv6-Multicast? NTP-Server haben da ne well-known Adresse…
Man kann natürlich trotzdem einen eigenen ntp betreiben, der sollte dann nur knapp außerhalb des Mesh liegen, keine ula Adresse verwenden und per dns aufgeloest werden. Das gibt einem dann einige Vektoren zur Analyse und zum eingreifen.