Zeit-Synchronisation über NTP funktioniert nicht

[flexicam]

Ich habe zwei Lancom 1721 VPN (Annex B), FW 8.00.0221RU2 in den Vereinigten Arabischen Emiraten über ADSL / Etisalat / Fiberoptic im Einsatz.
Die Verbindung zu den Boxen von Etisalat über LAN-Port klappt problemlos.
Seit einiger Zeit kann ich jedoch die Zeit der Lancoms nicht mehr über NTP-Server synchronisieren.

Es wird immer
Zeit
Online-Hilfe MENU: ISDN
Online-Hilfe TABINFO: Umstellungen-Sommerzeit 2 x [Ereignis,Index,Tag,Monat,Stunde,Minute,Zeit-Typ]
Online-Hilfe INFO: Aktuelle-Zeit Ungueltig
Online-Hilfe INFO: Quelle keine
Online-Hilfe INFO: Setzzaehler 0
Online-Hilfe INFO: Sommerzeit nein
Online-Hilfe INFO: Zeitzone +4
angezeigt.

Ich habe bereits mehrere Zeitservereinstellungen probiert, Firewall deaktiviert etc. jedoch ohne Erfolg.
Ich kann auch nicht genau sagen seit wann das Problem besteht, es ist bisher nicht aufgefallen... irgendwie bin ich aber sicher daß es vor 1-2 Monaten noch funktioniert hat...

Hier der Trace:

1/01/1900 00:00:01 System boot after power on

DEVICE: LANCOM 1721 VPN (Annex B)
HW-RELEASE: E
VERSION: 8.00.0221RU2 / 07.10.2010 / 6.26b/E74.02.54

[Sysinfo] 2012/09/30 12:37:51,778
Result of command: "sysinfo"

DEVICE: LANCOM 1721 VPN (Annex B)
HW-RELEASE: E
SERIAL-NUMBER: 057720600012
MAC-ADDRESS: 00a0571154e1
IP-ADDRESS: 192.168.153.254
IP-NETMASK: 255.255.255.0
INTRANET-ADDRESS: 0.0.0.0
INTRANETMASK: 0.0.0.0
VERSION: 8.00.0221RU2 / 07.10.2010 / 6.26b/E74.02.54
NAME: Ajman
CONFIG-STATUS: 1056;0
FIRMWARE-STATUS: 0;0.4;0.1;8.00RU2.07102010.4;8.00Rel.16062010.3
LANCAPI-PORT: 75
HW-MASK: 00000000000000000000000001100011
FEATUREWORD: 00000000001000000000000100011101
REGISTERED-WORD: 00000000001000000000000100011101
FEATURE-LIST: 00/F
FEATURE-LIST: 02/F
FEATURE-LIST: 03/F
FEATURE-LIST: 04/F
FEATURE-LIST: 08/F
FEATURE-LIST: 15/F
TIME: 00000000000000
HTTP-PORT: 80
HTTPS-PORT: 443
TELNET-PORT: 23
TELNET-SSL-PORT: 992
SSH-PORT: 22
Compatible-IDs: 14:30:31

[SNTP] 2012/09/30 12:38:44,673 Devicetime: 1900/01/01 00:09:11,560
SNTP: Looking up POOL.NTP.ORG

[SNTP] 2012/09/30 12:38:44,673 Devicetime: 1900/01/01 00:09:11,560
SNTP: Resolved POOL.NTP.ORG to 91.237.52.68
SNTP: Sending Time query

[SNTP] 2012/09/30 12:38:47,675 Devicetime: 1900/01/01 00:09:14,560
SNTP: Looking up PTBTIME1.PTB.DE

[SNTP] 2012/09/30 12:38:47,675 Devicetime: 1900/01/01 00:09:14,560
SNTP: Resolved PTBTIME1.PTB.DE to 192.53.103.108
SNTP: Sending Time query

[SNTP] 2012/09/30 12:38:50,676 Devicetime: 1900/01/01 00:09:17,560
SNTP: Looking up SWISSTIME.ETHZ.CH

[SNTP] 2012/09/30 12:38:50,676 Devicetime: 1900/01/01 00:09:17,560
SNTP: Resolved SWISSTIME.ETHZ.CH to 129.132.2.21
SNTP: Sending Time query

[SNTP] 2012/09/30 12:38:53,676 Devicetime: 1900/01/01 00:09:20,560
SNTP: Looking up NTP0.NL.NET

[SNTP] 2012/09/30 12:38:53,676 Devicetime: 1900/01/01 00:09:20,560
SNTP: Resolved NTP0.NL.NET to 193.67.79.202
SNTP: Sending Time query

[SNTP] 2012/09/30 12:38:56,677 Devicetime: 1900/01/01 00:09:23,560
SNTP: Looking up CHRONOS.CSR.NET

[SNTP] 2012/09/30 12:38:56,677 Devicetime: 1900/01/01 00:09:23,560
SNTP: Resolved CHRONOS.CSR.NET to 194.35.252.7
SNTP: Sending Time query


[SNTP] 2012/09/30 12:39:02,677 Devicetime: 1900/01/01 00:09:29,560
SNTP: Looking up POOL.NTP.ORG

[SNTP] 2012/09/30 12:39:02,677 Devicetime: 1900/01/01 00:09:29,560
SNTP: Resolved POOL.NTP.ORG to 91.237.52.68
SNTP: Sending Time query

[SNTP] 2012/09/30 12:39:05,677 Devicetime: 1900/01/01 00:09:32,560
SNTP: Looking up PTBTIME1.PTB.DE

