In many hub-and-spoke deployments, devices at the spoke locations are accustomed to using either public services (such as
pool.ntp.org) or self-hosted NTP services as their clock source. Rather than carry this traffic on the WAN, this document demonstrates how an SSR can provide NTP services for devices at the branch, avoiding unnecessary WAN traffic, and ensuring that all branch devices use a consistent clock source.
All of the recommendations in this document presume that the administrator has already set up the SSR to clock off of an upstream source.
There are two, somewhat complementary approaches to using a branch SSR as an NTP server:
- Issuing the SSR's address as the NTP server in DHCP repsonses and/or configuring devices to use the SSR's LAN interface as an NTP server
- Capturing all inbound NTP (using a service that captures 123/UDP), and handling that traffic locally
Configuring Devices to use the SSR as an NTP Server
This is straightforward configuration for both the end devices as well as for the SSR itself. In the example below, we will assume that the SSR's LAN IP address is
192.168.1.1. Consider the following configuration excerpt:
description "Branch LAN"
There are two principle components to this configuration excerpt, with respect to NTP treatment: the
host-service specifying NTP (using 123/UDP), and the
ntp-server configuration within the
ntp-server configuration will offer the SSR's LAN interface (192.168.1.1) as the NTP server to use when issuing DHCP leases.
Any devices that have static IP assignments will need to have the NTP server configured accordingly.
host-service configuration shown here will direct any traffic sent to 192.168.1.1:123/UDP to the Linux host subsystem on the SSR device, where the
ntpd running on the host platform will reply. As seen in the configuration example above, it is important to ensure that every
tenant population that can access that LAN interface is allowed access to the
host-service through the use of an
access-policy statement. (In our example, we have three tenants on the LAN: trusted, guest, and corporate).
Capturing all Inbound NTP
An alternative/complementary approach to assigning the SSR's LAN interface is to "catch" all inbound traffic for 123/UDP and forcibly redirect it to the SSR's NTP process. This is necessary in many occasions when the NTP server for a given client platform on the LAN is hardcoded, as is the case for many small embedded platforms and Internet of Things (IoT) devices.
This configuration will catch all inbound NTP. If you have devices at the branch that require precision timekeeping from external sources, adjust your service definitions and/or your tenant definitions accordingly to ensure the traffic does not match the "catch-all" service.
The configuration will match all traffic arriving based solely on its port and protocol, and send it to the SSR's Linux subsystem. Here is a relevant configuration excerpt:
firstname.lastname@example.org# show config running authority service ntp-iot
description "Local NTP"
This configuration will match any destination IP address (
0.0.0.0/0) for NTP (123/UDP). As in the previous example, we've added
access-policy statements for the three tenants that we see on the LAN segments at our branch locations. Likewise, we've added a
applies-to configuration block, to ensure that this service is only pushed down to the routers we've tagged as belonging to the
Do not also add the
_internal_ tenant to the
access-policy list, as this is (typically) the tenant that the SSR will use when sending traffic outbound to external NTP servers. We want to ensure the SSR – and only the SSR – clocks off of an external source.
On each router, we'll configure a
service-route that looks like this:
email@example.com# show config runn authority router branch1 service-route rte_inbound-ntp
service-route leverages Linux host networking to send packets to
ntpd using the
kni254 interface present on all SSR devices.
Avoiding unnecessary WAN traffic is always a welcome change, Using the SSR to provide NTP clock to devices at the branch ensures a consistent time source for a collection of devices that are logically grouped already.