+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Начальное время CHR указано неправильно

Начальное время CHR указано неправильно, RouterOS

sid5632

Guest

18.05.2017 09:10:00

Откуда у CHR берётся начальное время? У меня оно совершенно неправильное (запущено под Virtualbox на Ubuntu), и с каждым перезапуском становится всё хуже, как показывают следующие фрагменты из лога:
may/21 08:37:40 system,info router rebooted
may/21 08:37:40 interface,info ether1 link up
may/21 08:37:40 system,info item added
may/21 08:37:40 dhcp,info dhcp-client on ether1 got IP address ...
may/21 08:37:45 system,info,account user admin logged in from ...
may/21 08:39:08 system,info SNTP client configuration changed by admin
may/10 22:49:28 system,info sntp change time May/21/2017 08:39:08 => May/10/2017 22:49:28

jun/05 06:52:51 system,info router rebooted
jun/05 06:52:51 interface,info ether1 link up
jun/05 06:52:51 system,info item added
jun/05 06:52:51 dhcp,info dhcp-client on ether1 got IP address ...
jun/05 06:54:49 system,info,account user admin logged in from ...
jun/05 06:55:26 system,info SNTP client configuration changed by admin
09:59:00 system,info sntp change time Jun/05/2017 06:56:15 => May/18/2017 09:59:00

jun/05 07:03:36 system,info router rebooted
jun/05 07:03:36 interface,info ether1 link up
jun/05 07:03:37 system,info item added
jun/05 07:03:37 dhcp,info dhcp-client on ether1 got IP address ...
jun/05 07:04:27 system,info,account user admin logged in from ...
10:02:31 system,info sntp change time Jun/05/2017 07:05:08 => May/18/2017 10:02:31

Время должно брать с хоста (что, конечно, правильно) — все другие виртуальные машины так работают, так в чём же причина? Сейчас у меня стоит 6.40rc5, но на 6.39 та же фигня.
Если Dude запускается на CHR — а именно для этого я его и использую — то такой большой скачок времени назад вызывает кучу странных проблем.

sid5632 Guest	#2 0 04.08.2017 23:41:00 Нет, не делал. Что бы ты предложил? Хотя я не очень понимаю, как это может быть баг гипервизора.

romeoma2004 Guest	#3 0 20.07.2017 08:47:00 Дорогой, просто удали пакет ntp, если установил, и используй только клиент sntp — тогда всё будет работать нормально. Пакет ntp можно использовать, если хочешь сделать свой роутер CHR сервером ntp.

sid5632 Guest	#4 0 20.07.2017 13:28:00 У меня нет пакета ntp. Я никогда не утверждал, что он у меня есть. Ты вообще прочитал и понял мой первоначальный пост, прежде чем писать свой бессмысленный, совершенно ни к чему не относящийся ответ?

IntrusDave

Guest

20.07.2017 15:56:00

Не нужно быть грубым. Очевидно, он не понимает, что легко объясняется количеством его сообщений (это был его первый пост). В любом случае — на CHR нет установленных VM-инструментов, поэтому он не может напрямую связаться с хостом, чтобы получить дату и время. К сожалению, у вас есть только один реальный вариант — заставить CHR получать время с NTP-сервера (time1.google.com и time2.google.com работают очень хорошо). Большинство версий RouterOS не имеют внутренних часов, поэтому RouterOS обычно сохраняет текущее время в конфигурации при отключении — но это происходит ТОЛЬКО при использовании внутренней функции «/system shutdown». Отключение с хоста или перезагрузка питания этого не делают. Но NTP-клиент должен довольно быстро подтянуть актуальные дату и время, когда WAN выйдет в сеть.

sid5632

Guest

21.07.2017 07:24:00

Хорошо, я бы мог понять это, если бы время при каждом запуске было 1/1/70, но это не так:
22:49:28 system,info sntp изменил время с May/21/2017 08:39:08 на May/10/2017 22:49:28
09:59:00 system,info sntp изменил время с Jun/05/2017 06:56:15 на May/18/2017 09:59:00
10:02:31 system,info sntp изменил время с Jun/05/2017 07:05:08 на May/18/2017 10:02:31

Откуда он вообще берёт эти даты из будущего? И почему с каждым перезапуском даты сдвигаются дальше вперёд (ещё больше, чем прошло времени)? Большинство сборок RouterOS не имеют внутреннего часов, поэтому RouterOS обычно сохраняет текущее время в конфиге при выключении. Если он это читает, то при старте время должно отставать от текущего, а не идти вперёд. Но NTP-клиент должен быстро подтягивать правильную дату и время, как только WAN поднимается.

И он это делает, но примерно за 20 секунд — а этого достаточно, чтобы компонент Dude полностью запутался из-за того, что время идёт назад.

