網路時間協定（NTP）必備指南

【快速 copy/paste】

Google: (不建議設定成固定IP: 216.239.35.0 or 216.239.35.4)

用主機名稱才是正解。

TIME.google.com

TIME1.google.com

TIME2.google.com

TIME3.google.com

TIME4.google.com

Cloudflare:

TIME.cloudflare.com

National Time and Frequency Standard Laboratory of Taiwan:

TICK.stdtime.gov.tw

TOCK.stdtime.gov.tw

-----

在企業級基礎架構中，保持所有硬體元件的時間精準與同步，是維持維運基本要求的最低標準。網路時間協定（Network Time Protocol, NTP）是一種基於 UDP、運作於使用者模式（User-mode）的網路協定，它為伺服器、網路設備和用戶端節點之間的時間同步奠定了核心基礎。

時間在生產環境中的關鍵角色

大多數電腦系統都依賴內建且由電池供電的電子時鐘，這些時鐘隨著時間推移自然會產生偏移；此外，極少有企業能為每個節點配置昂貴的專用原子鐘硬體。當需要診斷系統故障時，這種時間偏差會讓問題變得極為棘手。如果不同節點上記錄的日誌文件（Log files）缺乏同步的系統時間，維運人員將很難重現事件發生的先後順序與時間線。

由於標準的 NTP 協定能提供毫秒（millisecond）等級的精準度，這讓工程師得以精確地合併並關聯來自完全不同基礎架構節點的日誌。有了NTP協助同步各節點的時鐘，我們得以快速重建事件紀錄的完整時間線，幫助我們找到問題所在。

協定變體：NTP vs. SNTP

NTP 是一個功能完整的時間同步協定。相對地，簡單網路時間協定（Simple NTP, SNTP）則是一個精簡版的協定變體。

在完整的 NTP 協定中，包含三種運作模式：對稱模式（Symmetric）、用戶端/伺服器模式（Client/Server）以及廣播模式（Broadcast）。而 SNTP 沿用了與 NTP 完全相同的封包格式，但僅實作了三種模式裡面的用戶端/伺服器模式。

值得慶幸的是，任何支援 SNTP 的用戶端都可以直接向標準 NTP 伺服器進行時間同步，且 NTP 伺服器端不需要進行任何特殊設定或調整。NTP 伺服器能同時為 NTP 用戶端和 SNTP 用戶端提供時間服務，而無需修改任何設定內容。

⚠️ 生產環境重要提示（關於 SNTP 的潛在風險）：

雖然 SNTP 與 NTP 伺服器完全相容，但 SNTP 不支援微調平滑時鐘（Clock Slewing）。標準 NTP 在校時時會以微幅加快或放慢時鐘的方式讓時間漸進平滑同步；而 SNTP 則會直接「跳躍式（Snap）」強制將本地時間修改為伺服器時間。這種時間驟變極易導致生產環境的資料庫（如 Oracle, SQL）當機、安全性憑證失效或導致日誌順序混亂，因此不建議在關鍵生產環境的資料庫或核心應用伺服器上使用 SNTP。

本文討論的主要是Cisco網路硬體設備，因此這個風險比較不嚴重。

典型的 NTP 部署架構場景

情境 0：極小規模環境（不超過 2 台設備/伺服器）

最實際的做法是直接將這兩台節點指向外部的公用 NTP 伺服器（Public NTP Servers）進行同步。

情境 1：中小型環境（3 台至數百台節點，無本地原子鐘）

建議部署扁平化的集中式架構。您必須指定至少兩台節點作為本地 NTP 伺服器。將這兩台本地伺服器設定與外部公用 NTP 伺服器同步，以獲取可信賴的時鐘來源。一般而言，其產生的本地階層（Stratum）將會是 Stratum 2 或 3（視上游公用伺服器的階層而定）。最後，將其餘所有的本地用戶端節點設定與這兩台本地伺服器同步。情境1形成了扁平化的集中式雙伺服器架構，如圖一所示。

圖一

情境 2：大型環境（數千台節點，無本地原子鐘）

當有數千台節點同時對少數幾台本地伺服器發送查詢時，可能會令本地伺服器的處理效能不堪負荷。在這種情況下，必須部署多層級的階層式架構（Multi-strata Topology）。您可以增加更多本地伺服器並將其劃分為多個時間階層：下層（例如階層三 Stratum 3）的伺服器面向本地上層（例如階層二 Stratum 2）的伺服器請求同步，以此類推。其餘的端點節點則根據其被指派的對應層級伺服器進行設定。情境2形成了多層級的階層式架構，可以用圖二來理解。

圖二

情境 3：擁有本地原子鐘的環境

若組織擁有原子鐘硬體並直接連接到 NTP 伺服器，則這些 NTP 伺服器即為核心的階層一Stratum 1 伺服器。在 Stratum 1 之下，您可以選擇直接讓剩下的端點節點進行連線，或是參考情境 1 增加一層階層二 Stratum 2 伺服器，甚至參考情境 2 擴展為多層級的架構（Multi-strata）。圖三說明了參考情境2擴展為多層級的階層式架構的可能部署範例。

圖三

連接公用 NTP 伺服器的配置最佳實踐