[SNTP] 2012/09/30 12:39:05,677 Devicetime: 1900/01/01 00:09:32,560
SNTP: Resolved PTBTIME1.PTB.DE to 192.53.103.108
SNTP: Sending Time query

[SNTP] 2012/09/30 12:39:08,678 Devicetime: 1900/01/01 00:09:35,560
SNTP: Looking up SWISSTIME.ETHZ.CH

[SNTP] 2012/09/30 12:39:08,678 Devicetime: 1900/01/01 00:09:35,560
SNTP: Resolved SWISSTIME.ETHZ.CH to 129.132.2.21
SNTP: Sending Time query

[SNTP] 2012/09/30 12:39:11,668 Devicetime: 1900/01/01 00:09:38,560
SNTP: Looking up NTP0.NL.NET

[SNTP] 2012/09/30 12:39:11,668 Devicetime: 1900/01/01 00:09:38,560
SNTP: Resolved NTP0.NL.NET to 193.67.79.202
SNTP: Sending Time query

[SNTP] 2012/09/30 12:39:14,679 Devicetime: 1900/01/01 00:09:41,560
SNTP: Looking up CHRONOS.CSR.NET

[SNTP] 2012/09/30 12:39:14,679 Devicetime: 1900/01/01 00:09:41,560
SNTP: Resolved CHRONOS.CSR.NET to 194.35.252.7
SNTP: Sending Time query


[SNTP] 2012/09/30 12:39:20,670 Devicetime: 1900/01/01 00:09:47,560
SNTP: Looking up POOL.NTP.ORG

[SNTP] 2012/09/30 12:39:20,670 Devicetime: 1900/01/01 00:09:47,560
SNTP: Resolved POOL.NTP.ORG to 69.167.160.102
SNTP: Sending Time query

[SNTP] 2012/09/30 12:39:23,670 Devicetime: 1900/01/01 00:09:50,560
SNTP: Looking up PTBTIME1.PTB.DE

Irgendwelche Ideen?

[alf29]

Moin,

Wenn Du im IP-Router-Trace zusätzlich noch siehst, daß die Anfragen an die IP-Adressen der NTP-Server rausgehen, dann wird wohl Dein Provider neuerdings das blocken. Eventuell wollen die ja, daß Du einen Provider-eigenen NTP-Server nutzt?

Gruß Alfred

[flexicam]

Das habe ich auch schon gedacht, ist aber anscheinend nicht so, da
1. die NTP-Server die ich im Lancom versuche, unter Windows problemlos funktionieren (auch über den Lancom) und
2. ich auch noch einen dritten Lancom habe, allerdings einen 1781A (FW 8.62.0050RU2) über ADSL / Annex A direkt an Etisalat angeschlossen (also ohne die Fiber-Box / Ethernet dazwischen), bei dem es mit dem NTP-Synch auch problemlos funktioniert.

Ich habe etwas weiter rumprobiert und vielleicht einen möglichen Zusammenhang entdeckt:
Vor einiger Zeit habe ich die Lancoms (die zwei 1721 VPN sowie den 1781A) mit einem anderen Lancom in Deutschland (1724 VOIP, FW 8.62.00.50RU2) über VPN verbunden (die 1-Klick-Version im Lanconfig, wo man einfach nur die Geräte übereinander zieht). Möglicherweise klappt der NTP-Synch seitdem nicht mehr mit den 1721 VPNs?

Ich habe allerdings inzwischen auch eine "Notlösung" gefunden:
Statt die normalen externen NTP-Server zur Synch zu verwenden, habe ich einfach die interne IP von dem Lancom in Deutschland eingetragen, sodaß die 1721 sich über VPN mit ihm synchronisieren. Klappt zwar, aber halt nur nachdem das VPN steht und solange der Lancom in Deutschland verfügbar ist.

Kann es sein, daß die 1711 mit der alten FW ein Problem mit dem NTP-Synch haben, insb. nachdem ein VPN aktiviert wurde? Oder im Zusammenspiel mit anderen VPN Routern mit neuerer 8.6x FW?

[LoUiS]

Kann es sein, daß die 1711 mit der alten FW ein Problem mit dem NTP-Synch haben, insb. nachdem ein VPN aktiviert wurde?

Nein, denke ich nicht, NTP und VPN haben nichts miteinander zutun.

Wenn das Paket tatsaechlich im Ethernet-Trace verschickt wird, dann wuerde ich mal auf dem Etisalat schauen ob das NTP Paket da ankommt (ggf. einen Rechner dazwischen klemmen und mit Wireshark sniffen) und ob es vom Etisalat weiter geschickt wird.


Ciao
LoUiS

[flexicam]

Bei dem letzten Lancom-Seminar habe ich gelernt, daß zumindest der Zugang via TFTP auf lesen stehen muß damit es funktioniert. Falls also jemand das gleiche Problem hat einfach mal probieren...

[LoUiS]

Hi,

was sollte TFTP mit dem NTP Protokoll zu tun haben? Das hast Du sicherlich falsch verstanden.
TFTP wird in diesem Kontext nur benoetigt, wenn man die Zeit auf dem LANCOM manuell via LANconfig setzen will.


Ciao
LoUiS

[MoinMoin]

Moin, moin!

Wenn auf die NTP-Time-Query keine Antwort kommt, liegt der Verdacht nahe, daß sie entweder überhaupt nicht rausgeht, oder nicht dahin, wo sie hin soll.

Was sagt der Router-Trace?


Ciao, Georg