4.1障害診断の道具（debug・ping・traceroute・SNMP・syslog）

ネットワークアシュアランスは「壊れてから調べる」技術ではなく、平常時の状態を測り続け、異常時に最短で原因の層と箇所を確定させる技術です。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同期を先に整えておく。