Thanks
@Adam,
However, I was more leaning towards a way of deploying this at mass scale. I understand that Linux and 128T have different routing tables and that the DNS functionality should sit on Linux (because that's where we'll configure NTP and where 128T draws it's system time from).
But from my perspective, if we had to deploy 200 sites for a project, how would I make this easier on the rollout team? Having to create a global-dns.conf file with those contents on every device that we need to ship hardly seems scalable.
On a different note, this also seems like it would work on a "manual" management interface, but not with the interface created when conductor services are enabled? From my knowledge, ticking the "conductor" slider on an interface, automatically adds a /32 route in the linux routing table along with creating a kni interface that traffic would be sourced from and sent to the conductor. Which means this config will not work with conductor service?
Also - is there any way to set up NTP servers on an authority level, and not on a per-router level? Something where I can specify 4 servers at an authority level, and I could maybe change a single device if that device alone had different NTP needs.
Regards,
------------------------------
Morne Vermeulen
Engineer
+27 (0) 10 141 8512
------------------------------
Original Message:
Sent: 04-05-2019 12:35
From: Adam Morris
Subject: NTP Configuration
Hello @Morne,
As of 4.0, keeping the proper system time via NTP has become a requirement on our 128T platform to ensure analytics are stored properly, so this question is perfect on timing.
The 128T software today leverages NTPD in order to ensure the system time is kept. Within the router configuration you can utilize an FQDN or IP address. Here's some example below:
amorris@aws-vm.conductor
-field-eng# show ntp router seattle-site-02-lanner
Fri 2019-04-05 16:15:27 UTC
Node: grimlock
======== ================== ================= ========= ====== ====== ====== ======= ======== ========= ======== ============
Status Time Source Ref. ID Stratum Type When Poll Reach Delay Offset Jitter Tally Code
======== ================== ================= ========= ====== ====== ====== ======= ======== ========= ======== ============
active +up2.com 58.148.140.87 2 u 1 64 1 90.833 -27.028 1.910 candidate
active *vps6.ctyme.com 216.218.254.202 2 u 2 64 1 29.728 -21.401 2.759 syspeer
active triton.ellipse. 128.252.19.1 2 u 1 64 1 73.888 -27.292 1.317 reject
active ns2.switch.ca 206.108.0.131 2 u 2 64 1 40.845 -17.898 0.000 reject
Completed in 1.31 seconds
amorris@aws-vm.conductor
-field-eng# show config running authority router seattle-site-02-lanner system ntp
config
authority
router seattle-site-02-lanner
name seattle-site-02-lanner
system
ntp
server 0.north-america.pool.ntp.org
ip-address 0.north-america.pool.ntp.org
exit
server 1.north-america.pool.ntp.org
ip-address 1.north-america.pool.ntp.org
exit
server 2.north-america.pool.ntp.org
ip-address 2.north-america.pool.ntp.org
exit
server 3.north-america.pool.ntp.org
ip-address 3.north-america.pool.ntp.org
exit
exit
exit
exit
exit
exit
amorris@aws-vm.conductor
-field-eng# show config running authority router conductor-field-eng system ntp
config
authority
router conductor-field-eng
name conductor-field-eng
system
ntp
server 38.229.71.1
ip-address 38.229.71.1
exit
server 104.155.144.4
ip-address 104.155.144.4
exit
server 104.156.99.226
ip-address 104.156.99.226
exit
server 45.79.1.70
ip-address 45.79.1.70
exit
exit
exit
exit
exit
exit
amorris@aws-vm.conductor
-field-eng# show ntp router conductor-field-eng
Fri 2019-04-05 16:25:29 UTC
Node: aws-vm.conductor-field-eng
======== ================== ============== ========= ====== ====== ====== ======= ======== ======== ======== ============
Status Time Source Ref. ID Stratum Type When Poll Reach Delay Offset Jitter Tally Code
======== ================== ============== ========= ====== ====== ====== ======= ======== ======== ======== ============
active +clock.team-cymr 204.9.54.119 2 u 412 1024 377 26.871 -3.000 0.707 candidate
active *4.144.155.104.b 216.239.35.8 2 u 239 1024 377 29.206 -2.678 0.607 syspeer
active 104.156.99.226 .INIT. 16 u - 1024 0 0.000 0.000 0.000 reject
active +dfw0.clover.mat 129.7.1.66 2 u 491 1024 377 29.696 -1.411 0.642 candidate
This NTP sync traffic will utilize the "management" port and thus follow the Linux routing table.
Note, if using the FQDN approach, the mgmt interface must be able to resolve these FQDNs. The easiest way to do this is outlined in this article which cover both cases of out-of-band or in-band mgmt interfaces by setting up global DNS servers.
#NTP #Analytics #4.0.0
------------------------------
Adam Morris
Sales Engineer
WA
(206) 617-4999
Original Message:
Sent: 04-04-2019 05:10
From: Morne Vermeulen
Subject: NTP Configuration
Hi All,
Please provide some detail on how NTP is currently being deployed on nodes for customers, as well as if this might form part of conductor services in the future to make things simpler?
Regards,
------------------------------
Morne Vermeulen
Engineer
------------------------------