【NTP入門 第6回】ネットワーク機器・仮想基盤の時刻同期 ― Cisco IOS、機器をNTPサーバーにするか、ESXi・vCenter、ホストとVMの時刻、アプライアンス

NTP サーバー
スポンサーリンク
スポンサーリンク

「vMotionでVMを移したら、そのVMの時刻が3分進みました。chronyはちゃんと動いているのに……」
「障害のとき、ルーターのログとサーバーのログを並べたら、順番がおかしくて原因が追えませんでした」

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

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

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

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

社内のntp1とntp2からUDP 123でルーター・コアスイッチ・ファイアウォール・無線LANコントローラーが時刻を受け取り、送信元はどの機器も管理用のLoopbackか管理VLANにそろえることと、時刻がそろっていれば16:20:01.123のrt01のGi0/1 down、.124のcore01のOSPF Nbr down、.126のfw01のVPN tunnel downのように別の機器のログを1本の時系列に並べられることを示す図
  • 機器の時刻がずれると、障害のときにサーバーのログと機器のログを突き合わせられず、原因の特定が大きく遅れる。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を設定して同期すると、ほかの機器からの問い合わせにも応答するのが一般的です。

本社の社内NTPサーバーからWAN経由で拠点のコアスイッチ（NTPサーバー役）が時刻を受け取り、拠点内のアクセスSW・複合機・監視カメラに配るため、WANが切れても拠点内の時刻がそろう一方、ntp access-groupで管理セグメントだけに応答させ、利用者のセグメントには応答しないようにすることを示す図
  • 利点：拠点のコアスイッチを拠点内の機器の時刻源にすると、WANが切れても拠点内の時刻がそろう
  • 欠点：機器の内蔵時計は品質が高くないことが多く、CPUの負荷が高いと応答の精度が落ちる。また、意図せず利用者のネットワークやインターネットにNTPを公開すると、増幅攻撃の踏み台や情報の漏えい（第8回）につながる

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

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

方式設定の場所（vSphere Client）要点
NTPホスト > Configure > System > Time Configuration > Add ServiceNTP サーバーは3台以上がベストプラクティス。NTP と PTP は同時に動かせない
PTP同上で Precision Time Protocol を選ぶハードウェアタイムスタンプは PCI パススルーの NIC（7.0 U3 では Intel X710・E810）、ソフトウェアは VMkernel アダプター。失敗時に NTP へ切り替える設定ができる
手動同上の Manual Set-UpNTP・PTP を止めたときだけ使える。大きくずれたホストを合わせる前処理
[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の時刻同期

モード意味使いどころ
NTPvCenter 自身が NTP サーバーと同期する推奨。ホストと同じ時刻源を指定する
HostVMware Tools で、動いているホストの時刻に合わせるホストの時刻が確実に正しい場合
Disabled同期しない使わない
# 管理インターフェース（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分進んだ」の答えです。

ESXi01（10:00:00で正しい）からESXi02（10:03:00で3分進み）へVMをvMotionすると、移った直後の一回限りの同期でVMの時計が＋3分飛び、chronyがslewで戻すまで最短でも約36分、ログと認証の時刻がずれたままになるため、全ホストを同じ社内NTPに同期させることを示す図
  • 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ハードウェアクロックとして見せる仮想デバイス）もある
社内NTPからESXiホスト全台（esxcli system ntp set、3台以上、UTCで動作）、vCenter（timesync.set --mode NTP、ホストと同じ時刻源）、ゲストOS（chrony／W32Time、周期的なToolsの同期は無効）をそろえ、一回限りの同期でホストの時刻がVMを上書きするため、ホストがずれているとvMotion直後にVMの時刻が飛びvSANの健全性チェックが警告することと、確認コマンドを示す図

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

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

機器時刻がずれると設定の注意
ストレージ（NAS・SAN）スナップショットの時刻の混乱、SMB の Kerberos 認証やレプリケーションの失敗AD と連携するなら DC と同じ時刻源
監視サーバー・SIEMアラートの時刻がずれ、相関分析ができない受信した時刻と機器側の時刻の両方を残す
バックアップ装置ジョブのスケジュールや保持期間の判定がずれるジョブの時刻が UTC かローカルかを確かめる
複合機スキャンしたファイルの保存（SMB）の認証失敗、ログの時刻のずれ既定の参照先が海外の公開サーバーのことがある。社内に向ける
UPS・PDU・BMC（iDRAC・iLO など）停電や障害の記録の時刻が狂う管理ネットワークから社内 NTP に届くようにする
入退室管理・監視カメラ記録や映像の証拠としての価値が下がる設定の漏れが多い。棚卸しの対象にする
機器・参照先・台数・送信元・ログのTZと精度・状態を1行にまとめた時刻源の台帳の例で、ルーターは2台参照なので3台に、ESXiとvCenterは3台で正常、複合機は海外の公開サーバー1台なので社内へ、UPS・iDRACは未設定、NASは停止予定の公開サーバーを参照しているので変更が必要と分かることを示す表

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

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

例何が起きるか目安
証明書の検証有効期間の外と判断され、TLS の接続や管理画面へのログインが失敗期間を外れた時点
Kerberos 認証ログオン、ファイル共有、SSO が失敗（連載「Kerberos入門」第4回）既定で5分
vCenter と ESXiSAML トークンや証明書が無効とされ、vpxd の起動、インストール、アップグレードが失敗ずれの大きさによる
vSAN健全性チェック「Time is synchronized across hosts and VC」が警告を出す60秒を超える差
vSphere HA・障害の調査ホストごとのイベントの時刻がずれ、フェイルオーバーの経過を追えない数秒でも問題
ログの突き合わせ障害の前後関係が逆転して見える数秒でも問題
ワンタイムパスワード（TOTP）コードが合わず、多要素認証が失敗30秒単位

障害の調査では、まず関係する機器の時刻を並べて比べます。時刻そのものが原因の障害もあれば、時刻のずれのせいで調査を誤る場合もあります。切り分けの手順は第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. 時刻同期の設計演習

コメント

タイトルとURLをコピーしました