NTP

Network Time Protocol (NTP) keeps RouterOS synchronized to an accurate time source. Correct system time is critical for log timestamps, certificate validation, scheduled tasks, and firewall time-based filters.

RouterOS v7 includes a full NTP implementation (client and server) in the System package — no additional package is required.

NTP uses UDP port 123.

Sub-menus

/system ntp client
/system ntp client servers
/system ntp server

NTP Client

Client Properties

Configure the NTP client under /system ntp client:

Property	Description
`enabled`	Enable or disable the NTP client (yes/no, default: no)
`mode`	Sync mode: `unicast`, `broadcast`, or `manycast` (default: unicast)
`server-dns-names`	Comma-separated list of NTP server hostnames (unicast mode)
`server-addresses`	Comma-separated list of NTP server IP addresses (unicast mode)
`vrf`	VRF instance for NTP traffic (default: main)

In broadcast and manycast modes, server-dns-names and server-addresses are ignored — the router discovers servers automatically.

Unicast Mode

Unicast is the standard mode for synchronizing with public NTP pools or known upstream servers. The router sends requests directly to the configured addresses.

Using DNS names (recommended for pool.ntp.org):

/system ntp client
set enabled=yes mode=unicast server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Using IP addresses:

/system ntp client
set enabled=yes mode=unicast server-addresses=216.239.35.0,216.239.35.4

Using MikroTik’s NTP pool:

/system ntp client
set enabled=yes mode=unicast server-dns-names=0.routeros.pool.ntp.org,1.routeros.pool.ntp.org

Broadcast Mode

In broadcast mode, the client listens for NTP broadcast packets on the local network. No server address configuration is needed — the router accepts time from any broadcasting NTP server.

/system ntp client
set enabled=yes mode=broadcast

Use broadcast mode only on trusted networks, as there is no authentication of the broadcasting server.

Manycast Mode

Manycast is a hybrid: the client sends a discovery request and synchronizes with the first server that responds. Suitable for local networks with multiple NTP servers.

/system ntp client
set enabled=yes mode=manycast

Monitoring Sync Status

Check whether the client has synchronized and review timing quality:

/system ntp client print

Read-only status fields returned:

Field	Description
`status`	Current sync state (e.g., `synchronized`, `reaching`)
`active-server`	IP address of the server currently being used
`stratum`	Stratum level of the active server
`offset`	Current time offset from the server (milliseconds)
`round-trip`	Round-trip delay to the active server (milliseconds)
`jitter`	Variance in offset measurements (milliseconds)
`last-adjustment`	Time of the most recent clock adjustment

Confirm the system clock after sync:

/system clock print

For detailed per-server status, including reachability and error counters:

/system ntp client servers print detail

Force immediate DNS re-resolution for hostname-based servers (useful after a server’s IP changes):

/system ntp client servers resolve-dns-names

NTP Server

RouterOS can serve time to other devices on the network. The NTP server should itself be synchronized to an accurate upstream source before clients connect.

Server Properties

Configure the NTP server under /system ntp server:

Property	Description
`enabled`	Enable or disable the NTP server (yes/no, default: no)
`broadcast`	Send NTP broadcast packets on the local subnet (yes/no, default: no)
`multicast`	Join NTP multicast groups `224.0.1.1` / `ff05::101` (yes/no, default: no)
`manycast`	Respond to manycast discovery requests (yes/no, default: no)
`use-local-clock`	Serve time from the local clock even when unsynced (yes/no, default: no)
`local-clock-stratum`	Stratum advertised when serving from local clock (1–15, default: 10)

Enabling the NTP Server

/system ntp server
set enabled=yes

This enables unicast server mode — clients can send requests directly to the router’s IP address on UDP/123.

Stratum and Local Clock Fallback

Stratum indicates how many hops a clock is from a reference source:

Stratum 1 — directly connected to an atomic clock or GPS receiver
Stratum 2 — synchronized from a stratum 1 server
Stratum 15 — maximum valid stratum; higher means less reliable

When the router is synchronized via NTP client, it automatically advertises the correct stratum (upstream stratum + 1).

If the router is not synced but you still want it to serve time (e.g., for an isolated network), enable use-local-clock and set a high stratum value so clients know the time quality is low:

/system ntp server
set enabled=yes use-local-clock=yes local-clock-stratum=12

