EthernetやTCP/IPが，一般的なコンピュータネットワークとして利用されはじめてから30年近く経ちました。近年，ネットワークトラブルといっても機器障害などのハードウェア的な故障か，外部からのDDoS攻撃，セキュリティホールクラックなどが多く，ネットワークトポロジーに関わるフラッディングやブロードキャスト，ブリッジループによるパケットストームが発生することは非常にまれになってきています。運用においても設定をデプロイするまえにグループ内で必ずクロスチェックやレビューを行っているでしょう。一般ユーザがネットワークに影響を及ぼすようなアプリケーションをインストールできないような処置を施したり，実験的なネットワークを隔離したり，設定ミスやプログラムのバグでネットワーク全体が落ちるというケースはほとんどありません。

それでもトラブルは発生していますが，最近耳にする障害の多くは設定ミスやプロトコル上のバグなどではなく，設計者，運用者による間違った認識や思い込みによる些細な原因で発生しています。

トラシュー事例（初級編）
「ある特定のファイルサーバに対する通信が不安定であり，アプリケーションからサーバ上のファイルをアクセスすると，時折そのレスポンスが非常に遅くなる」

障害報告を受けて，サーバ管理者はサーバ障害の可能性を考え，該当するファイルサーバにリモートログインしてサーバの状態を確認します。まず，topコマンドでプロセスの状態を見ますが，CPU使用量の高いプロセスもなく，大量にメモリを消費しているプロセスはありません。次に，sarやiostat，mpstat，vmstatなどのコマンドを実行してプロセスやメモリの状態をチェックしても，iowaitプロセスやwait run timeプロセスもそれほど多くなく通常の状態です。

サーバに異常なし

さてはDoS攻撃かと思ってnetstatを見ても，アタックされたときに多く発生するSYN_RECV，WAIT_FIN，LAST_ACK状態のセッションは見当たりません。またNagiosやZabbixなどの監視ツールを見ても，ポートのトラフィック量は正常です。NICの障害かと考えてシステムログを見ても，とくにエラーは見当たりません。念のため，同じスイッチに接続されているサーバ間でiperfを実行すると，GbEインターフェースで945 Mbpsの性能が出ています。ログからファイルシステムもしくはディスクに問題はないかどうか確認しても，とくにディスクI/Oエラーなどの障害は発生していません。どうみてもサーバの健康状態は正常に見えます。

ネットワーク経路のチェック

管理者はどうやら問題はサーバではなくネットワークにあると考えましたが，iperfによるパフォーマンスチェックに問題はなかったので，サーバのネットワークインターフェースではなさそうです。次に疑ったのはネットワークの経路です。まず各クライアントマシンからサーバへの到達性を確認するためpingを実行しました。これもすべてレスポンスがあり，疎通はできています。次にtracerouteによってIPネットワークの経路を確認しました。クライアントからサーバへのホップ数は設計どおりになっており，経路が迂回されていたり特定のリンクに経路が集中している様子もありません。

一通りのチェックを実行した結果，サーバにもネットワークにも問題は見受けられませんでした。しかしレスポンスが遅いという問題は解消していないので，どこかに原因があるはずです。もしかするとツールやコマンドでのヘルスチェックでは検出できない物理的現象の問題かもしれません。誰かがサーバをメンテナンスした際，ケーブルを折り曲げたり，ポートへの差し込みが甘かったりしている可能性があります。

サーバラック内部のチェック

管理者はマシンルームへと向かい，該当するサーバが格納されているラックを開け，RJ45コネクタの差し込み具合をチェックしたり，ケーブルを交換したり，接続ポートを変えたりしながらサーバを再起動して様子をみます。レスポンスが異常に遅いという障害がいったん解消されますが，数時間後，サーバの反応が不安定になり再び障害が露見しました。ケーブルやポートなどではなく，スイッチ本体に障害があるのではないかと考え，ネットワーク管理者に依頼してスイッチを交換してもらいました。しかし同じようにいったん障害が復旧しますが，しばらくするとまた同じ症状になってしまいます。

違和感の正体

管理者は原因がわからなくなってしまい，次に何をチェックするといいのかさえ思いつかず，ラックの前後を行ったり来たりしながら，スイッチやサーバを眺め回すしかありませんでした。ふと，ラック内に設置されているパッチパネルを眺めているときのことです。

• 「おや？」

管理者は何か違和感を感じました。それが何を意味するのかハッキリと考えがまとまりませんでしたが，ジロジロとラックの中を見回し，再びサーバとスイッチを凝視して思わず声をあげます。

• 「あっ！」

そのパッチパネルに，バックボーン側から接続されているファイバケーブルの色が黄色だったのです。今では橙，青，緑，ピンクなど各メーカーがさまざまな色のマルチモードケーブルを提供していますが（写真1）⁠，ケーブルの色が黄色であるということは，それが例外なくシングルモードケーブルであることを意味します。しかも，スイッチのアップリンクポートからパッチパネルへ接続されているケーブルの色はオレンジなのです。

スイッチ側の光ピックアップポートを確認すると，1000BASE-SXと刻印されており，本来ならばこのスイッチとバックボーンはマルチモードで接続されるべきでした。障害の原因はスイッチとバックボーンのファイバモードミスマッチだったのです。

おそらく機器調達者は，スイッチを設置するラックから集約スイッチまでの距離が1000BASESXの最大有効距離よりもかなり短かったので，マルチモードで十分だと判断したのでしょう。しかしファイバ工事担当者は，フロアにまたがる長距離配線や複数のパッチパネルを介する配線などを行っているため，とくに念を押されない限り，ファイバの敷設はシングルモードファイバを手配していたと思われます。つまり原因は，ネットワーク機器調達の担当者と配線工事の担当者との間で，情報が正確に伝達していなかったためだったのです。

思い込みは危険

このケースの厄介なところは，ファイバモードが異なっていてもある程度の通信は可能であり，パフォーマンスが劣化したり，エラーが頻発したりするのは，接続してから時間が経過し，かつ高トラフィック負荷が掛けられたときに初めて露見するということです。まったく通信できないわけではないので，通常のトラブルシューティング手法ではなかなか原因がつかめず，直接マシンルームまで足を運ばないと原因が特定できません。

初めて光インターフェースを導入したりファイバーを敷設したりするときでは，シングルモードかマルチモードか，マルチモードはSPかGIか，コネクタ形状はLCかSCかなどを注意深くチェックするものです。しかし，運用が長期に渡ると，しだいに繰り返し習慣化している調達や作業など，各人の思い込みのままに行ってしまいがちになり，このようなまったく初歩的なミスによる障害に多くの時間を取られることになってしまいます。そのため，各人の思い込みではなく，常に作業者間で正確な情報の確認を行うことが大切です。