當基礎架構需要指向外部公用資源時，系統管理員應避免設定成寫死的靜態 IP 位址（例如 216.239.35.0）。使用固定 IP 會帶來結構性的維運缺點，因為公用NTP服務提供者會根據其管理需求隨時更改底層網路位址。

改用主機名稱（Hostname）設定，能強制節點在每次建立新的 NTP 連線階段時，都重新查詢並重新更新成正確的 IP 對應。此外，公用提供商普遍採用輪詢網域名稱系統（Round-robin DNS）來達到負載平衡。使用主機名稱可以讓用戶端的查詢在不同的解析嘗試中，無縫地分配到不同的 IP 位址，進而自然地分散網路請求的流量。

Cisco IOS 設定藍圖

在管理 Cisco 網路環境時，組態範本可依據設備角色分為：用戶端（Clients）、伺服器（Servers）和對稱同級節點（Peers）。

宣告身分驗證金鑰（Authentication Key）

在此範例中，我們定義一組新的 Key ID 99，其金鑰密碼內容為 "my_secret"。這組金鑰稍後將用於用戶端、伺服器和對稱同級節點之間的加密驗證。

ntp authentication-key 99 md5 my_secret

用戶端（Clients）

對於純粹作為用戶端的基礎架構節點，以下配置會將 NTP 查詢綁定到指定的來源介面（Source Interface），並設定首選的上游目標伺服器：

!標準 NTP 用戶端（無驗證範例，直接連接公用伺服器）：

!(注意：此範例將 Google 設定為首選 prefer，Cloudflare 為備援。實務上公用 NTP 伺服器通常不要求用戶端驗證。)

ntp server time.google.com source {來源介面名稱} prefer

ntp server time.cloudflare.com source {來源介面名稱}

標準 NTP 用戶端，加入啟用金鑰 99 驗證範例：

ntp authenticate

ntp trusted-key 99

ntp server {本地伺服器_IP_或_主機名稱_1} source {來源介面名稱} key 99 prefer

ntp server {本地伺服器_IP_或_主機名稱_2} source {來源介面名稱} key 99

舊型或僅支援 SNTP 的用戶端：

!SNTP 命令語法極為相似，僅需將關鍵字 ntp 改為 sntp。

sntp server time.google.com source {來源介面名稱} prefer

sntp server time.cloudflare.com source {來源介面名稱}

伺服器（Servers）

當 Cisco 設備與上游時間來源成功建立連線並同步後，它會自動開始為下游的 NTP 用戶端提供時間服務，不需額外指令。然而，若該設備失去了與上游的連線，它也會立即停止向後端用戶端提供校時服務。

為了避免這種因為短暫的上游離線而向後端停止服務的狀況，我們可以加入備援功能：當上游網路斷線時，允許設備改以節點本地時鐘作為權威時間來源宣告，其指令如下：

ntp master 5

這裡的整數值 5 代表階層（Stratum）等級，範圍為 1 到 15，數字越小代表時間源越可靠。在正常狀態下，設備的 Stratum 是透過上游提供商的 Stratum 數字加 1 動態計算出來的。 但這條備援指令告訴 Cisco IOS：一旦上游斷線，請立刻強制改宣告自己為 Stratum 5 繼續提供服務。除非您管理的是具備數千台設備、需要複雜多層級架構的龐大基礎設施，否則選擇中間數值（例如 5）是一個不錯的起點。

伺服器端（NTP Master）啟用金鑰驗證：

ntp authenticate

ntp trusted-key 99

ntp master 5

對稱同級節點（Symmetric Peers）

對於處於相同時間階層層級（Stratum）的本地 NTP 伺服器，彼此可以設定為對稱同級節點，來達到互相同步與校正時鐘的效果。此模式常配合雙伺服器備援架構使用。兩台設備皆需下達以下指令：

ntp peer {同級節點的主機名稱或IP} source {來源介面名稱}

啟用金鑰驗證的對稱同級節點配置：

ntp authenticate

ntp trusted-key 99

ntp peer {同級節點的主機名稱或IP} source {來源介面名稱} key 99

驗證 NTP 狀態

配置完成後，網路工程師可以使用以下兩項內建的診斷工具，來檢查時間同步的健康狀況以及同級節點的連線狀態：

show ntp status （用來查看整體同步狀態、當前階層等）

show ntp associations （用來查看與各別上游與同級節點的連線品質、Reachability 值等）

One more thing…

補充工具：Windows 用戶端快速自我排查

若您想在微軟 Windows 作業系統的電腦上，直接測試與確認遠端 NTP 伺服器是否正常回應、且中間沒有防火牆阻擋 UDP 123 埠口的封包，可在 Windows 命令提示字元（CMD）中執行以下指令：

w32tm /stripchart /computer:time.cloudflare.com /samples:3 /dataonly

在這個範例中，系統將會向目標伺服器 time.cloudflare.com 發送 3 次查詢（samples:3）並在終端機視窗中直接印出時間偏移結果。

💡 維運提醒： 在多數現代 Windows 企業安全性環境中，執行 w32tm 指令可能需要高權限。如果遇到拒絕存取的錯誤，請改以「系統管理員身分（Run as Administrator）」開啟命令提示字元再行測試。