NTP 101
Each router has a software clock that is set at initialization according to the hardware clock. The software clock can be updated manually, or automatically using NTP, SNTP or VINES Time Service.
!Manual setup:
R(config)# clock set HH:MM:SS DATE MONTH YEAR
The software clock provides the time for time-based ACLs, logging ande debugging messages, and other router features.
The software clock is kept in UTC (GMT) and a timezone can be configured for a more accurate display, as well as the daylight saving time.
R(config)# clock timezone ZONE HOURS-OFFSET [MIN-OFFSET]
! Recurring summer time:
R(config)# clock summer-time ZONE recurring [WEEK DAY MONTH HH:MM WEEK DAY MONTH HH:MM] [OFFSET]
! Absolute summer time:
R(config)# clock summer-time ZONE date DAY MONTH YEAR HH:MM DAY MONTH YEAR HH:MM [offset]
To check the clock, use:
R# show clock [detail]
NTP is a protocol that runs on UDP 123 and offers time accuracy of a milisecond. Stratum represent the number of hops away a machine is from an authoritative time source.
- A Stratum 1 clock is a radio clock or an atomic clock or a GPS clock
- A Stratum 2 clock receives clock information from a Stratum 1 clock
- A Stratum 3 clock receives clock information from a Stratum 2 clock and so on..
NTP makes estimations taking into account Network delay, Dispersion of time packet exchanges(measures max clock error between the 2 hosts) and clock offset (the correction that is applied to the client clock to synchronize it)
To set a routers as an NTP authoritative source, use:
R(config)# ntp master [STRATUM]
NTPv4 is an extension of NTPv3 and provides some additional capabilities:
- NTPv4 supports IPv6
- NTPv4 supports public key cryptography and X.509 certificates
- NTPv4 can use a hierarchy of servers to achive the best time accuracy
- NTPv4 uses multicast messages instead of broadcase messages
NTP can work in 2 modes:
In this mode, we have 2 methods of association: Client mode and Symmetric Active Mode. In client mode, the client polls the server for time information, while in symmetric active mode, a device can poll for time information, but can also respond to NTP polls.
! Client mode:
R(config)# ntp server IP-ADDR [version VER | key KEY | source INTERFACE | prefer]
! Symmetric Active Mode
R(config)# ntp peer IP-ADDR [normal-sync] [version VER | key KEY | source INTERFACE | prefer]
In Client mode, the client will synchronize with a server
The Symmetric Active mode is used when multiple hosts are part of a redundant group of NTP servers.
In this mode, the hosts listen to NTP broadcasts from the server. This is a less accurate method and it is recommended in environments with more than 20 clients.
!On the server
R(config-if)# ntp broadcast [version VER]
! On the client
R(config-if)# ntp broadcast client
R(config)# ntp access-group {peer|serve|serve-only|query-only} ACL [kod]
! kod = Sends a "Kiss of Death" packet to the source of an unmatched packet
When a host receives KoD packets, they indicate that the NTP server dropped their packets. They should take appropriate measures, like running sanity checks or rate limiting their NTP outgoing packets.
If the source IP address matches the ACL for more than one type, the first type is granted. They are scanned in the following order:
- 1.peer – Allows time requests and NTP control queries and allows the system to synchronize itself to a system whose address passes the access list criteria
- 2.serve – Allows time requests and NTP control queries, but does not allow the system to synchronize itself to a system whose address passes the access list criteria
- 3.serve-only – Allows only time requests from a system whose address passes the access list criteria
- 4.query-only – Allows only NTP control queries from a system whose address passes the access list criteria
NTP provides MD5 authentication, but it is used to authenticate the NTP Server on the NTP Clients.
To enable authentication, follow these steps:
! 1. Enable authentication:
R(config)# ntp authenticate
! 2. Configure the MD5 key:
R(config)# ntp authentication-key KEY-NUMBER md5 KEY
! 3. Configure the key as trusted. Only NTP packets from servers that use the trusted keys will be accepted
R(config)# ntp trusted-key KEY-NUMBER
! 4. On clients only, define the key for each server.
R(config)# ntp server IP-ADDRESS key KEY-NUMBER
You can apply an ACL to the NTP configuration as such:
R(config)# ntp access-group {serve|peer|serve-only|query-only} ACL
- peer - Time synchronization requests and control queries are allowed. The deviec is allowed to synchronyze to remote systems that pass the ACL
- serve - Time synchronization requests and control queries are allowed. The device is not allowed to synchronize itslef to remote systems even if they pass the ACL
- serve-only: Time synchronziation requests only are allowed
- query-only: Time synchronuzation control queries only are allowed
You can use multiple options on each router to better control who is allowed to synchronize and with whom.
R(config)# calendar set HH:MM:SS DAY MONTH YEAR
! sets the hardware clock
R(config)# clock read-calendar
! sets the software clock according to the hardware clock
R(config)# clock update-calendar
! sets the hardware clock according to the software clock
R(config)# ntp update-calendar
! Syncs the hardware clock with NTP
R# show calendar
By default, the time maintained on the software clock is not considered to be reliable and will not be synchronized with NTP or VINES time service. To set the hardware clock as a valid time source, use this command:
R(config)# clock calendar-valid
Last modified 2mo ago