変更要約: 初版
4.1障害診断の道具（debug・ping・traceroute・SNMP・syslog）
debugとCPU負荷を抑える条件付きdebug、L3到達性を測るping（拡張pingのsource/size/df-bit）、経路上のどこで止まるかを見るtraceroute、機器状態をポーリング/通知で集めるSNMP、事象を時系列で残すsyslogと重大度（severity）の設計を、「本番機に負荷をかけずに、どの道具で何を確定させるか」という切り分けの判断として学びます。
ネットワークアシュアランスは「壊れてから調べる」技術ではなく、平常時の状態を測り続け、異常時に最短で原因の層と箇所を確定させる技術です。ENCORのこの領域で最も問われるのは、道具の名前ではなく道具の選択順です。本番のコアルータでいきなりdebug ip packetを叩けばCPUが飽和して障害を増やしかねません。まずは負荷ゼロのshowと、既に流れているsyslogを読み、次に到達性をping/tracerouteで切り分け、それでも足りないときに範囲を絞ったdebugへ進む——この順序が実務でも試験でも正解の骨格です。
4.1.1debug と条件付き debug
debugはプロセスの内部処理をリアルタイムに出力するため、プロセススイッチングを誘発しCPU使用率を跳ね上げる。本番機ではdebug ip packetのような広範なdebugは事実上禁じ手で、まずshow ip ospf neighbor・show interfaces・show loggingなど負荷のかからないshowで仮説を絞るのが定石。有効中のdebugはshow debuggingで確認し、undebug all（=no debug all）で確実に止める。- 条件付きdebug＝
debug condition interface GigabitEthernet0/1のように条件を先に設定してからdebugを有効化すると、出力が該当インターフェイス（あるいはdebug condition ipなどのフィルタ）に一致するものだけに絞られ、CPU負荷と出力量を劇的に抑えられる。条件はshow debug conditionで確認し、undebug allではなくno debug condition allで解除する点に注意（条件だけ残ると次のdebugが意図せず絞られる）。 - debug の出力先は既定でコンソールのみ。SSH/Telnet の vty で見るには
terminal monitorが必要で、後から読み返したいならlogging buffered 8192 debuggingのようにバッファに落としてshow loggingで回収するほうが安全（コンソール出力はコンソールが低速だと機器全体を遅くする）。時刻の突合のためservice timestamps debug datetime msecとNTP同期を先に整えておく。
4.1.2ping と traceroute で到達性を切り分ける
- 通常の
pingは出力インターフェイスのIPを送信元に使うため、「ルータからは通るのに利用者からは通らない」ケースを再現できない。拡張pingでping 10.20.0.10 source Loopback0のように実際の通信と同じ送信元を指定すると、戻り経路（リバースルート）やACLの非対称性が露見する。sizeとdf-bitを組み合わせたping 10.20.0.10 size 1500 df-bitは経路MTUの検出に有効で、失敗する最小サイズがボトルネックのMTUを示す。 tracerouteはTTLを1ずつ増やしたプローブを送り、各ホップから返るICMP time-exceededで経路を可視化する（IOSは既定でUDPプローブ、WindowsのtracertはICMP echo）。どのホップから先で応答が変わるかが切り分けの主眼で、traceroute 10.20.0.10 source Loopback0のように送信元も揃える。- 中間ホップの
* * *は必ずしも経路断ではない。多くの機器はICMP応答をレート制限し、あるいはポリシーでtime-exceededを抑止しているため、途中が無応答でも最終ホップが応答していれば転送自体は成功している。逆に「最終行まで届かず、あるホップ以降が全て無応答」なら、そのホップの先を疑う。!H（ホスト到達不能）や!A（管理上禁止＝ACL遮断）などの記号は原因を直接示す強い手がかりになる。
4.1.3SNMP と syslog（重大度の設計）
- SNMPは管理サーバ（NMS）がOID単位で値をポーリング（get/getnext/getbulk・UDP161）し、機器側からはtrap（送りっぱなし）またはinform（受信確認あり・再送する）で通知する（UDP162）。v2c はコミュニティ名が平文なので運用系ではv3（
authPriv＝認証＋暗号化）を選ぶ。「取りこぼしが許されない通知」なら trap ではなく inform を選ぶのが判断ポイント。 - syslogの重大度は0が最も重い：0 emergencies / 1 alerts / 2 critical / 3 errors / 4 warnings / 5 notifications / 6 informational / 7 debugging。
logging trap 4は「レベル4以下（数値が同じか小さい＝より重大）」だけをサーバへ送る設定で、%LINK-3-UPDOWN（レベル3）は送られるがdebug出力（レベル7）は送られない。この非対称が現場でも試験でも頻出の落とし穴。 - 送出先と粒度は独立に設計する：
logging host 10.50.0.9（宛先）、logging trap <level>（サーバ向け）、logging buffered <size> <level>（ローカルバッファ）、logging console <level>（コンソール）。logging console debuggingのまま放置すると、コンソールへの書き出しが機器を詰まらせるため、本番ではlogging console critical程度に絞り、詳細はバッファとサーバで受けるのが定石。show loggingで現在の各出力先とレベルを確認できる。
「本番機のdebugはdebug condition interface等で先に条件を絞る」「条件解除はno debug condition all」「拡張pingのsourceで実通信と同じ送信元を再現・size＋df-bitで経路MTU検出」「traceroute中間の* * *は必ずしも断ではない（ICMPレート制限/抑止）」「syslog重大度は0が最重・7がdebugging」「logging trap 4ではdebug（7）は送られない」「SNMP trapは確認なし・informは確認あり／v2cは平文でv3がauthPriv」が頻出です。道具の選択順（show→syslog→ping/traceroute→絞ったdebug）として覚えると解けます。
本社のディストリビューションスイッチで、支店向けWANルータとのOSPF隣接が1日に数回だけフラップし、そのたびに数十秒の通信断が出ています。CPU使用率は平常時でも55〜65%あり、debug ip ospf adjを無条件で有効にすると全隣接（12本）の出力が流れてCPUがさらに跳ね上がるため、そのまま叩くのは選択肢になりません。まずshow loggingを見ると%OSPF-5-ADJCHGが散発しており、直前に%LINK-3-UPDOWNではなく%OSPF-4-ERRRCVが出ていることから、物理断ではなくOSPFパケットの受信異常が疑われます。ここでの正しい一手は、対象を問題の隣接が乗るインターフェイス1本に限定することで、debug condition interface GigabitEthernet0/1を設定してからdebug ip ospf adjを有効化し、さらに出力はコンソールではなくlogging buffered 16384 debuggingへ落としてshow loggingで回収します。並行してping 10.10.0.2 source Vlan10 size 1500 df-bitを打つと失敗し、size 1476で成功したとすれば、経路上にMTU 1476のトンネル区間があることが確定し、OSPFのDBD交換が大きなパケットで詰まってフラップしていた、という仮説が一気に有力になります。逆に、ここでtracerouteの途中ホップが* * *だったことを根拠に「経路が切れている」と結論づけるのは誤りで、最終ホップが応答している以上転送は成立しており、中間機器のICMPレート制限を見ているだけです。また調査後にundebug allだけを実行して満足するのも危険で、no debug condition allを打たないと条件が残り、次に別の障害でdebugを有効にしたとき「なぜか何も出ない」という二次的な混乱を招きます。道具そのものより、負荷を上げずに仮説を1つずつ潰す順序が診断の質を決めます。
| 道具 | 確定できること | 機器への負荷/リスク | 使いどころ |
|---|---|---|---|
| `show` 各種 / `show logging` | 現在の状態と過去の事象（隣接・IF・エラー） | ほぼゼロ | 最初の一手。仮説を絞る |
| `ping`（拡張） | L3到達性・戻り経路・経路MTU（`size`+`df-bit`） | 小さい | 送信元依存の症状やMTU疑いの確認 |
| `traceroute` | どのホップ以降で挙動が変わるか | 小さい | 経路上の位置を絞る（`* * *`は断とは限らない） |
| SNMP（ポーリング/trap/inform） | 継続的な状態値と異常通知 | 小さい（ポーリング間隔次第） | 常時監視。欠落不可なら inform |
| `debug`（条件付き） | プロセス内部の詳細な処理過程 | 高い（無条件は本番で危険） | 他で確定できない最後の手段・必ず条件で絞る |
ひっかけ： 「logging trap 4にしておけばdebug出力もsyslogサーバへ届く」は誤りです——debugは重大度7（debugging）で、レベル4より軽いため送信対象外です。届かせたいならlogging trap debugging（7）が必要です。また「tracerouteの途中が* * *＝経路断」も誤りで、ICMPのレート制限や抑止にすぎず最終ホップが応答していれば転送は成立しています。さらに「調査後はundebug allだけで元通り」も誤り＝条件はno debug condition allで明示的に消さないと残り、次回のdebugが無言になります。
4.1.4この節のまとめ
- 診断は負荷の低い順に進める：
show/show logging→ping/traceroute→条件で絞ったdebug。本番機の無条件debugはCPU飽和で障害を増やす - 条件付きdebugは
debug condition interface ...で先に条件設定、解除はno debug condition all。拡張pingはsourceで実通信を再現し、size＋df-bitで経路MTUを特定できる - syslog重大度は0（emergencies）が最重・7（debugging）が最軽で、
logging trap NはN以下（より重大）のみ送出。SNMPはtrap＝確認なし／inform＝確認あり、v2cは平文なのでv3（authPriv）を選ぶ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番のディストリビューションスイッチ（CPU使用率が平常時でも約60%、OSPF隣接12本）で、特定の1本の隣接だけが1日数回フラップする。OSPFの詳細な処理を確認したいが、他の隣接への影響とCPU飽和は避けたい。取るべき手順として最も適切なものはどれか。
Q2. syslogサーバへ `logging host 10.50.0.9` と `logging trap 4` を設定した機器で、インターフェイスのUP/DOWN（`%LINK-3-UPDOWN`）はサーバに記録されるが、有効にしたdebugの出力だけがサーバに現れない。この事象の説明として最も適切なものはどれか。
Q3. 利用者から「本社から支店サーバへの大きなファイル転送だけが途中で止まる」と報告があった。ルータから `ping 10.20.0.10` は成功、`ping 10.20.0.10 source Vlan10 size 1500 df-bit` は失敗、`size 1476 df-bit` は成功する。また traceroute は中間2ホップが `* * *` だが最終ホップは応答している。この結果からの判断として最も適切なものはどれか。