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 128T 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 128T to clock off of an upstream source.
There are two, somewhat complementary approaches to using a branch 128T as an NTP server:
- Issuing the 128T's address as the NTP server in DHCP repsonses and/or configuring devices to use the 128T'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 128T as an NTP Server
This is straightforward configuration for both the end devices as well as for the 128T itself. In the example below, we will assume that the 128T's LAN IP address is
192.168.1.1. Consider the following configuration excerpt:
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 128T'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 128T 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 128T's LAN interface is to "catch" all inbound traffic for 123/UDP and forcibly redirect it to the 128T'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 128T's Linux subsystem. Here is a relevant configuration excerpt:
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 128T will use when sending traffic outbound to external NTP servers. We want to ensure the 128T – and only the 128T – clocks off of an external source.
On each router, we'll configure a
service-route that looks like this:
service-route leverages Linux host networking to send packets to
ntpd using the
kni254 interface present on all 128T devices.
Avoiding unnecessary WAN traffic is always a welcome change, Using the 128T to provide NTP clock to devices at the branch ensures a consistent time source for a collection of devices that are logically grouped already.