Use stratum 12 or higher for an unsynced local clock. This prevents clients from preferring a router that has no reliable time source over other options they may have.

Multicast Server

For networks where you want all devices to receive time without being configured with the router’s IP, enable multicast mode:

/system ntp server
set enabled=yes multicast=yes

Multicast NTP uses the well-known groups 224.0.1.1 (IPv4) and ff05::101 (IPv6). Clients must also be configured in multicast mode to receive these packets.

Broadcast Server

To push NTP packets as layer-2 broadcast (useful for simpler devices that only support NTP broadcast client mode):

/system ntp server
set enabled=yes broadcast=yes

Monitoring the Server

View server status and packet counters:

/system ntp server print detail
/system ntp server monitor

The monitor output includes last-bad-packet-from and last-bad-packet-reason fields to identify malformed or rejected client requests.

Synchronization Troubleshooting

Troubleshooting Checklist

Verify the client is enabled and servers are configured:

/system ntp client print
/system ntp client servers print

Check UDP/123 connectivity — ensure no firewall rule blocks outbound UDP port 123 to the NTP server. Test basic reachability with a ping to the server IP.
Check mode compatibility — for Internet servers, use unicast mode. Broadcast and manycast only work on local networks.
Inspect the reachability register:
```
/system ntp client servers print detail
```
The server-reachability field is an octal shift register of the last 8 polls:
- 377 — all 8 recent polls succeeded (fully reachable)
- 0 — no recent polls succeeded (unreachable)
- Values between indicate intermittent loss
Check bad packet fields — if last-bad-packet-reason shows a value, the server is responding but sending malformed or invalid NTP packets. Try a different upstream server.
Force DNS re-resolution — if using hostnames and the server’s IP recently changed:
```
/system ntp client servers resolve-dns-names
```

Enable system logging to capture NTP events:

/system logging add topics=system,info action=memory
/log print where topics~"system"

Isolate the upstream source — replace the configured server with a known-good public NTP server (e.g., time.cloudflare.com or 0.pool.ntp.org) to rule out source quality issues.
If serving time to clients, verify the router itself is synchronized first — clients inherit inaccurate time from an unsynced server.

Common Issues

Symptom	Likely Cause	Resolution
Status stuck at `reaching`	UDP/123 blocked or server unreachable	Check firewall; verify server IP/port
`server-reachability` = 0	No responses from NTP server	Check connectivity; try alternate server
High offset or jitter	Poor upstream NTP quality or network latency	Use a geographically closer or more accurate server
Client not syncing after IP change	Stale DNS cache	Run `resolve-dns-names`
Clients not syncing from local server	Server not enabled or mode mismatch	Enable server; verify broadcast/multicast settings match client mode
Time correct but timezone wrong	Clock timezone not set	See Clock configuration

Precision Time Protocol (PTP)

For applications requiring sub-microsecond accuracy — industrial automation, financial systems, telecom — RouterOS supports IEEE 1588-2008 Precision Time Protocol (PTP) with hardware timestamping on supported hardware.

PTP is configured under /system ptp.

PTP vs NTP

Feature	NTP	PTP
Typical accuracy	1–10 ms (WAN), sub-ms (LAN)	Sub-microsecond to nanosecond
Hardware requirement	None	Requires hardware timestamping support
Use case	General network time sync	Industrial, telecom, financial
Transport	UDP (unicast/multicast)	UDP or Ethernet

When to Use PTP

Use PTP when:

Sub-millisecond synchronization accuracy is required
Deploying timing-sensitive equipment (e.g., LTE base stations, SCADA systems)
Participating in a SyncE or IEEE 1588 telecom profile network

For standard router and network device synchronization, NTP is sufficient.

Hardware Timestamping

PTP accuracy depends on hardware timestamping, which captures exact packet transmit/receive timestamps at the hardware level rather than in software. Check the MikroTik hardware specifications for your device to confirm PTP and hardware timestamping support.

Example: Complete NTP Setup

A typical deployment: RouterOS syncs from public NTP pools and serves time to LAN devices.

# Sync from public NTP pool
/system ntp client
set enabled=yes mode=unicast \
    server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

# Serve time to local network
/system ntp server
set enabled=yes

# Set correct timezone (adjust to your region)
/system clock
set time-zone-name=Europe/London

# Verify sync
/system ntp client print
/system clock print

NTP

NTP