時刻同期というとサーバーを思い浮かべますが、ネットワーク機器、ESXiやvCenter、ストレージや複合機など、サーバー以外の機器の時刻も障害対応を左右します。そして仮想基盤では、ホストの時刻がVMの時刻を引き戻すことがあります。

第4回・第5回でLinuxとWindowsを見ました。第6回では、ネットワーク機器と仮想基盤、アプライアンスの時刻同期を扱います。

ネットワーク機器の時刻同期の考え方

ルーター、スイッチ、ファイアウォール、無線LANコントローラーなどのネットワーク機器も、ほぼすべてがNTPクライアントの機能を持ちます。

• 機器の時刻がずれると、障害のときにサーバーのログと機器のログを突き合わせられず、原因の特定が大きく遅れる。VPNの証明書の検証や、RADIUS・TACACS+のログ（連載「RADIUS入門」第16回「ログと監査」）、SNMPトラップの時刻にも影響する
• 設計の考え方はサーバーと同じで、社内のNTPサーバー（第7回）を2〜3台以上参照し、送信元のインターフェースを管理用のアドレスに固定して、ファイアウォールやアクセスリストの設定を単純にする
• 電源を切ると時刻を失う機器も多いため、起動直後の時刻にも注意する
• ログに記録するタイムゾーンと、ミリ秒まで記録するかどうかを全機器でそろえておくと、突き合わせが楽になる。対称鍵による認証（第8回）に対応した機種なら、有効にすることも検討する

冒頭の「ルーターとサーバーのログの順番がおかしい」は、時刻のずれか、タイムゾーン・精度の違いが原因のことが多いです。

Cisco IOSの設定例と確認

Router(config)# ntp server 192.0.2.123 prefer
Router(config)# ntp server 192.0.2.124
Router(config)# ntp source Loopback0
Router(config)# clock timezone JST 9 0
Router(config)# service timestamps log datetime msec localtime show-timezone

Router# show ntp status
Clock is synchronized, stratum 3, reference is 192.0.2.123
Router# show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.0.2.123     203.0.113.1      2     35     64   377  1.012   0.254   0.188
+~192.0.2.124     203.0.113.2      2     20     64   377  1.105  -0.132   0.201
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

• 出力は要所だけの抜粋。show ntp statusの1行目がClock is synchronizedか、stratumが期待どおりかを見る
• show ntp associationsの記号は、chronyと似ている：*同期先、+候補、x誤り、~設定したサーバー。reachは8進数（第4回）
• service timestamps log datetime msec …で、ログにミリ秒とタイムゾーンを残す
• 機種・OS（IOS XE、NX-OS、各社のファイアウォール）で書式は異なる。考え方（参照先・送信元・タイムゾーン・確認）を押さえ、書式は機種の手引で確かめる

ログのタイムスタンプの形式をそろえる

時刻が合っていても、ログの書き方がばらばらだと突き合わせに苦労します。syslogには、古い形式と新しい形式があります。

Sep 26 16:20:01 rt01 %LINK-3-UPDOWN: Interface Gi0/1, changed state to down
      ↑ RFC 3164 の形式：年・タイムゾーン・ミリ秒が無い
2026-09-26T16:20:01.123+09:00 rt01 LINK - - - Interface Gi0/1, changed state to down
      ↑ RFC 5424（RFC 3339 の日時）：年・ミリ秒・UTC からのオフセットがある

• 古い形式（RFC 3164）の「Sep 26 16:20:01」には、年もタイムゾーンもミリ秒も無い。年をまたぐ調査や、UTCで記録する機器との突き合わせで迷う
• 機器が対応していれば、RFC 5424の形式（2026-09-26T16:20:01.123+09:00のように年・ミリ秒・オフセット付き）で送る。Ciscoなら前の節のservice timestamps log datetime msec … show-timezoneが近い効果を持つ
• ログの収集基盤では、「機器が記録した時刻」と「受け取った時刻」を両方残す。機器の時計がずれていても、受け取った時刻から、おおよその順序を復元できる

時刻を合わせることと、時刻を読める形で残すことは、セットで考えます。

機器をNTPサーバーにするかどうか

ネットワーク機器の多くは、NTPサーバーとしても動けます。IOSなどでは、NTPを設定して同期すると、ほかの機器からの問い合わせにも応答するのが一般的です。

• 利点：拠点のコアスイッチを拠点内の機器の時刻源にすると、WANが切れても拠点内の時刻がそろう
• 欠点：機器の内蔵時計は品質が高くないことが多く、CPUの負荷が高いと応答の精度が落ちる。また、意図せず利用者のネットワークやインターネットにNTPを公開すると、増幅攻撃の踏み台や情報の漏えい（第8回）につながる

基本の方針は、サーバーや端末は社内のNTPサーバー（第7回）を直接参照し、機器を時刻源にするのは拠点の事情がある場合に限ることです。機器を時刻源にするときは、応答する相手をアクセスリスト（Ciscoではntp access-group）で絞り、参照の関係を構成図に残して、階層が循環しないようにします。

