この記事は、 「ネットワーク中級編｜構築・検証・障害切り分けを身につける」 の第29回です。
ネットワーク機器の時刻をそろえるNTP、イベントを記録するSyslog、 状態や性能を取得するSNMPを組み合わせ、障害を検知・調査できる状態を目指します。
NTP・Syslog・SNMPとは？役割・違い・監視での使い分けと設定例を図解
ネットワーク障害を調査するときは、「いつ起きたか」「何が起きたか」「現在どうなっているか」を分けて確認します。 この記事では、NTP・Syslog・SNMPの役割、通信方向、使用ポート、Cisco IOS系の設定例、 SNMPv3の考え方、監視できないときの切り分けまで順番に解説します。
ルーターのインターフェースがダウンしたとき、機器の画面を見続けていなければ異常に気づけません。 また、異常に気づいても、機器ごとの時計がずれていれば、複数装置のログを正しい順番に並べられません。
そこで必要になるのが、NTPによる時刻同期、Syslogによるイベント記録、SNMPによる状態監視です。 3つは似た監視機能ではなく、それぞれ別の役割を担当します。
この記事を読み終えるとできること
- NTP・Syslog・SNMPの役割を区別できる
- ポーリングとTrapの違いを説明できる
- SyslogのSeverityを読み取れる
- SNMPv2cとSNMPv3の違いを説明できる
- Cisco IOS系の基本設定・確認コマンドを読める
- 監視情報が届かない原因を順番に切り分けられる
NTP・Syslog・SNMPを1枚で理解する
NTPは時刻をそろえる仕組み、Syslogは発生した出来事を記録・転送する仕組み、 SNMPは機器の状態や性能を取得し、異常を通知する仕組みです。
ネットワーク監視における3つの役割
NTP
「いつ起きたか」を正しく比較するため、複数機器の時計を同じ時刻源へ同期させます。
Syslog
「何が起きたか」をメッセージとして残します。リンクダウン、設定変更、認証失敗などを調査できます。
SNMP
「現在どうなっているか」「どのように推移したか」を取得します。CPU、トラフィック、エラー数などを監視できます。
3つは競合する機能ではなく、組み合わせて使う機能です。
SNMPで異常を検知し、Syslogで原因候補を確認し、NTPで複数機器の記録を正しい時系列へ並べます。
NTP・Syslog・SNMPの役割と違い
| 比較項目 | NTP | Syslog | SNMP |
|---|---|---|---|
| 主な目的 | 機器の時刻同期 | イベント・エラーの記録と転送 | 状態・性能情報の取得と異常通知 |
| 代表的な相手 | NTPサーバー | Syslogサーバー | SNMPマネージャー／NMS |
| 通信のきっかけ | クライアントが定期的に時刻を照会 | 機器でイベントが発生 | 定期ポーリング、またはTrap／Inform |
| 主な情報 | 基準時刻、時刻差、同期状態 | 時刻、機器名、Severity、メッセージ | インターフェース状態、カウンター、CPU、メモリーなど |
| 代表的なポート | UDP 123 | UDP 514が一般的 TLSではTCP 6514など |
照会：UDP 161 Trap：UDP 162 |
| 障害調査で分かること | ログ時刻を信頼できるか | 何が、いつ、どの機器で起きたか | 現在値、推移、しきい値超過、状態変化 |
ポート番号だけで通信可否を判断しないでください。
TCP・UDP、送信方向、送信元IPアドレス、VRF、NAT、ACL、ファイアウォール、監視サーバー側の待ち受け設定まで確認します。 SyslogやSNMPは製品・設定によって別トランスポートを使う場合もあります。
NTPの役割と基本動作
NTP（Network Time Protocol）は、ネットワーク上の機器が基準となる時刻源へ同期するためのプロトコルです。 ルーター、スイッチ、ファイアウォール、サーバー、監視装置の時刻をそろえることで、障害やセキュリティ事象を正しい順番で追跡できます。
NTPが必要な理由
ログを時系列で並べる
ルーターでは10時00分、ファイアウォールでは10時04分と記録されていると、どちらが先に発生したか判断できません。
認証や証明書の判定を安定させる
時刻が大きくずれると、証明書の有効期間、ワンタイムパスワード、認証チケットなどの判定に影響することがあります。
運用作業の証跡を残す
設定変更、ログイン、再起動、フェイルオーバーなどの時刻が一致していれば、作業記録と機器ログを照合できます。
監視グラフを正しく読む
トラフィック増加、CPU上昇、リンク断などを同じ時間軸で比較できます。
NTPの階層とStratum
NTPでは、基準時刻源からの論理的な距離をStratumで表します。 原子時計やGPSなどの基準時計そのものをStratum 0、それへ直接接続されたNTPサーバーをStratum 1、 さらにそのサーバーから同期する機器をStratum 2のように扱います。
NTPの階層イメージ
Stratumの数字が小さい機器を無条件に選べばよいわけではありません。 到達性、遅延、安定性、認証、冗長性、運用管理のしやすさも含めて時刻源を設計します。
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は時刻同期の仕組みです。タイムゾーン設定は、同期した時刻を人にどう表示するかという設定です。 UTCで統一するかJSTで表示するかは、監視基盤・サーバー・運用手順と合わせて決めます。
NTPの確認コマンド
show clock detail show ntp status show ntp associations
確認する主なポイントは次のとおりです。
- synchronizedになっているか
- 参照先のIPアドレスが設計どおりか
- reachが継続して更新されているか
- offsetやdelayが異常に大きくないか
- 送信元IPアドレスやVRFが想定どおりか
NTPが同期しないときの確認順序
- NTPサーバーへの経路を確認する対象VRFからNTPサーバーへ到達できるか確認します。
- UDP 123の通信制御を確認するACLやファイアウォールで往復通信が許可されているか確認します。
- 送信元IPアドレスを確認するNTPサーバー側で許可された送信元と一致しているか確認します。
- サーバー側の同期状態を確認する参照先のNTPサーバー自体が未同期ではないか確認します。
- 認証・VRF・設定値を確認する認証キー、VRF、ホスト名解決、設定先IPの誤りを確認します。
Syslogの役割とSeverity
Syslogは、OSやネットワーク機器が生成したイベントメッセージを、ローカルへ保存したり、外部のSyslogサーバーへ転送したりする仕組みです。 インターフェースの状態変化、ルーティングプロトコルのネイバー変化、認証失敗、設定変更、再起動などを記録できます。
Syslogメッセージから読み取る情報
時刻
Jul 31 10:15:03.482 JST
Facility
LINK
Severity
3
内容
Gi1/0/24がdownへ変化
Cisco IOS系のメッセージは、一般に%FACILITY-SEVERITY-MNEMONICの形式で表示されます。
たとえば%LINK-3-UPDOWNなら、FacilityはLINK、Severityは3、メッセージ識別子はUPDOWNです。
Severity 0〜7
SyslogのSeverityは、数字が小さいほど重大です。 転送レベルを5に設定した場合は、通常0〜5のメッセージが対象になります。
Severityが低い数字だから、必ず利用者影響が大きいとは限りません。
重大度はメッセージ生成側の分類です。実際の影響は、対象ポート、冗長化状態、利用サービス、発生継続時間、同時発生ログなどと組み合わせて判断します。
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：機器内部のログバッファへ保存
転送レベルをDebugにすればよい、とは限りません。 メッセージ量、回線帯域、保存容量、検索性、監視サーバー負荷を考慮し、必要なSeverityやFacilityを設計します。
Syslogの確認コマンド
show logging show running-config | include logging|service timestamps
Syslogが届かない場合は、次を確認します。
- 機器内部には対象ログが生成されているか
- 転送Severityに対象メッセージが含まれているか
- SyslogサーバーのIPアドレスとポートが正しいか
- 送信元IPアドレスがサーバー側の許可条件と一致するか
- サーバー側で受信・保存・検索できているか
- UDP利用時に途中で失われていないか
Syslogには機器名、IPアドレス、ユーザー名、構成情報などが含まれる場合があります。
管理ネットワークへ分離し、送信元を制限し、必要に応じてTCP/TLSなどの信頼性・暗号化機能を検討します。
SNMPの役割とポーリング・Trap
SNMP（Simple Network Management Protocol）は、監視サーバーがネットワーク機器の管理情報を取得したり、 機器が状態変化を監視サーバーへ通知したりするための仕組みです。
SNMPマネージャー・エージェント・MIB・OID
SNMPマネージャー
NMSなどの監視側です。機器へ問い合わせを送り、取得した値を保存・グラフ化・しきい値判定します。
SNMPエージェント
ルーターやスイッチなどの監視対象側で動作し、管理情報を保持して問い合わせへ応答します。
MIB
管理対象となる情報を体系化した定義です。インターフェース、CPU、システム情報などを扱います。
OID
MIB内の個別項目を識別する番号です。監視ソフトはOIDを指定して値を取得します。
ポーリングとTrapの違い
| 比較項目 | ポーリング | Trap／Inform |
|---|---|---|
| 通信の起点 | NMSから機器へ問い合わせる | 機器からNMSへ通知する |
| 主な用途 | 定期的な状態・性能取得 | 状態変化や異常の即時通知 |
| 例 | トラフィック量、CPU、メモリー、エラー数 | linkDown、再起動、認証失敗など |
| 長所 | 現在値と推移を継続して取得できる | 次回ポーリングを待たずに通知できる |
| 注意点 | 間隔の間に短時間の事象を見逃す場合がある | 通知が失われる可能性や、設定漏れがある |
ポーリングとTrapは併用します。
Trapで即時に状態変化を検知し、ポーリングで現在状態と性能推移を確認します。 Trapだけ、またはポーリングだけでは、検知漏れや情報不足が起こりやすくなります。
カウンター値は差分と時間で読む
インターフェースの受信バイト数など、多くのSNMP値は起動後からの累積カウンターです。 監視ソフトは、前回値との差分を取得間隔で割り、ビット毎秒などの利用率へ変換します。
通信速度 ≒（今回のカウンター − 前回のカウンター）× 8 ÷ 経過秒数
カウンターの桁あふれ、機器再起動、インターフェース再初期化、取得失敗があると、グラフへ異常値が出ることがあります。 数字だけで障害と断定せず、Syslogや稼働時間と照合します。
SNMPv1・v2c・v3の違い
| バージョン | 認証の考え方 | 暗号化 | 運用上の考え方 |
|---|---|---|---|
| SNMPv1 | Community String | なし | 古い実装との互換用途。新規採用は避ける |
| SNMPv2c | Community String | なし | GetBulkなどを利用できるが、Communityが平文で扱われる |
| SNMPv3 | ユーザーと認証 | Privacy設定で暗号化可能 | 新規設計では原則として優先する |
SNMPv3でも、設定しただけで安全になるわけではありません。
強い認証・暗号化方式、十分なパスフレーズ、読み取り専用権限、MIB View、送信元制限、管理ネットワーク分離を組み合わせます。
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つの役割を、実際のインターフェース障害で確認します。
Gi1/0/24がダウンした場合の情報の流れ
- NTPで時刻をそろえる スイッチ、上位ルーター、ファイアウォール、サーバーの時刻を同じ基準へ同期させます。
- SNMP Trapで状態変化を検知する linkDown通知を受信し、監視システムがアラームを生成します。
- SNMPポーリングで現在状態を確認する インターフェースが現在もdownか、トラフィックが停止したか、エラーが増えていたかを確認します。
- Syslogで発生内容と前後関係を確認する link downの直前にエラー、設定変更、再起動、STP変化などがなかったか確認します。
- 他機器・サーバーの記録と時刻で照合する 同じ時刻帯のルーティング変化、冗長切り替え、利用者申告、アプリケーションログを比較します。
調査結果の報告例
10時15分03秒、SW1のGi1/0/24でlinkDownを検知しました。 SNMPポーリングでも同時刻以降の受信トラフィックが0となり、現在もoperStatusはdownです。 Syslogには同時刻のLINK-3-UPDOWNが記録されていますが、直前の設定変更・再起動ログは確認されていません。 SW1はNTPサーバー192.0.2.10へ同期済みであり、上位機器のログ時刻とも一致しています。 次に物理配線、対向装置、光レベルを確認します。
この報告では、単に「ポートがdownです」と伝えるのではなく、検知方法、現在状態、前後ログ、時刻の信頼性、次の確認内容を示しています。
設定・設計で確認するポイント
1．送信元IPアドレスを固定する
NTP、Syslog、SNMP Trapの送信元が物理インターフェースのIPアドレスだと、経路変更やポートダウンで送信元が変わることがあります。 Loopbackインターフェースなどへ固定すると、ACL、監視対象登録、ログ検索を安定させやすくなります。
2．監視用の通信経路を明確にする
- 管理VRFを使用するか
- 管理ネットワークと業務ネットワークを分離するか
- 障害時にも監視経路が残るか
- インバンド管理かアウトオブバンド管理か
- 戻り経路やファイアウォールセッションが成立するか
3．冗長化と依存関係を整理する
NTPサーバー、Syslogサーバー、NMSが1台だけでは、そのサーバー停止時に監視機能を失います。 複数宛先、クラスタ、別拠点保管、ローカルバッファなどを組み合わせます。
NTP
- 複数の時刻源
- preferの扱い
- 上位NTPの健全性
- 認証・アクセス制限
Syslog
- 複数サーバーへの転送
- ローカルバッファ
- 保存期間と容量
- 転送方式と暗号化
SNMP
- NMS冗長化
- ポーリング間隔
- Trap送信先
- MIB・OID対応確認
共通
- 送信元IP固定
- ACL・FW許可
- DNS・経路・VRF
- 設定変更時の試験
4．何を監視し、何を通知するかを決める
すべてのログ・すべてのOID・すべてのTrapを集めるだけでは、重要な異常が大量の情報へ埋もれます。 次の観点で監視項目を整理します。
- 死活：装置へ応答があるか
- 状態：インターフェース、ネイバー、冗長化状態
- 性能：帯域、CPU、メモリー、遅延、エラー
- イベント：設定変更、再起動、認証失敗、リンク変化
- 通知：誰へ、どの時間帯に、どの優先度で連絡するか
次の記事では、死活・性能・ログ・しきい値・通知先を整理し、 監視項目を設計する方法を詳しく解説します。
監視できないときの切り分け
「監視サーバーに何も表示されない」とき、すぐにネットワーク機器側の設定ミスと断定してはいけません。 情報の生成、送信、転送、受信、保存、表示のどこで止まっているかを分けます。
情報が機器で作られたか
宛先・条件が正しいか
経路・ACL・FWは正常か
サーバーで処理できたか
共通の確認手順
- 設定値を確認する 宛先IP、ポート、バージョン、ユーザー、Severity、Trap種別、送信元インターフェースを確認します。
- 送信元から宛先への到達性を確認する 管理VRF、ルーティング、ARP、戻り経路を確認します。通常のpingだけで対象UDP通信の許可までは証明できません。
- ACL・ファイアウォールを確認する NTPのUDP 123、Syslogの使用ポート、SNMPのUDP 161／162など、実際の通信条件を確認します。
- 機器内部で情報が生成されているか確認する ローカルログ、インターフェース状態、SNMP統計、NTP状態を確認します。
- 監視サーバー側を確認する 待ち受け、認証、フィルター、保存先、ライセンス、時刻範囲、画面表示条件を確認します。
- パケットキャプチャーで境界を確認する 必要に応じて送信元・中継・受信側でパケットを確認し、どこまで届いているかを判断します。
症状別の確認ポイント
| 症状 | 優先して確認する項目 |
|---|---|
| NTPが未同期 | NTPサーバー到達性、UDP 123、送信元IP、上位サーバー同期状態、認証 |
| ローカルログはあるがSyslogサーバーにない | 転送Severity、logging host、送信元IP、ACL・FW、受信サービス、フィルター |
| SNMPポーリングだけ失敗 | UDP 161、SNMPバージョン、ユーザー／Community、認証・暗号化、View、OID |
| ポーリングは成功するがTrapが来ない | UDP 162、Trap送信先、enable traps、対象Trap種別、trap-source、NMS受信設定 |
| 監視グラフの時刻がずれる | 機器・NMS・DBのNTP状態、UTC／JST、ブラウザ表示、夏時間設定 |
NTP・Syslog・SNMPに関するよくある勘違い
NTPは、複数機器のログ、監視グラフ、認証、作業記録を同じ時間軸で比較するための基盤です。
Syslogはイベントメッセージが中心です。継続的なCPU、帯域、エラー数、稼働状態の取得にはSNMPなどの監視手段が必要です。
Trap種別の有効化、通知先、しきい値、対応MIB、NMS側ルールが必要です。Trapが定義されていない異常や、通知前に装置が停止する事象もあります。
SNMPv2cには通信内容を暗号化する仕組みがありません。複雑な文字列でも、ネットワーク上での秘匿性は別問題です。
Severityはメッセージ分類です。実際の影響は、対象、冗長性、継続時間、業務利用状況を含めて判断します。
NTPで時刻の信頼性を確保し、SNMPで異常と推移を捉え、Syslogで具体的なイベントを追跡します。
理解度チェック
次の7問に答えてください。解答を見る前に、「時刻」「イベント」「状態・性能」のどれを扱う問題か整理しましょう。
問題1．複数機器のログを正しい時系列で比較するため、最初に整備すべき仕組みはどれですか。
- DNS
- NTP
- NAT
- STP
解答を見る
NTPで各機器の時刻を同じ基準へ同期します。
問題2．インターフェースの帯域使用率を5分間隔で継続取得したい場合、最も適した仕組みはどれですか。
- SNMPポーリング
- NTP
- Syslogだけ
- ARP
解答を見る
SNMPポーリングでインターフェースカウンターを定期取得し、差分から利用率を計算します。
問題3．SyslogのSeverityについて正しい説明はどれですか。
- 数字が大きいほど重大
- 0〜7ではなく1〜10を使用する
- 数字が小さいほど重大
- Severityは時刻同期の精度を表す
解答を見る
Severity 0がEmergency、7がDebugで、数字が小さいほど重大です。
問題4．SNMPポーリングは成功していますが、linkDownのTrapだけ届きません。優先して確認する項目を3つ挙げてください。
解答を見る
- linkDown Trapが機器で有効化されているか
- 通知先IPアドレスとUDP 162の通信が正しいか
- trap-sourceとNMS側の登録・受信設定が一致しているか
問題5．SNMPv3を新規設計で優先する主な理由は何ですか。
解答を見る
ユーザー単位の認証と、Privacy設定による暗号化を利用できるためです。加えて、Viewやアクセス制限を組み合わせます。
問題6．logging trap warningsを設定した場合、Severity 5のメッセージは通常リモートSyslogへ送信されますか。
解答を見る
warningsはSeverity 4なので、通常0〜4が対象です。Severity 5を含めるにはnotificationsなど、設計に合ったレベルを指定します。
問題7．監視サーバーへpingが通れば、SNMPポーリングも必ず成功すると判断できますか。
解答を見る
pingはICMPの確認です。SNMPのUDP 161、認証、暗号化、View、ACL、NMS設定は別に確認します。
実践演習：監視通知が不足する原因を特定しよう
次の小規模ネットワークを想定します。
演習構成
発生事象
10時15分ごろ、利用者端末が切断されました。SW1のGi1/0/24はdownですが、監視画面にlinkDownアラームが表示されず、 Syslogサーバーにも対象ログが見つかりません。監視グラフの時刻も実際より約4分遅れています。
現在の設定と出力
課題1．設定・状態の問題点を3つ以上挙げる
課題1の解答例を見る
- 設計上のNTPサーバーは192.0.2.10だが、192.0.2.11が設定されている
- NTPがunsynchronizedで、ログ時刻が信頼できない
logging trap warningsはSeverity 0〜4が対象で、Severity 5のログが転送対象外- SNMP通知先は設定されているが、
snmp-server enable traps ...が確認できない - Gi1/0/24はadministratively downであり、物理断ではなく設定操作によるshutdownの可能性が高い
課題2．修正方針を考える
Syslog：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
SNMP：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
課題2の解答例を見る
- NTP：正しいサーバー192.0.2.10へ修正し、UDP 123、経路、送信元、サーバー同期状態を確認する
- Syslog：運用要件に応じて
logging trap notificationsまたはinformationalへ変更し、Severity 5を収集対象へ含める - SNMP：linkDown／linkUp Trapを有効化し、trap-source、UDP 162、NMS側受信ルールを確認する
課題3．調査結果を報告文へまとめる
課題3の報告例を見る
利用者端末が接続されているSW1のGi1/0/24はadministratively downとなっており、設定操作によるshutdownが原因候補です。 SW1のローカルログにはSeverity 5の状態変更が記録されていますが、リモートSyslogの転送レベルがwarningsのため、Syslogサーバーへ送信されていません。 また、linkDown Trapの有効化設定がなく、NMSへ通知されていない可能性があります。 NTPの参照先IPも設計値と異なり未同期のため、表示時刻が約4分ずれています。 正しいNTP参照先への修正、Syslog転送レベルの見直し、SNMP Trap有効化を実施し、試験用ポートで通知確認を行います。
自分の言葉で説明する課題
上司から「NTP・Syslog・SNMPは、全部監視の仕組みではないのですか」と質問されました。 1分程度で違いと組み合わせる理由を説明してください。
Syslogは＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
SNMPは＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。
説明例を見る
NTPはネットワーク機器の時計を同じ時刻へそろえる仕組みです。 Syslogはリンクダウンや設定変更など、機器で起きた出来事をメッセージとして記録・転送します。 SNMPはCPUやトラフィック、インターフェース状態を定期取得し、状態変化をTrapで通知できます。 SNMPで異常を検知し、Syslogで具体的な原因候補を確認し、NTPで複数機器の記録を正しい時系列に並べるため、3つを組み合わせます。
まとめ
- NTP：機器の時刻をそろえ、ログや監視情報を同じ時間軸で比較できるようにする
- Syslog：リンク変化、設定変更、認証失敗などのイベントを記録・転送する
- SNMP：状態・性能をポーリングし、Trap／Informで状態変化を通知する
- SyslogのSeverityは0〜7で、数字が小さいほど重大
- SNMPはポーリングとTrapを併用し、現在値・推移・即時通知を補完する
- 新規設計ではSNMPv3を優先し、認証・暗号化・View・送信元制限を組み合わせる
- 監視できない場合は、生成・送信・転送・受信・表示のどこで止まったかを切り分ける
- 送信元IP、VRF、ACL、ファイアウォール、サーバー側設定まで含めて確認する
NTP・Syslog・SNMPを正しく組み合わせると、「異常を検知する」「何が起きたか調べる」「複数機器の記録を時系列でつなぐ」という障害対応の土台を作れます。
参考仕様・公式資料
- RFC 5905：Network Time Protocol Version 4
- RFC 8633：Network Time Protocol Best Current Practices
- RFC 5424：The Syslog Protocol
- RFC 5426：Transmission of Syslog Messages over UDP
- RFC 5425：TLS Transport Mapping for Syslog
- RFC 3411：SNMP Management Frameworks
- RFC 3414：User-based Security Model for SNMPv3
- Cisco：SNMP Configuration Guide, Cisco IOS XE 17
- Cisco：Cisco IOS XE Software Hardening Guide
コマンド構文、対応暗号方式、初期値、ログ形式、Trap種類は、ベンダー、機種、OS、ソフトウェアバージョンによって異なります。 本番環境へ設定する前に、対象製品の公式ドキュメント、現行コンフィグ、監視サーバー仕様を確認してください。
コメント