pe1chl

Guest

21.07.2017 08:45:00

Это что-то, связанное именно с вашей системой (настройками хост-системы или CHR). У меня CHR работает под ESXi без особых настроек, кроме sntp, плюс установлен Dude, и он перезагружается с правильным временем. Иногда вижу, что sntp немного корректирует время на секунду после загрузки, но в основном без изменений.

sid5632

Guest

21.07.2017 11:10:00

Спасибо, полезная информация. Конфигурация довольно простая, так что она не может быть причиной:
# jul/21/2017 12:02:43 by RouterOS 6.40rc32
# software id =
#
#
#
/ip dhcp-client add disabled=no interface=ether1
/ip firewall filter add action=reject chain=output dst-address=169.254.169.254 protocol=tcp reject-with=tcp-reset
/snmp set enabled=yes
/system clock set time-zone-name=Europe/London
/system ntp client set enabled=yes server-dns-names=uk.pool.ntp.org
/system package update set channel=release-candidate

Единственное, что связано со временем в настройках Virtualbox — это «аппаратные часы в UTC», и эта опция была включена (как у всех остальных Linux-виртуалок). Я её отключил, чтобы посмотреть, что получится:

[admin@MikroTik] > log pr
12:01:33 system,info router rebooted
12:01:33 interface,info ether1 link up
12:01:36 system,info,account user admin logged in via local
12:01:43 system,info item added
12:01:44 dhcp,info dhcp-client on ether1 got IP address 192.168.x.y
12:02:07 system,info sntp change time Jul/21/2017 12:02:10 => Jul/21/2017 12:02:07

И теперь всё работает как надо. Странно. Ещё раз спасибо за полезную обратную связь.

sid5632

Guest

04.08.2017 12:05:00

На самом деле это не решило проблему, и она вернулась при следующей перезагрузке. Остановка для редактирования настроек виртуальной машины только запутала ситуацию… Оказалось, что часы в RouterOS запускаются с неправильным временем, если роутер перезагружается командой /system reboot. Время опережает нужное ровно на то же количество, которое роутер проработал с момента последнего холодного запуска. Например: я последний раз холодно запускал CHR 2 августа в 14:29, перезагрузил его 4 августа в 11:49, а сейчас время показывает 6 августа 09:13. Вот фрагмент журнала:

aug/06 09:13:30 system,info router rebooted
aug/06 09:13:30 interface,info ether1 link up
aug/06 09:13:40 system,info item added
11:51:13 system,info sntp change time Aug/06/2017 09:15:24 => Aug/04/2017 11:51:13

Если сделать холодный старт (через /system shutdown) и потом вручную запустить виртуальную машину, время будет правильным и синхронизируется с хостом. Это не связано с опцией «Hardware Clock in UTC Time» или её отсутствием. Жаль, что нельзя нормально использовать команду «reboot», это довольно неудобно.

pe1chl Guest	#10 0 04.08.2017 12:40:00 Вы пробовали другой гипервизор, чтобы убедиться, что проблема в RouterOS, а не в самом гипервизоре?

pe1chl

Guest

#11

05.08.2017 08:32:00

Как я уже говорил, я никогда не видел такую проблему на VMware ESXi. Возможно, это какой-то баг или несовместимость между CHR и гипервизором, точно не знаю. Обычно в гипервизоре есть настройки времени: время синхронизируется гипервизором или остаётся свободно бегущим (и, возможно, синхронизируется внутри ВМ), часы могут работать либо по UTC, либо по местному времени, с учётом летнего времени или без него.

sid5632

Guest

#12

12.08.2017 12:28:00

Оказалось, что причиной проблемы при дальнейших тестах является настройка «Paravirtualization interface» в VirtualBox. Параметры «None», «Minimal», «Legacy» и «Hyper-V» не вызывают эту проблему. А вот «Default» и «KVM» её вызывают. Поскольку все новые виртуальные машины по умолчанию создаются с этим параметром, установленным на «Default», это довольно неприятно. В любом случае, наконец-то мне удалось заставить службу поддержки воспроизвести баг — это хорошая новость, и они уже работают над его исправлением.

pe1chl Guest	#13 0 12.08.2017 15:22:00 Ну, я какое-то время использовал VirtualBox, чтобы запускать Windows под Linux, и должен сказать, что у меня было куча проблем, которых я никогда не встречал в VMware ESX(i). Конечно, не с этой проблемой. Но я читал, что у других возникали трудности с гипервизорами при попытке синхронизировать время из виртуальной машины (например, при работе с NTP). Приятно слышать, что, по крайней мере, проблему уже сузили и смогли воспроизвести — такие вещи часто очень трудно найти, но обычно их довольно просто исправить.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры