NTP・Syslog・SNMPを1枚で理解する

NTP・Syslog・SNMPの役割と違い

NTPの役割と基本動作

NTP（Network Time Protocol）は、ネットワーク上の機器が基準となる時刻源へ同期するためのプロトコルです。 ルーター、スイッチ、ファイアウォール、サーバー、監視装置の時刻をそろえることで、障害やセキュリティ事象を正しい順番で追跡できます。

NTPが必要な理由

NTPの階層とStratum

NTPでは、基準時刻源からの論理的な距離をStratumで表します。 原子時計やGPSなどの基準時計そのものをStratum 0、それへ直接接続されたNTPサーバーをStratum 1、 さらにそのサーバーから同期する機器をStratum 2のように扱います。

Cisco IOS系のNTP設定例

clock timezone JST 9 0
ntp server 192.0.2.10 prefer
ntp source Loopback0
service timestamps log datetime msec localtime show-timezone

この設定例では、次の内容を指定しています。

• clock timezone JST 9 0：表示上のタイムゾーンをJSTへ設定
• ntp server 192.0.2.10 prefer：NTPサーバーを指定
• ntp source Loopback0：NTPパケットの送信元インターフェースを固定
• service timestamps log ...：ログへミリ秒・タイムゾーン付きの時刻を表示

NTPの確認コマンド

show clock detail
show ntp status
show ntp associations

確認する主なポイントは次のとおりです。

• synchronizedになっているか
• 参照先のIPアドレスが設計どおりか
• reachが継続して更新されているか
• offsetやdelayが異常に大きくないか
• 送信元IPアドレスやVRFが想定どおりか

NTPが同期しないときの確認順序

1. NTPサーバーへの経路を確認する対象VRFからNTPサーバーへ到達できるか確認します。
2. UDP 123の通信制御を確認するACLやファイアウォールで往復通信が許可されているか確認します。
3. 送信元IPアドレスを確認するNTPサーバー側で許可された送信元と一致しているか確認します。
4. サーバー側の同期状態を確認する参照先のNTPサーバー自体が未同期ではないか確認します。
5. 認証・VRF・設定値を確認する認証キー、VRF、ホスト名解決、設定先IPの誤りを確認します。

Syslogの役割とSeverity

Syslogは、OSやネットワーク機器が生成したイベントメッセージを、ローカルへ保存したり、外部のSyslogサーバーへ転送したりする仕組みです。 インターフェースの状態変化、ルーティングプロトコルのネイバー変化、認証失敗、設定変更、再起動などを記録できます。

Syslogメッセージから読み取る情報

Cisco IOS系のメッセージは、一般に%FACILITY-SEVERITY-MNEMONICの形式で表示されます。 たとえば%LINK-3-UPDOWNなら、FacilityはLINK、Severityは3、メッセージ識別子はUPDOWNです。

Severity 0〜7

SyslogのSeverityは、数字が小さいほど重大です。 転送レベルを5に設定した場合は、通常0〜5のメッセージが対象になります。

Cisco IOS系のSyslog設定例

service timestamps log datetime msec localtime show-timezone
logging host 192.0.2.20
logging trap informational
logging source-interface Loopback0
logging buffered 32768 informational

• logging host：外部Syslogサーバーを指定
• logging trap informational：Severity 0〜6を外部へ送信
• logging source-interface：送信元インターフェースを固定
• logging buffered：機器内部のログバッファへ保存

Syslogの確認コマンド

show logging
show running-config | include logging|service timestamps

Syslogが届かない場合は、次を確認します。

• 機器内部には対象ログが生成されているか
• 転送Severityに対象メッセージが含まれているか
• SyslogサーバーのIPアドレスとポートが正しいか
• 送信元IPアドレスがサーバー側の許可条件と一致するか
• サーバー側で受信・保存・検索できているか
• UDP利用時に途中で失われていないか

SNMPの役割とポーリング・Trap

SNMP（Simple Network Management Protocol）は、監視サーバーがネットワーク機器の管理情報を取得したり、 機器が状態変化を監視サーバーへ通知したりするための仕組みです。

SNMPマネージャー・エージェント・MIB・OID

ポーリングとTrapの違い

カウンター値は差分と時間で読む

インターフェースの受信バイト数など、多くのSNMP値は起動後からの累積カウンターです。 監視ソフトは、前回値との差分を取得間隔で割り、ビット毎秒などの利用率へ変換します。

カウンターの桁あふれ、機器再起動、インターフェース再初期化、取得失敗があると、グラフへ異常値が出ることがあります。 数字だけで障害と断定せず、Syslogや稼働時間と照合します。

SNMPv1・v2c・v3の違い

Cisco IOS系のSNMPv3設定例

snmp-server view MONITOR iso included
snmp-server group MONITOR-GRP v3 priv read MONITOR
snmp-server user monitor MONITOR-GRP v3 auth sha AuthPass-Example priv aes 128 PrivPass-Example
snmp-server host 192.0.2.30 version 3 priv monitor
snmp-server enable traps snmp linkdown linkup coldstart warmstart
snmp-server trap-source Loopback0

設定の主な意味は次のとおりです。

• view：参照を許可するOID範囲を定義
• group ... v3 priv：認証と暗号化を要求するグループを定義
• user：SNMPv3ユーザーと認証・暗号化方式を設定
• host：通知先NMSを指定
• enable traps：送信する通知種類を有効化
• trap-source：通知の送信元インターフェースを固定

SNMPの確認コマンド

show snmp
show snmp user
show snmp group
show running-config | section snmp

SNMP監視ができないときは、次を分けて確認します。

• ポーリング不可：UDP 161、認証、暗号化方式、View、ACL、送信元IP、OID対応
• Trap不可：UDP 162、通知先、Trap種別、送信元IP、NMS側受信設定
• 値が不自然：カウンター再初期化、取得間隔、64bitカウンター、MIB差異、機器再起動

NTP・Syslog・SNMPを組み合わせた障害調査

3つの役割を、実際のインターフェース障害で確認します。

1. NTPで時刻をそろえる スイッチ、上位ルーター、ファイアウォール、サーバーの時刻を同じ基準へ同期させます。
2. SNMP Trapで状態変化を検知する linkDown通知を受信し、監視システムがアラームを生成します。
3. SNMPポーリングで現在状態を確認する インターフェースが現在もdownか、トラフィックが停止したか、エラーが増えていたかを確認します。
4. Syslogで発生内容と前後関係を確認する link downの直前にエラー、設定変更、再起動、STP変化などがなかったか確認します。
5. 他機器・サーバーの記録と時刻で照合する 同じ時刻帯のルーティング変化、冗長切り替え、利用者申告、アプリケーションログを比較します。

調査結果の報告例

この報告では、単に「ポートがdownです」と伝えるのではなく、検知方法、現在状態、前後ログ、時刻の信頼性、次の確認内容を示しています。

設定・設計で確認するポイント

1．送信元IPアドレスを固定する

NTP、Syslog、SNMP Trapの送信元が物理インターフェースのIPアドレスだと、経路変更やポートダウンで送信元が変わることがあります。 Loopbackインターフェースなどへ固定すると、ACL、監視対象登録、ログ検索を安定させやすくなります。

2．監視用の通信経路を明確にする

• 管理VRFを使用するか
• 管理ネットワークと業務ネットワークを分離するか
• 障害時にも監視経路が残るか
• インバンド管理かアウトオブバンド管理か
• 戻り経路やファイアウォールセッションが成立するか

3．冗長化と依存関係を整理する

NTPサーバー、Syslogサーバー、NMSが1台だけでは、そのサーバー停止時に監視機能を失います。 複数宛先、クラスタ、別拠点保管、ローカルバッファなどを組み合わせます。

4．何を監視し、何を通知するかを決める

すべてのログ・すべてのOID・すべてのTrapを集めるだけでは、重要な異常が大量の情報へ埋もれます。 次の観点で監視項目を整理します。

• 死活：装置へ応答があるか
• 状態：インターフェース、ネイバー、冗長化状態
• 性能：帯域、CPU、メモリー、遅延、エラー
• イベント：設定変更、再起動、認証失敗、リンク変化
• 通知：誰へ、どの時間帯に、どの優先度で連絡するか

監視できないときの切り分け

「監視サーバーに何も表示されない」とき、すぐにネットワーク機器側の設定ミスと断定してはいけません。 情報の生成、送信、転送、受信、保存、表示のどこで止まっているかを分けます。

共通の確認手順

1. 設定値を確認する 宛先IP、ポート、バージョン、ユーザー、Severity、Trap種別、送信元インターフェースを確認します。
2. 送信元から宛先への到達性を確認する 管理VRF、ルーティング、ARP、戻り経路を確認します。通常のpingだけで対象UDP通信の許可までは証明できません。
3. ACL・ファイアウォールを確認する NTPのUDP 123、Syslogの使用ポート、SNMPのUDP 161／162など、実際の通信条件を確認します。
4. 機器内部で情報が生成されているか確認する ローカルログ、インターフェース状態、SNMP統計、NTP状態を確認します。
5. 監視サーバー側を確認する 待ち受け、認証、フィルター、保存先、ライセンス、時刻範囲、画面表示条件を確認します。
6. パケットキャプチャーで境界を確認する 必要に応じて送信元・中継・受信側でパケットを確認し、どこまで届いているかを判断します。

症状別の確認ポイント

NTP・Syslog・SNMPに関するよくある勘違い

自分の言葉で説明する課題