Ich habe am Wochenende festgestellt, das die Systemzeit auf meinen Routern in Duisburg (FF-DU-Masurensee01/02/03) total verstellt war.
Ich hab nach einigem Suchen festgestellt, das die NTP Server nicht erreichbar waren.
Das kann ja mal passieren, aber die Fehlermeldung im Ping und bei einem ntpd -n -d -p 0.openwrt.pool.ntp.org war interessant.
In beiden Fällen kam die Meldung ‚invalid IP address‘
Ich habe dann in der /etc/config/system de.pool.ntp.org als ersten Server eingetragen, und die Zeit wurde wieder richtig eingestellt.
Gib es ein bekannten Problem, das die Namensauflösung keine Hostnamen, die mit einer Zahl gefolgt von einem Punkt beginnen, nicht funktioniert?
Oder wird die Namensauflösung gar nicht benutzt, weil der Netzwerkstack meint es ist schon eine IP-Adresse?
Das hilft auf systemen, die IPv4 (via WAN/VPN…) haben.
Zumindest bei meinem letzten schauen gab es aber unter pool.ntp.org KEINE IPv6-Adresse, daher hilft das „Mesh-Only-Routern“ nicht.
BTW: Wenn Router keine (korrekte) Uhrzeit haben, dann benimmt sich der Gluon-Autoupdater meist „komisch“. (Sprich: Er tut es einfach nicht, gar nicht.) Das könnte evtl(!) das sein, was @Vincent beim letzten Krefelder Stammtisch angesprochen hatte.
moinsn, soweit ich weiß ist aktuell ist IPv6 für RG-West noch nicht fertig. Im Niersufer läufts aktuell auch noch nicht 100% rund.
Aktueller Stand in RG-West soweit mir bekannt:
Supernode auf privat Finanzierter Hardware läuft, Routinginstanz hat ne Backboneanbindung und der (neue) SN ist dort hin umgeschwenkt worden.
Die Redundanz liegt auf einer Ovirt VM.
Geplante weitere Schritte: Services (Webseite, Map, etc.pp), ne weitere Supernode, anschließend ne Aufteilung/Umbau des Netzes
Vielleicht sollte man fuer Niersufer und RG-west einfach die ntp-Server de.pool.ntp.org als default server in die Router-Images einbauen. Das hilft sofort und loest die von @adorfer beschriebenen Probleme mit dem Autoupdater.
Ipv6 ist aktiv mit dem neuen Prefix, aber Ntp ist meine ich noch nicht von uns angefasst worden.
Externe zu nutzen finde ich persönlich nicht so schön, da es nur bei funktionalen ipv6 geht. Und wenn man aggregiert finden das die Pool owner sicher auch ganz nett
Wäre was für Donnerstag @DJaeger?
Im Pool de.pool.ntp.org sind im Moment 471 Server mit IPv4 und 292 Server mit IPv6.
Bei der minimalen Last, die ntp auf einem Server erzeugt, ist es den Betreibern sicherlich egal, ob die FF Router direkt an den Pool gehen, oder ein eigener ntp-Server dazwischen hängt.
Es sind übrigens viele Betreiber, da jeder der einen offenen ntp-Server betreibt Teil des Pools werden kann. Das ist auf der Seite die ich oben genannt habe so beschrieben.
Naja davon mal ab, dass es ziemlich blöd wäre, ein paar Tausend Router jeweils einzeln die „Externen“
NTP-Server abfragen zu lassen (anstatt Aggregieren), muss dazu auch zwangsläufig IPv6 Routing aktiv sein.
Ich kann nicht für RGW sprechen, das müssen die „neuen“ Aktoren selbst für sich entscheiden.
Wir haben im EN-Kreis aufgrund des Quertraffics IPv6 komplett abgeschaltet, da es ein Performance und
Kosten Faktor ist, der abseits davon wenig Bereicherung bringt.
Nein ich möchte mich hier jetzt nicht über die Möglichkeiten und Vorteile von IPv6 unterhalten,
da sie mir sehr wohl bewusst sind (Ich nutze es zu Hause selbst).
Quertraffic zwischen den Supernodes ist definitiv nicht schön. Zumal es die v6 Verbindungen auch langsam macht und einfach nur Geld kostet.
Durch das BGP Routing gelangt der Traffic immer auf den einen besten Supernode und muss dann an die anderen Supernodes verteilt werden wo der entsprechende Knoten verbunden ist.
Für mich ist Linderung des Problemes aktuell dadurch sichergestellt das wir primär IPv6 DNS Antworten an die Clients verteilen. Aber eine Lösung ist das natürlich nicht.
Es wäre deutlich besser wenn die Clients an allen Supernodes verbunden wären. Dann würde der Traffic direkt durchgereicht werden können.
Was aber auch das Problem des BGP Routings nicht lösst.
