Network Time Protocol – NTP

Introduction

Time is a tricky concept. For most switching and routing operations having the correct system time is not required. However, for OpenVPN, IPsec, logging, and a few other functions time is of crucial importance.

System time is saved to, and restored from, the Real-Time Clock (RTC). At system bootstrap time is restored from RTC, which may fail if the system has experience power loss for an extended period of time. When the system shuts dow, or reboots, the RTC is updated with the current time.

Time and date can be set manually from the CLI admin-exec context using the date command:

example:/#> date
Wed Jun 19 12:52:09 UTC 2019
example:/#> help date
Syntax:
    date [[YYYY-MM-DD] hh:mm[:ss]]
Usage:
    System date & time

Another option is to enable the system NTP client and set up at least one valid time server. NTP adjusts for clock drift but may sometimes have trouble setting the initial time, if current time differs too much, in which case the date command is useful to help push things along.

Timezone

The time zone is the offset from Universal Coordinated Time (UTC), which is stored in the RTC. If time on your system seems off this is usually what you want to change, unless your site keeps all servers, routers, and switches on UTC.

The time zone setting is available in the system configuration context of the CLI:

example:/#> configure
example:/config/#> system
example:/config/system/#>

[no] timezone [TIMEZONE]

Set system time zone.

Try show timezone keyword to list matching timezones for your region.

E.g., show timezone Europe

When setting the timezone using the ‘Etc/GMT+/-offset’ notation, please take into account that the unit is consistent with POSIX which has positive signs west of Greenwich, while many people expect positive signs east of Greenwich.

E.g., ‘Etc/GMT+4’ corresponds to 4 hours behind UT (i.e. west of Greenwich) even though many people would expect it to mean 4 hours ahead of UT (i.e. east of Greenwich).

no: Reset system time zone to its default: UTC

list-timezones

List all available time zone codes

NTP Client

When configured as an NTP client, the device synchronizes with all configured NTP peers. The peers are continously evaluated for best offset, delay and jitter.

Note

Before the client is synchronized with its peers, it first asks for a preliminary date/time, which might differ some seconds, or even minutes, from the actual current time. This time is set as the initial system time.

All subsequent responses from the peer are treated as adjustments of the clock frequency in order to edge closer to the time provided from peer.

NTP cannot change the system time when there is a bug time difference, instead it sets time only once, initially, and then simply adjusts that time. If contact with peers cannot be established, preliminary time will not be set, and system is left with either the time restored from the RTC, or that which is set according to the UNIX epoch.

When multiple peers are set up, preference can be set by using the weight peer option. This option has the highest priority, regardless of offset, delay and jitter that other servers migh have. Meaning, a server with poor offset, delay and jitter can still be chosen when given a higher weight. By default, all servers have a weight of 1, which means NTP chooses the best peer.

The time obtained from an NTP server is always in UTC, so the time zone must be configured in order to get correct system time.

NTP Server

A device configured to act as an NTP server must also be an NTP client. The server must have a point of origin of time, i.e., an external source of time, which can be a GPS, or another time server on the Internet, or local one.

Note

Even if correct system time is set manually the NTP server will not respond to its clients, and it will never synchronize to itself. That is why NTP server is always a client in the first place, since to serve time to its clients it needs to synchronize itself to ‘the origin of time’, i.e. another time server or GPS.

NTP client/server will only respond to client requests when it has its own time synchronized. Before that, all client requests are denied.

Regardless of the configured time zone on NTP server, distributed time is in UTC, per RFC, therefore clients must configure timezone in order to get correct system time.

DHCP Clients

The DHCP server can be set up to distribute NTP server(s). This is can be very useful when managing a complete subnet, in which end-devices act as both DHCP and NTP clients. The setting can be global, per subnet, or even per static lease.

It is possible to have both manually configured NTP peers, and those received from a DHCP server. Time servers which are received from DHCP server have a default weight value of 1, which is not possible to change.

Configuration

NTP is a top-level configuration context in the CLI:

example:/#> configure
example:/config/#> ntp
example:/config/ntp/#>

[no] enable

Enable or disable NTP client/server. When disabled the settings are still saved to startup-config.cfg. To completely deactivate the service, use no ntp from the main configuration context.

no: Disable NTP client/server configuration.

[no] peer [FQDN|IPADDR]

Remote NTP peer to synchronize with.

You either can use a private or a public NTP peer, as ‘pool.ntp.org’ for example. If unset, the NTP server will try to set NTP peer from its DHCP client. This setting opens up the peer specific settings:

[no] enable

Enable or disable this peer

[no] weight [VALUE]

Weight value 1 - 10, default: 1

Controls the relative importance of peers. A server with a weight of 5 has five times more influence on time offset calculation than a server with a weight of 1.

[no] server

Enable or disable the NTP server. When disabled only the client mode is active. This setting opens up the server specific settings:

[no] listen IFACE [IFACE ...]: Interfaces on which to allow server queries.