infoblox:ntp_on_infoblox
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| infoblox:ntp_on_infoblox [2021/09/23 10:24] – bstafford | infoblox:ntp_on_infoblox [2026/02/05 10:56] (current) – [NIOS-XaaS] bstafford | ||
|---|---|---|---|
| Line 2: | Line 2: | ||
| * There is a dedicated page for [[ntp: | * There is a dedicated page for [[ntp: | ||
| * There is a dedicated page for [[ntp: | * There is a dedicated page for [[ntp: | ||
| + | * From NOS 9.0.4 onwards, NIOS will not use static UTC offsets such as (UTC+2:00). Instead, it will only have time zone names with DST changes. To achieve this, NIOS fetches the time zone list from the Ubuntu tzdata package and updates the same in the database. | ||
| + | * When Grid members synchronize their times with the Grid Master, the Grid Master and its members send NTP messages through an encrypted VPN tunnel. When a Grid member synchronizes its time with another Grid member, the NTP messages are not sent through a VPN tunnel. | ||
| + | * Unofficial tests indicate that the small, virtual TE-825 NIOS appliance can easily handle over 10k NTP transactions per second (TPS). | ||
| + | * If you have configured DNS anycast on the appliance, it can answer NTP requests through the anycast IP address. | ||
| + | * NTP Working group member says stratum has almost no bearing on accuracy. GM should sync to 3+ sources. Limit to no more than 5 or 7 because you can run into some interesting reboot time issue on appliances if there are DNS issues which lead to NTP service not resolving NTP FQDN. | ||
| + | * If Members are serving NTP, then get members to sync out directly to Internet rather than to the GM. This ensures they are not dependent on GM for time. | ||
| + | * Considerations on whether to sync all members to GM and then sync GM to external or whether it is better to sync all members directly to external time sources. | ||
| + | * If you sync all members to external time sources, those time sources may not agree so the Grid members may never be fully in sync. | ||
| + | * If you sync all members to external time sources, if one members gets firewalled off from NTP by accident, it will drift off on its own. | ||
| + | * If you want to serve time from NIOS to the network, consider having each member sync to external time. | ||
| + | * If you are not serving time from NIOS to the network, consider having the members sync to the GM and the GM sync to the external time source. | ||
| + | * NTP best practice is actually 5+ servers. 3 NTP servers is too few. If one goes down, you are left with 2 (the magic ' | ||
| + | * Stratum of time source as almost no bearing on accuracy. That myth was started by people who sell time sources for exorbitant money. (Source: member of NTP working group) | ||
| + | * NIOS checks if the NTP is in sync or not every 4 seconds, if 5 consecutive checks fail, it will send a SNMP trap. I don't know what the offset diff has to be to be considered a sync fail. | ||
| + | * NTP listens on all interfaces. No specific config necessary for LAN2, other than possibly routing of course. | ||
| + | * With the containerization of NIOS it is more important to have a reliable external timezone because now ntpd is running inside a container which does worse at keeping time than when it was run at the VM level. | ||
| + | * For a disconnected NIOS hardware appliance, NTP time is not held well but no worse than anyone else. If the NIOS appliance is on KVM, or ESXi, then it can be much much much worse. This is why there are $10k-$20K NTP clocks that synchronize, | ||
| + | * For your time source list, also consider using one or two from time.nist.gov and something appropriate (Top Public Time Servers) from [[https:// | ||
| + | |||
| + | |||
| + | ===== Leap Seconds ===== | ||
| + | |||
| + | [[ http:// | ||
| + | |||
| + | NIOS has supported Leap Seconds since NIOS 6.5.0. | ||
| + | |||
| + | Properly configured NTP servers will send a leap second warning announcement to NTP clients. | ||
| + | |||
| + | The kernel in NIOS supports receiving the leap second warning announcement and doing the one second insertion at precisely the right time. In turn, the NIOS NTP servers send notifications to NTP clients which are configured to use the Infoblox appliances as NTP servers. | ||
| + | |||
| + | |||
| ===== Show NTP Data CLI ===== | ===== Show NTP Data CLI ===== | ||
| < | < | ||
| + | Example. Normally, you want the numbers in the ' | ||
| + | < | ||
| + | | ||
| + | ============================================================================== | ||
| + | +212.23.8.6 | ||
| + | *212.23.10.129 | ||
| + | | ||
| + | or | ||
| + | < | ||
| + | | ||
| + | ============================================================================== | ||
| + | -212.23.8.6 | ||
| + | +212.23.10.129 | ||
| + | | ||
| + | +216.239.35.12 | ||
| + | *17.253.28.251 | ||
| or | or | ||
| < | < | ||
| Line 10: | Line 57: | ||
| You can exit maintenance mode with | You can exit maintenance mode with | ||
| < | < | ||
| + | ===== NIOS-XaaS ===== | ||
| + | NIOS-XaaS instance use AWS for NTP source and show to end user as '' | ||
| + | a special NTP (Network Time Protocol) reference address that indicates a device is using its own local internal system clock as the time source (often labeled .LOCL.). | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | The NTP service offered by NIOS-X as a Service uses the Global NTP Settings (the " | ||
| + | |||
| + | Because throttling is applied per source IP, multiple devices behind the same NAT IP can collectively exceed the rate limit, even if each device individually polls at a reasonable rate. This could be plausible contributing factor in Rothschild (Continuation Computers Limited) case. | ||
| ===== Setting Time ===== | ===== Setting Time ===== | ||
| Time can be set under Grid Properties. Rememeber that you cannot set the time manually if the Grid is set to sync time from external servers (Grid NTP Settings). | Time can be set under Grid Properties. Rememeber that you cannot set the time manually if the Grid is set to sync time from external servers (Grid NTP Settings). | ||
| When the Grid Member joins the Grid Master and the time difference between Grid Member and the Grid Master is more than 60 seconds, then Grid Member restarts to adjust time with Grid Master and logs: " | When the Grid Member joins the Grid Master and the time difference between Grid Member and the Grid Master is more than 60 seconds, then Grid Member restarts to adjust time with Grid Master and logs: " | ||
| + | ===== Synctime ===== | ||
| + | NIOS 8.6.1 introduces the '' | ||
| + | external NTP server or a Grid Manager. When you run the '' | ||
| + | there are already configured NTP servers present. If they are present, it displays the list of NTP servers and you | ||
| + | have to choose from the list. If there are no NTP servers that are configured, you must specify the IP address of the | ||
| + | NTP server or Grid Manager with which you want to synchronize the system time. | ||
| + | |||
| + | Running this command will immediately sync the appliance to its configured NTP server. | ||
| + | |||
| + | Once the command is issued, there will be a confirmation, | ||
| + | |||
| + | To run the command, enter maintenance mode | ||
| + | < | ||
| + | Maintenance Mode > synctime | ||
| + | It is recommended to sync grid manager with external server first. | ||
| + | Do you want to continue ? (y or n): y | ||
| + | VPN IP Address of NTP Server in Grid: | ||
| + | 169.254.0.1 | ||
| + | If grid manager is not excluded as an NTP Server, please use above VPN IP address! | ||
| + | Configured external NTP servers: | ||
| + | 85.199.214.98 | ||
| + | If not use above VPN IP Address, and one of the servers above is reachable and a part of the list of configured NTP servers, please use that NTP server. | ||
| + | Last NTP server used to synchronize the time through the synctime command is: | ||
| + | 169.254.0.1 | ||
| + | Enter the NTP server' | ||
| + | |||
| + | The offset between server 85.199.214.98 and this system is 1.328228 seconds. | ||
| + | Because the offset is very small, we recommend that you let NTP server handle it. | ||
| + | The adjustment made to the system time will cause the product to restart. | ||
| + | Do you want to continue? (y or n)</ | ||
| + | |||
| ===== How Long Does it Take to Sync Time ===== | ===== How Long Does it Take to Sync Time ===== | ||
| Line 24: | Line 111: | ||
| * OR 1,558 minutes | * OR 1,558 minutes | ||
| * OR 26 hours | * OR 26 hours | ||
| + | |||
| + | Normally, you want the numbers in the ' | ||
| One (nasty) solution to get NIOS back in sync is the following | One (nasty) solution to get NIOS back in sync is the following | ||
| Line 54: | Line 143: | ||
| When you execute the show ntp command, the NIOS appliance displays the following information: | When you execute the show ntp command, the NIOS appliance displays the following information: | ||
| * **remote**: The IP address of the remote peer. | * **remote**: The IP address of the remote peer. | ||
| - | * **refid**: Identifies the reference clock. This will be the clock type if the NTP server is Stratum 1. If it is Stratam 2 or higher then the refid will be the IP address of the NTP server' | + | * **refid**: Identifies the reference clock. This will be the clock type if the NTP server is Stratum 1. If it is Stratam 2 or higher then the refid will be the IP address of the NTP server' |
| * **st**: The stratum of the remote peer. Indicates the stratum of the configured clock. Infoblox recommends that an external stratum 1 clock be configured as the NTP server if you are running an enterprise network. Other stratum clocks, such as stratum 2 or 3, can be configured as the NTP server when the Grid Member or Grid Master is blocked by the firewall and cannot reach the external stratum 1 clock. | * **st**: The stratum of the remote peer. Indicates the stratum of the configured clock. Infoblox recommends that an external stratum 1 clock be configured as the NTP server if you are running an enterprise network. Other stratum clocks, such as stratum 2 or 3, can be configured as the NTP server when the Grid Member or Grid Master is blocked by the firewall and cannot reach the external stratum 1 clock. | ||
| * **t**: The type of the peer, such as local (l), unicast (u) or broadcast (b). | * **t**: The type of the peer, such as local (l), unicast (u) or broadcast (b). | ||
| * **when**: When the last packet was received, in seconds. | * **when**: When the last packet was received, in seconds. | ||
| * **poll**: The polling interval, in seconds. | * **poll**: The polling interval, in seconds. | ||
| - | * **reach**: The reachability | + | * **reach**: The reach-ability |
| - | * **delay**: The current estimated delay, in seconds. Should be as low as possible. 1 - 10 is superbe. 11 - 20 great. 20 - 30 is more common and not bad. >100 is not so great. Delay (Latency) is the delay between the Local clock (NIOS appliance) and the external NTP servers. Delay varies depending upon the distance and network latency of the external NTP server. Normally, the delay can be between 5-40 Milliseconds. Choose the server with the least possible delay before configuring NTP. | + | * **delay**: The current estimated delay, in seconds. Should be as low as possible. 1 - 10 is superb. 11 - 20 great. 20 - 30 is more common and not bad. >100 is not so great. Delay (Latency) is the delay between the Local clock (NIOS appliance) and the external NTP servers. Delay varies depending upon the distance and network latency of the external NTP server. Normally, the delay can be between 5-40 Milliseconds. Choose the server with the least possible delay before configuring NTP. |
| * **offset**: The offset of the peer clock relative to the local clock, in milliseconds. The value should be something like (0.517). This means there is less than a second difference. If you see something line 39256.2 then your clock is about 39 second out-of-sync and it will take some time to correct (see above). Offset is the time difference in milliseconds from the external NTP server and local clock. Offset value more than 300 seconds (300,000 milliseconds) need a step change which need the '' | * **offset**: The offset of the peer clock relative to the local clock, in milliseconds. The value should be something like (0.517). This means there is less than a second difference. If you see something line 39256.2 then your clock is about 39 second out-of-sync and it will take some time to correct (see above). Offset is the time difference in milliseconds from the external NTP server and local clock. Offset value more than 300 seconds (300,000 milliseconds) need a step change which need the '' | ||
| * **jitter**: The estimated time error of the system clock. Should be a value less than 1.0. Ideally as close to 0.000 as possible (e.g. 0.205). | * **jitter**: The estimated time error of the system clock. Should be a value less than 1.0. Ideally as close to 0.000 as possible (e.g. 0.205). | ||
| + | ===== NTP Settings ===== | ||
| + | If the members are told to sync to Grid Master, they will do so over the VPN tunnel. If the tunnel is down (e.g. product reboot), then they will use whatever the Grid Master uses for NTP source. This can lead to long product reboots if there is a very long list of NTP servers to sync to and the member does not have access to any of them. Either permit access or reduce the list. | ||
| + | ===== Troubleshooting ===== | ||
| + | |||
| + | ==== NTP Error ==== | ||
| + | * Facility: '' | ||
| + | * Level: '' | ||
| + | * Server: '' | ||
| + | * Message: < | ||
| + | | ||
infoblox/ntp_on_infoblox.1632392662.txt.gz · Last modified: (external edit)