ACI fabric switches as NTP server.

[ecsnnsls]

From the docs, I see that I can configure ACI switches to act as NTP server. Let's say that there is a NTP server(external) configured on the pod policy. The external NTP server acts as a stratum1, it is connected to an external clock/GPS. Now ACI will send NTP messages to the clients as stratum-2. Documentation states the following,

Server State enables switches to act as NTP servers to provide NTP time information to downstream clients.
To support the server functionality, it is always recommended to have a peer setup for the server.
This enables the server to have a consistent time to provide to the clients.

Question-1: What is peer-setup in this context?

Question-2: What will be the NTP server(for the clients) IP if the switches are acting as servers? Will this be the address of the inb gw residing on a BD? Can someone confirm?

Thanks.

[Robert Burns]

I'm going to take a stab at trying to decode what our docs' intention was, but I'll wager it's implying to have configure 2+ separate NTP sources (external) in order to ensure the fabric can reliably pull time for a master NTP source.  We recommend 3 NTP sources at min. per best practice.

For your second question, the IP of the Switches INB or OOB Management IP will definitely work, and I'm also 99% sure the  BD SVI of the switches will respond to NTP queries for the respective endpoints.  I'll quickly test this in the lab and update back here.  This should be included in our docs as well - which is why I want to verify it before rubber stamping this is supported. 

Robert

[Robert Burns]

Yep looks good w/ BD SVI as NTP server IP for client endpoints.

leaf10# show ip int brief vrf lb:ctx1
IP Interface Status for VRF "lb:ctx1"(65)
Interface Address Interface Status
vlan19 12.2.2.254/24 protocol-up/link-up/admin-up
vlan24 unassigned protocol-up/link-up/admin-up
vlan37 15.15.15.254/24 protocol-up/link-up/admin-up

leaf10# show ntp server-info
ServerState: enabled
MasterMode : enabled Stratum : 8
leaf10#

NTP Client:
=============

1. BD SVI (12.2.2.254) is configured as NTP server
2. TCP Dump shows BD SVI as the source IP

[root@localhost ~]# cat /etc/ntp.conf | grep 12
restrict 127.0.0.1
server 12.2.2.254 iburst
[root@localhost ~]#

[root@localhost ~]# tcpdump -vvi ens224 udp port 123
tcpdump: listening on ens224, link-type EN10MB (Ethernet), capture size 262144 bytes
15:55:07.937641 IP (tos 0xc0, ttl 64, id 17429, offset 0, flags [DF], proto UDP (17), length 76)
localhost.localdomain.ntp > 12.2.2.254.ntp: [bad udp cksum 0x1e13 -> 0x1a93!] NTPv4, length 48
Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 6 (64s), precision -24
Root Delay: 0.000000, Root dispersion: 0.000030, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 3747077705.942095271 (2018/09/27 15:55:05)
Receive Timestamp: 3747077705.938190687 (2018/09/27 15:55:05)
Transmit Timestamp: 3747077707.937604167 (2018/09/27 15:55:07)
Originator - Receive Timestamp: -0.003904584
Originator - Transmit Timestamp: +1.995508895
15:55:07.937996 IP (tos 0x14, ttl 64, id 46324, offset 0, flags [none], proto UDP (17), length 76)
12.2.2.254.ntp > localhost.localdomain.ntp: [udp sum ok] NTPv4, length 48
Server, Leap indicator: (0), Stratum 9 (secondary reference), poll 6 (64s), precision -20
Root Delay: 0.000000, Root dispersion: 0.010940, Reference-ID: 127.127.1.0
Reference Timestamp: 3747077646.570948494 (2018/09/27 15:54:06)
Originator Timestamp: 3747077707.937604167 (2018/09/27 15:55:07)
Receive Timestamp: 3747077707.941735276 (2018/09/27 15:55:07)
Transmit Timestamp: 3747077707.941898781 (2018/09/27 15:55:07)
Originator - Receive Timestamp: +0.004131108
Originator - Transmit Timestamp: +0.004294613
//snip
[root@localhost ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*12.2.2.254 LOCAL(0) 9 u 9 64 1 0.177 3.993 0.054
[root@localhost ~]#

[ecsnnsls]

Apologies if I sound dumb.

Question: How did you choose the tenant? I was under the assumption that the NTP server listens on the OOB/INB BD SVI IP based on what we choose for fabric communication.

From the output, I see that you have configured a BD SVI as a NTP server in tenant lb. How did you choose this?

I see only a knob to enable the server state, how do I choose which BD SVI over which the NTP process can listen?

Thank you very much for taking the time to respond. Appreciate it.

[Robert Burns · Accepted solution]

That's just one of my user tenants.  NTP Server functionality is enabled/disabled globally via the Fabric Pod Policies.  When enabled, it enables ntp server function on all BD SVIs, you can't selectively disabled on a per-BD basis.
Robert