ESXi（ESX）ホストの時刻同期

[root@esx01:~] esxcli system ntp set -s ntp1.corp.example.jp -s ntp2.corp.example.jp -s ntp3.corp.example.jp -e 1
[root@esx01:~] esxcli system ntp get
[root@esx01:~] esxcli system time get

• ESXi（vSphere 9.0からの名称はESX）はUTCで動き、タイムゾーンは変えられない（vSphere Clientでは見る人の現地時刻で表示）
• 7.0 U3以降は設定がConfigStoreで管理され、/etc/ntp.confを直接編集しても正しく反映されない
• NTPサービスの起動ポリシーは「ホストと連動して開始・停止」にする

vCenterの時刻同期

# 管理インターフェース（https://vcenter01.corp.example.jp:5480）の Time でも設定できる
Command> ntp.set --servers ntp1.corp.example.jp,ntp2.corp.example.jp,ntp3.corp.example.jp
Command> ntp.test --servers ntp1.corp.example.jp,ntp2.corp.example.jp,ntp3.corp.example.jp
Command> timesync.set --mode NTP
Command> timesync.get

vCenterとホストの時刻がずれると、SAMLトークンや証明書が有効と認識されず、インストール・アップグレードの失敗や、vCenterのサービス（vpxd）が起動しない原因になります（Broadcom TechDocs）。デプロイや移行の前に、配置先のホストがNTPかPTPで同期していることを確かめます。

ホストの時刻とVMの時刻

冒頭の「vMotionでVMの時刻が3分進んだ」の答えです。

• VMware Toolsの「周期的な時刻同期」（1分ごとにホストに合わせる）は既定で無効で、ゲストOSのNTP（chrony、W32Time）を使うのが推奨
• ただし、VMの起動、一時停止からの再開、vMotion、スナップショットの作成と復元、VMware Toolsの再起動のときの「一回限りの同期」は既定で有効
• ホストの時刻がずれていると、vMotionの後にVMの時刻が突然ずれる。ゲストのNTPが正しくても、ホストの時計がVMを引き戻す
• 対策は、全ホストを同じ時刻源に同期させること。一回限りの同期を止めたいVMは「Synchronize at startup and resume」を外せる
• 高い精度が要るVMには、仮想ハードウェア17以降のPrecision Clock（ホストの時刻をPTPハードウェアクロックとして見せる仮想デバイス）もある

vSphereの時刻は、ホスト・vCenter・VMを同じ時刻源にそろえるのが基本です。

ストレージ・監視・複合機などのアプライアンス

NTPの設定画面が無い機器や、参照先を1台しか書けない機器もあります。導入時にNTPの対応（台数、DNS名を書けるか、認証やNTS）を確かめ、参照先を台帳に残します。古い機器は、停止した・停止予定の公開NTPサーバー（福岡大学など。第7回）を参照したままのことがあります。

時刻のずれが障害になる例

障害の調査では、まず関係する機器の時刻を並べて比べます。時刻そのものが原因の障害もあれば、時刻のずれのせいで調査を誤る場合もあります。切り分けの手順は第10回で扱います。

考えてみよう

1. 自分の職場のネットワーク機器、ESXi、vCenter、複合機などは、それぞれどこを時刻源にしていますか。台帳にできますか。
2. 「vMotionの後にVMの時刻が数分ずれた」と報告を受けました。何を疑い、どこから確かめますか。
3. 拠点のコアスイッチをNTPサーバーにしたいと相談されたら、何を確かめ、どんな条件を付けますか。

ヒント：この記事の「機器をNTPサーバーにするかどうか」の方針、ESXi・vCenter・ホストとVMの関係の図、アプライアンスの表と台帳が手がかりです。

まとめ

• ネットワーク機器も社内NTPを複数参照し、送信元を管理用に固定、ログのタイムゾーンとミリ秒をそろえる
• Ciscoはshow ntp status・show ntp associationsで確認。記号はchronyと似ている（~・-などは意味が違う）
• 機器をNTPサーバーにするのは拠点の事情があるときだけ。応答範囲をアクセスリストで絞る
• ESXiはUTC固定、esxcli system ntpで3台以上。vCenterはtimesync.set --mode NTP
• 一回限りの同期は既定で有効。ホストがずれているとvMotionでVMの時刻が飛ぶ
• アプライアンスは設定漏れが多い。時刻源の台帳で棚卸しする

次回は、ここまでの内容をもとに社内の時刻同期の階層を設計し、公開NTPサーバーやクラウドの時刻の使い方を扱います。

連載「NTP入門」全11回

全回の目次と、読む順番・目的別の読み方は、NTP入門の入口のページにまとめています。

1. なぜ時刻同期が必要か
2. 時刻の基礎知識
3. NTPの仕組み
4. Linuxの時刻同期（chrony）
5. Windowsの時刻同期
6. ネットワーク機器・仮想基盤（この記事）
7. 設計と推奨構成
8. NTPのセキュリティ
9. PTPと高精度同期
10. 時刻同期のトラブルシュート
11. 時刻同期の設計演習