Я полностью согласен. Когда я строил корпоративные сети, я всегда использовал маршрутизатор сайта в качестве источника времени NTP для этого сайта (используя оборудование маршрутизаторов Cisco) и строил сеть часов NTP на основе структуры маршрутизаторов (главные часы, концентраторные маршрутизаторы, зависящие от главных и связанные между собой, и маршрутизаторы сайта, зависящие от концентраторного маршрутизатора, например). Наличие постоянного источника времени внутри сайта и между сайтами критически важно для операционной функциональности (например, Windows Domain Kerberos), логирования и отчётности событий, а также для диагностики и устранения неисправностей. Если часы в разных устройствах не согласованы друг с другом, то становится очень сложно коррелировать информацию из этих разных устройств. NTP-сервер времени должен быть хорошо подключён и обладать высокой доступностью. Маршрутизаторы обычно являются лучше всего подключёнными устройствами в двух смыслах: 1) это устройство на сайте, которое "лучше всего подключено" к остальной сети, потому что оно подключает сайт к остальной сети, и 2) это устройство на сайте, которое лучше всего подключено ко всем устройствам на сайте (по крайней мере для устройств, зависящих от сети). Маршрутизатор сайта обычно имеет высокую доступность благодаря критической природе передачи данных в поддержании сети и подключённых к ней устройств. Добавлю, что наличие встроенных часов реального времени (RTC) также является полезной функцией для NTP-сервера, позволяющей ему поддерживать время даже во время перебоев питания, даже если сеть недоступна. Для маршрутизатора на ИБП (критически важного для доступности) это не так необходимо, но для маршрутизаторов на небольших сайтах или просто в качестве резервного копирования защиты ИБП это полезно. Я был очень удивлён, обнаружив, что продукты Ubiquiti, которые я ожидал бы полноценно участвовать в системе NTP (как клиент и как сервер), могли участвовать только как клиент. Это большой упущение для клиентов Ubiquiti, так как они должны либо полагаться только на удалённые серверы времени (что потенциально снижает согласованность между устройствами на сайте в случае отключения канала сайта), либо приобретать и управлять дополнительным устройством для каждого сайта, чтобы оно служило сервером времени для этого сайта. Шлюзы должны включать функциональность NTP-сервера и (очень желательно) часы реального времени с собственным источником питания (батарея) для поддержания отсчёта времени несмотря на перебои питания.

Огромный плюс — это раздражает, когда проверяешь исходящие сетевые соединения IoT-устройств и видишь "1000 соединений", только чтобы выяснить, что это всего лишь NTP. Я мог бы запустить локальный NTP-сервер, но учитывая, что это такой важный сервер при работе с большим количеством машин, использующих oauth, он должен быть в UDM. (так же как IKE2 VPN, поскольку и Android, и iPhone поддерживают это из коробки).