「PCからサーバーに通信できません」と言われたとき、あなたなら最初に何を確認しますか？
原因はケーブル、設定ミス、経路の誤り、遠く離れた機器の障害まで、無数に考えられます。闇雲に調べ始めると時間だけが過ぎてしまいます。効率よく原因を絞り込むには、決まった「型」が必要です。
Stage04のゴール：知識を「切り分け」に変換する
ここまでのレッスンで、スタティックルート、OSPF、HSRP、NAT、DHCPと、ルーティングに関わる要素を一通り学んできました。最後のレッスンでは、これらの知識を実際の障害対応でどう使うか、トラブルシューティングの手順として整理します。
基本方針：レイヤーを1つずつ確認する
ネットワークの障害対応で大切なのは、「なんとなく怪しいところ」を勘で調べるのではなく、下位レイヤーから順番に切り分けていくことです。物理層（ケーブル・リンクランプ）が生きているか確認せずに、いきなりルーティングプロトコルの設定を疑っても、時間の無駄になりがちです。
代表的な確認の流れは次の通りです。
- 物理層の確認：インターフェースが
up/upか（show ip interface brief） - IP設定の確認：IPアドレス・サブネットマスクが正しいか
- 直接到達性の確認：同一セグメント内の相手に
pingが通るか - 経路の確認：
show ip routeに必要な経路があるか - リモート到達性の確認：
tracerouteでどこまで到達し、どこで止まっているか
ping と traceroute の使い分け
pingは「そこまで届くか届かないか」という到達性そのものを確認するコマンドです。
Router# ping 192.168.20.1tracerouteは、宛先までの経路上のどのホップまで届いているかを1台ずつ表示してくれます。
Router# traceroute 192.168.20.1pingが失敗した場合、tracerouteを使うことで「どのルーターまでは応答があり、どこから先で止まっているか」が分かります。目的地に着けない荷物を、どの中継地点まで配送記録が残っているかで追跡するようなものです。これにより、障害箇所をピンポイントで絞り込めます。
「宛先に届くか届かないか」ではなく、「どのホップまで届いているか」を1台ずつ確認したいときに使うコマンドはどれでしょう？
答えを見る
tracerouteです。宛先までの経路上の各ルーター(ホップ)からの応答を順番に表示してくれるため、どこまでは正常でどこから障害が起きているのかを切り分けられます。pingは到達性の有無だけを確認するコマンドです。
ありがちな原因のパターン集
現場で頻出する原因を、Stage04の学習内容と結びつけて整理します。
no shutdown忘れ：インターフェースの設定をすべて終えたのに、shutdown状態のままでup/upにならない- サブネットマスクの不一致：両端のルーターで同じセグメントのつもりでも、マスクの桁数がずれていて別ネットワーク扱いになっている
- ネクストホップの指定ミス：
ip routeのネクストホップに、存在しないアドレスや別セグメントのアドレスを書いてしまっている - OSPFのエリア不一致：
networkコマンドで指定したエリア番号が両端で食い違っている - ACLによる暗黙の遮断（Stage05で詳しく学びますが、通信断の原因として非常に多いです）
これらはすべてshow running-config、show ip interface brief、show ip route、show ip ospf neighborを組み合わせれば発見できます。
インターフェースにIPアドレスを設定したのにshow ip interface briefでadministratively downと表示される場合、まず疑うべき原因は何でしょう？
答えを見る
no shutdownのし忘れです。IOSのインターフェースはデフォルトで無効化(shutdown)されているため、設定後に必ずno shutdownを実行する必要があります。administratively downは「人為的に無効化されている」ことを示す明確なサインです。
私の失敗談：直したはずなのに直っていなかった夜
正直に打ち明けると、私にも苦い経験があります。まだ経験が浅かった頃、深夜の切り分け作業で「支社のPCから本社サーバーにpingが通らない」という障害対応をしていました。ルーティングテーブルを何度見直しても経路はある。OSPFのネイバーもFULL。おかしいと思いながら1時間ほど設定を眺め続けていました。
原因は、拠点間リンクのサブネットマスクの不一致でした。片方のルーターは/30、もう片方はコピー&ペーストのミスで/24のままになっていて、OSPFのネイバー自体は別の経路から成立していたため、一見「経路はある、ネイバーも生きている」ように見えていたのです。しかし肝心のリンクのIP設定がずれていたせいで、そのセグメント経由のパケットだけが正しく転送されていませんでした。
このとき学んだのは、「ネイバーが生きているから、そのリンクの設定は正しいはずだ」という思い込みが一番危険だということです。ネイバー関係の成立と、実際のインターフェース設定の正しさは、別々に確認しなければならないのです。それ以来、私は障害対応のときに必ずshow ip interface briefとshow running-configのインターフェース部分を、思い込みを捨てて最初から読み直すようにしています。
試験でのポイント
CCNA試験のトラブルシューティング問題では、複数の設定ミスが組み合わさったシナリオが出題されることがあります。大切なのは「下位レイヤーから順番に確認する」という型を崩さないことです。特に、no shutdown忘れ、マスク不一致、ネクストホップ誤り、OSPFエリア不一致は、いずれも一見つながっているように見えて実は繋がっていない、という状況を生み出す定番の原因です。「一部は正常に見えるからといって、全体が正常とは限らない」という視点を持って、showコマンドの出力を1つずつ根拠にしながら切り分けていきましょう。
下位レイヤーから順番に、思い込みを捨てて1つずつ確認する。これがトラブルシューティングの基本だよ。私の失敗談みたいに、一見正常に見える部分にこそ落とし穴が隠れていることもあるから気をつけてね。Stage04はこれで完了、お疲れさま。次のStage05では、セキュリティの基本概念と脅威について見ていくよ。