はじめに
ネットワーク機器を運用する上で、正確な時刻管理 は重要なポイントです。ルーターの時刻がズレているとログの時系列突き合わせが困難になり、障害解析の効率が大きく低下します。また、デジタル証明書の検証、スケジュール機能、SAML／Kerberos などの認証連携といった 時刻に依存する機能が正常に動作しなくなる リスクもあります。
Cisco ルーターはデフォルトで UTC（協定世界時） で動作するため、日本国内で運用する場合は JST（日本標準時）への変更と、NTP サーバーとの同期設定が推奨されます。
本記事は Cisco IOS XE 17.x を前提に、タイムゾーン設定・NICT との同期・認証・トラブルシュートまでをまとめます。
参考: Cisco IOS XE 17 – Network Time Protocol
“We strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time.”
（誤った時刻が偶発的または悪意を持って設定されることを防ぐため、NTP のセキュリティ機能の利用を強く推奨します）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/syst-mgmt/b-system-management/m_bsm-time-calendar-set.html
- タイムゾーンの設定（UTC → JST）と NTP サーバー同期の基本手順
- NICT（情報通信研究機構）の公開 NTP サーバー利用と
61.205.120.130の正体 - HMAC-SHA2-256 を使った NTP 認証設定
show ntp associations／show ntp statusの見方- 同期できない場合のトラブルシューティングと運用上の制約
タイムゾーンの設定（UTC から JST へ）
Cisco ルーターの初期状態では内部時計が UTC で動作しています。このままでは、例えば 9:00（JST）に発生したログが「00:00 UTC」と記録されてしまい、日本時間で時系列を直感的に追えません。日本国内で運用する場合は JST に変更することが一般的です。
設定コマンド
グローバルコンフィグレーションモードで以下のコマンドを実行します。JST は表示用のラベル名、9 は UTC からの時差（+9 時間）です。
Router(config)# clock timezone JST 9
これでルーターの時刻表示が日本時間になります。なお、日本では夏時間（サマータイム）が運用されていないため、clock summer-time の設定は不要です。
NTP サーバーの設定
ルーターが時刻情報を取得しにいく親（NTP サーバー）を指定します。
推奨される公開 NTP サーバー（NICT など）
日本国内で運用する場合、NICT（情報通信研究機構） が提供している公開 NTP サーバーが広く利用されています。
| サーバー | Stratum | 備考 |
|---|---|---|
ntp.nict.jp | Stratum 1 | NICT 公式。複数の IP（61.205.120.130 など）を持つ |
pool.ntp.org | Stratum 2 | 世界的な NTP サーバープール（複数サーバーへの負荷分散） |
設定コマンド（ntp server）
グローバルコンフィグレーションモードで同期先サーバーを指定します。特定のサーバーを優先したい場合は末尾に prefer オプションを付けます。
! NICT のサーバーを優先（prefer）に設定
Router(config)# ntp server ntp.nict.jp prefer
! バックアップとして NTP プールを設定
Router(config)# ntp server pool.ntp.org参考: Cisco IOS XE Catalyst SD-WAN Qualified Command Reference – NTP Commands
https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-ntp-commands.html
ドメイン名で設定する場合の注意
ntp.nict.jp などのドメイン名を使用するには、ルーター自身が名前解決できるよう DNS サーバーの設定（ip name-server 8.8.8.8 など）が事前に必要です。DNS が利用できない環境では、IP アドレスで直接指定することが推奨されます。
Router(config)# ip name-server 8.8.8.8
! または DNS なしで IP 直接指定
Router(config)# ntp server 61.205.120.130 preferなお、IOS XE 17.x の仕様として、FQDN と IP アドレスの両方を同じ NTP サーバーとして設定した場合、show running-config の出力には FQDN のみが表示される 動作になります。
送信元インターフェイスの固定（ntp source）
ルーターが複数のインターフェイス（WAN・LAN・VPN トンネル等）を持っている場合、NTP パケットの送信元 IP はルーティング状況によって変動する可能性があります。
送信元 IP が不安定だと、NTP サーバー側のセキュリティフィルタで弾かれる、戻りパケットが意図しない経路を通るなど、同期が不安定になる原因となります。これを防ぐため、NTP 通信の送信元インターフェイスを固定する設定が推奨されます。
! インターフェイス名は環境に合わせて変更（例: GigabitEthernet0、Dialer1、Loopback0 等）
Router(config)# ntp source Loopback0特に Loopback インターフェイスを送信元に指定する設計 が、物理リンクの up/down に影響を受けない安定した構成として広く採用されています。
VPN 越しに NTP を同期する構成では、VPN トンネル経由のパケット送信元として Loopback または LAN 側の固定 IP を指定する ことで、トンネルダウン時の挙動も安定します。VPN 構築の詳細は、関連記事『Cisco VTI を使った IPsec VPN の設定例｜IKEv2 と GRE 不要構成』を参照してください。
動作確認: ステータスと記号の見方
設定完了後、正しく時刻が同期されているかを確認します。NTP の同期収束には一般的に 5〜10 分程度かかる ため、設定直後ではなく時間をおいて確認します。
時刻の確認（show clock）
現在の時刻とタイムゾーンが意図通りかを確認します。
Router# show clock
15:30:00.000 JST Wed Feb 10 2026JST: タイムゾーン設定が反映され、日本時間になっていること- 時刻先頭に
.（ドット）が付いていないこと
. が付いている場合、ルーター内部のハードウェアクロックで動作している（NTP 未同期） 状態を示します。
同期ステータスの詳細（show ntp associations）
NTP サーバーとの接続状況を詳細に確認します。
Router# show ntp associations
address ref clock st when poll reach delay offset disp
*~61.205.120.130 .NICT. 1 45 64 377 5.123 0.456 1.234
+~129.250.35.251 204.2.140.74 2 41 64 377 8.567 1.234 2.345
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured左端の記号の意味
| 記号 | 意味 |
|---|---|
*（アスタリスク） | 現在同期中のサーバー（sys.peer）。これがあれば正常 |
# | 選択候補（selected） |
+（プラス） | 通信は成功しているが待機状態の候補（candidate） |
-（マイナス） | 統計から外れ値と判定（outlyer） |
x | 偽情報の可能性ありと判定（falseticker） |
~（チルダ） | コンフィグで静的に設定されたサーバー |
その他の重要項目
| 項目 | 意味 |
|---|---|
st（Stratum） | 階層。Stratum 1 から同期している場合、自身は Stratum 2 になる。16 は同期不能状態 |
when | 最後に NTP パケットを受信してからの秒数 |
poll | ポーリング間隔（秒）。デフォルトは 64 秒、安定すると最大 1024 秒まで延長 |
reach | 到達性を 8 進数（8 ビット）で表示。377 であれば直近 8 回すべて成功 |
delay | サーバーまでの往復遅延（ミリ秒） |
offset | サーバーとの時刻差（ミリ秒） |
詳細表示が必要な場合は detail オプションを利用します。
Router# show ntp associations detail同期状態の要約（show ntp status）
ルーター自身が NTP クライアントとして正常かを確認できるコマンドです。
Router# show ntp status
Clock is synchronized, stratum 2, reference is 61.205.120.130
...Clock is synchronized と表示されていれば NTP 同期は正常に完了しています。Clock is unsynchronized の場合は、まだ同期が完了していないか、通信設定に問題があります。
「61.205.120.130」とは何か
show ntp associations や show ntp status の出力に、設定した覚えのない 61.205.120.130 という IP アドレスが表示されることがあります。
結論: NICT の NTP サーバーの実体 IP
61.205.120.130 は、NICT（情報通信研究機構）が運用する公開 NTP サーバー ntp.nict.jp の実体 IP アドレスの 1 つ です。
NICT は 複数の IP アドレスをラウンドロビンで提供 しており、ntp.nict.jp を DNS で名前解決するたびに、61.205.120.130、61.205.120.131、133.243.238.243、133.243.238.244 などのいずれかが返されます。
設定では FQDN、表示では IP になる理由
ルーター側の設定（ntp server ntp.nict.jp）は FQDN ですが、実際に NTP パケットを送出する際にはルーターが DNS で名前解決を行い、解決された IP アドレスをアソシエーション情報として保持します。そのため、show ntp associations には 解決後の IP アドレスが表示 される動作となります。
表示内容に問題はない
61.205.120.130 が表示されることは正常な動作です。同様に 129.250.35.251（NTT 系）や 133.243.238.x 系（NICT の別系統）が表示されるケースも、いずれも公開 NTP サーバーの実体 IP です。
不審な IP が表示されている場合のみ、設定した覚えのない NTP サーバーへの問い合わせが行われていないか show running-config | include ntp で確認することが推奨されます。
NTP 認証によるセキュリティ強化
NTP は標準では認証なしの平文通信であり、悪意ある第三者が偽の NTP サーバーを立てて誤った時刻を配信する「時刻偽装攻撃」のリスク があります。本番環境では NTP 認証の有効化が推奨されます。
参考: DISA STIG – Cisco IOS XE Router NDM Security Technical Implementation Guide
“If Network Time Protocol is not authenticated, an attacker can introduce a rogue NTP server. This rogue server can then be used to send incorrect time information to network devices, which will make log timestamps inaccurate and affect scheduled actions.”
（NTP が認証されていない場合、攻撃者は不正な NTP サーバーを導入できます。これにより誤った時刻情報がネットワーク機器に送られ、ログのタイムスタンプが不正確になり、スケジュール処理にも影響します）
https://stigviewer.com/stigs/cisco_ios_xe_router_ndm/
推奨アルゴリズム: HMAC-SHA2-256
Cisco IOS XE 17.x では以下の認証アルゴリズムが利用可能です。
| アルゴリズム | 推奨度 | 備考 |
|---|---|---|
md5 | 非推奨 | 衝突攻撃の対象。後方互換用途のみ |
hmac-sha1 | 非推奨寄り | SHA-1 の衝突リスク |
hmac-sha2-256 | 推奨 | NIST 推奨。DISA STIG の要件にも準拠 |
cmac-aes-128 | 利用可 | AES ベースの代替 |
新規構築では hmac-sha2-256 の選定が推奨されます。
設定コマンド
NTP 認証は 対向の NTP サーバー側でも同じキー ID／キー値／アルゴリズムを設定する必要がある ため、社内の NTP サーバー階層で利用するケースが中心です（公開 NTP サーバー ntp.nict.jp などには適用できません）。
! 1. 認証機能を有効化
Router(config)# ntp authenticate
!
! 2. 認証キーの定義（ID 1 に HMAC-SHA2-256 で鍵値を設定）
Router(config)# ntp authentication-key 1 hmac-sha2-256 <16文字以上のランダム文字列>
!
! 3. 信頼するキー ID を指定
Router(config)# ntp trusted-key 1
!
! 4. NTP サーバーごとに使用するキー ID を紐付け
Router(config)# ntp server 10.0.0.1 key 1 prefer参考: Cisco IOS XE 17 – Network Time Protocol Configuration
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/syst-mgmt/b-system-management/m_bsm-time-calendar-set.html
認証状態の確認
show ntp associations detail の出力で authenticated が表示されていれば、認証付きで同期できています。
Router# show ntp associations detail
10.0.0.1 configured, authenticated, our_master, sane, valid, stratum 2
...機種・IOS バージョンによる対応状況
hmac-sha2-256 は IOS XE 17.x の Catalyst 9000 系／ISR4K／ISR1K／Catalyst 8000 系などで利用可能ですが、Catalyst 2960X 系のレガシー機種では MD5 のみのサポート といったケースがあります。導入前に対象機種・IOS バージョンの対応状況を確認することが推奨されます。
NTP のアクセス制御（ntp access-group）
ntp access-group は、ACL で許可された送信元からのみ NTP 通信を受け付ける 機能です。認証よりも軽量で、ルーターへの NTP アクセスを送信元 IP ベースで制御できます。
4 つのアクセスレベル
ntp access-group には 4 つのアクセスレベルがあり、最も制限の緩いものから厳しい順に評価されます。
| アクセスレベル | 許可される動作 |
|---|---|
peer | 時刻同期要求・NTP 制御クエリの受付＋自身も対向に同期される |
serve | 時刻同期要求・NTP 制御クエリの受付（自身は対向に同期されない） |
serve-only | 時刻同期要求のみ受付（制御クエリ不可） |
query-only | NTP 制御クエリのみ受付（時刻同期は提供しない） |
設定例: 信頼する NTP ピアのみ許可
! NTP 通信を許可する送信元を ACL で定義
ip access-list standard ACL-NTP-PEERS
permit host 10.0.0.1
permit host 10.0.0.2
deny any log
!
! NTP アクセスグループを設定
ntp access-group peer ACL-NTP-PEERSこの設定により、10.0.0.1 および 10.0.0.2 からの NTP 通信のみが許可され、それ以外の送信元からの NTP パケットはドロップされます。
参考: Cisco IOS XE Catalyst SD-WAN – NTP Commands
https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-ntp-commands.html
認証と access-group の併用
実運用では、ntp access-group で送信元を絞り込み、ntp authenticate で内容を保証する 二段構えの構成が標準的です。STIG 準拠など高セキュリティ要件の環境では両者の併用が推奨されます。
Cisco ルーターを NTP マスターとして使う
社内に閉じたネットワークやインターネット接続のないセグメントでは、コアスイッチ／コアルーターを NTP マスターとして配下機器に時刻配信する 構成がよく採られます。Cisco IOS XE では ntp master コマンドで実現できます。
構成イメージ
コアルーター側の設定例
! NICT から時刻を取得（クライアント動作）
ntp server ntp.nict.jp prefer
ntp source Loopback0
!
! 自身を NTP マスターとして公開（Stratum 5 として配信）
ntp master 5
!
! 配下からの NTP 要求を許可するアクセス制御
ip access-list standard ACL-NTP-CLIENTS
permit 192.168.0.0 0.0.255.255
ntp access-group serve-only ACL-NTP-CLIENTSntp master <stratum> の Stratum 値は、外部 NTP との同期が失われた場合に配下に通知する自身の Stratum 値です。実運用では 5〜10 程度の中間値を設定 し、外部同期が生きている間は実 Stratum（NICT に同期していれば 2）が使われます。外部同期が途切れた場合のみ ntp master の値が採用されます。
配下機器側の設定例
ntp server 10.0.0.1 prefer
ntp source Vlan10社内階層で ntp authenticate を併用する構成が、エンタープライズ環境の標準的な設計です。
同期されない場合のトラブルシューティング
設定を行っても show ntp associations のステータスが * にならない、または Clock is unsynchronized のままの場合、以下を順に確認します。
ACL／ファイアウォール設定の確認
よくある原因として、ルーターの ACL や上位ファイアウォールで NTP パケット（UDP/123）が拒否されているケースがあります。
! ACL の設定例（UDP/123 を許可、名前付き拡張 ACL で管理）
ip access-list extended ACL-WAN-IN
permit udp host 61.205.120.130 any eq ntp
permit udp host 133.243.238.243 any eq ntpWAN 側で ZBFW（Zone-Based Firewall）を運用している場合は、Self Zone への NTP 通信を許可するゾーンペアの設定 も必要となります。ZBFW での Self Zone 制御の詳細は、関連記事『Cisco ZBFW の仕組みと設定手順｜ゾーンと Self Zone のポイント』を参照してください。
送信元インターフェイスの問題
ルーターが複数の IP アドレスを持っている場合、NTP サーバーへ送るパケットの送信元 IP が、サーバー側で認識できない、または戻りルートがないアドレスになっている可能性があります。VPN 環境や OSPF など経路が複数ある場合は特に発生しやすく、Loopback インターフェイスを送信元に指定することで解決するケースが多い です。
Router(config)# ntp source Loopback0NTP デバッグログの取得
上記の確認で原因が特定できない場合、デバッグコマンドを使用して NTP パケットの送受信を直接確認します。
Router# debug ntp packets ! NTP パケットの送受信
Router# debug ntp adjust ! 時刻調整の詳細
Router# debug ntp validity ! 認証・検証の結果
! 確認後はデバッグを停止
Router# undebug all参考: Cisco IOS XE 17 – System Management Configuration Guide
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/syst-mgmt/b-system-management/m_bsm-time-calendar-set.html
ログ出力で xmit packet rejected や peer dispersion などのエラーが見られる場合、サーバー側の問題か経路上の問題かを切り分けます。
大幅な時刻ズレ（panic threshold）
ルーターの内部時計と NTP サーバーの時刻差が 1000 秒（約 17 分）以上ある場合、NTP は自動同期を拒否 する仕様です。この場合は、まず手動で時刻を近い値に合わせてから NTP 同期を待ちます。
! 特権モードで手動時刻設定（タイムゾーン設定済みなら JST で入力）
Router# clock set 15:30:00 10 Feb 2026NTP 運用上の制約と留意点
NTP の運用設計時に把握しておくと役立つ、構造的な制約と留意点を整理します。
古い NTP バージョンの脆弱性
NTP 4.2.4p7 以前のバージョンには、認証なしのリモート攻撃で DoS 状態を引き起こす脆弱性 があります。古い IOS／IOS XE を運用している環境では、IOS バージョン自体のアップデートも検討する価値があります。
参考: Cisco Catalyst IR8300 – Configuring NTP
“NTP versions 4.2.4p7 and earlier are vulnerable to unauthenticated remote attacks that may cause a Denial of Service (DoS) condition.”
（NTP 4.2.4p7 以前は認証なしのリモート攻撃に脆弱で、DoS 状態を引き起こす可能性があります）
https://www.cisco.com/c/en/us/td/docs/routers/ir8340/software/configuration/b-ir8340-timing-ios-xe-17/m-configuring-ntp.html
同期収束に時間がかかる
NTP は複数のサンプルを統計処理して安定した時刻に収束させる仕組みのため、設定直後に即座に同期するわけではありません。
| 状況 | 同期収束までの目安 |
|---|---|
| 新規設定／再起動直後 | 5〜10 分 |
| ネットワーク経路変更後 | 3〜5 分 |
ntp source 変更後 | 1〜3 分 |
設定直後に Clock is unsynchronized と表示されても、数分待って再確認することが推奨されます。
falseticker 判定による除外
複数の NTP サーバーを設定している場合、ルーターは各サーバーから取得した時刻を統計処理し、明らかに異常な値を返すサーバーを falseticker として自動的に除外 します。show ntp associations 出力の左端に x が表示されているサーバーはこの状態です。意図せず信頼するサーバーが falseticker 判定された場合は、対向サーバー自体の時刻精度や、経路上の遅延ばらつきを確認します。
Stratum 16 は同期不能状態
show ntp associations の st 列に 16 が表示されている場合、そのサーバーは現在他の NTP ソースと同期できていない状態 を意味し、ルーターも同期先として採用しません。長時間続く場合はサーバー側の問題を疑います。
インターフェイス単位での NTP 受信を無効化
特定のインターフェイス（例: WAN 側）からの NTP パケット受信を完全に拒否したい場合は、インターフェイスコンフィグで ntp disable を指定します。
interface GigabitEthernet0/0
ntp disable ! このインターフェイスでは NTP パケットを受信しないまとめ
本記事では、Cisco IOS XE 17.x における NTP 設定の手順と、NICT 同期・認証・運用上の留意点を解説しました。
- タイムゾーンを
clock timezone JST 9で日本時間に設定する - 公開 NTP サーバーは NICT（
ntp.nict.jp／61.205.120.130系） が国内では広く利用されている 61.205.120.130は NICT がラウンドロビンで提供する実体 IP の 1 つであり、正常な動作- 送信元インターフェイスは
ntp source Loopback0で固定するのが安定構成として広く採用されている - 本番環境では
hmac-sha2-256を使った NTP 認証＋ntp access-groupの併用が推奨される - 同期しない場合は ACL／ZBFW・送信元 IP・
panic thresholdを順に切り分ける - 社内階層では
ntp masterでコア機器から配下へ時刻配信する構成が標準的
以上、最後までお読みいただきありがとうございました。
