Edited at

ベンダ側NWエンジニアが送る、ネットワークのトラブルシューティング虎の巻(初心者向け)


前書き

クラウド上でできることが増えている昨今、ネットワークが繋がらないことによる業務インパクトも比例するように増えています。

Paas/Iaasなど管理に割く手間を減らせるサービスも一般化してきましたが、インターネットに繋ぐためのネットワークだけはどうしても自前で持つ必要があります。

そんな中で、一般的なネットワーク機器の保守契約では、一次切り分けは顧客の対応範囲となっています。

つまり、どの機器が悪そうかまでは特定して、保守ベンダに説明する必要があると言うことです。(=障害がおきたからすぐに来て直せは通用しない)

何かあったらすぐエンジニアが来てくれるようなサービスだと、当然それなりに値段が高いため、ほとんどの企業では実は一次切り分けを自身で行う必要がある場合が多いです。

ネットワーク機器ベンダーでネットワークエンジニアとしてトラブル対応に関わってきた中で、

障害解決までに時間が掛かった/復旧できない状態に陥った事例を数多く見てきました。

いいからすぐ来いとかのクソみたいな問い合わせが減ることを祈り

実践的なトラブルシューティングの手順を紹介します。


対象

・事業所などの小規模なネットワーク(所謂キャンパスネットワーク)のトラブルシューティングについて解説します。

・データセンターのような大規模/複雑なネットワークについては対象外です。

■対象読者

・ネットワークの勉強をしたことない方/そもそもITにあまり詳しくないよという方

・なのにシステム管理の業務をアサインされて、いざ何かあったらどうしようとお悩みの方


事前準備

トラブルが起きる前に、以下の資料/情報を用意しましょう。

・保守契約の情報

どういうサービス内容になっているのかや、問い合わせ先の電話番号/メールアドレスを把握しておきましょう。

また、障害発生時の問い合わせに必要となる情報は事前に確認しておくとベターです。(一般的には契約番号や、機器のシリアル番号などです。)

・構成図(特に物理構成図)

ルータ/スイッチなどの各ネットワーク機器がどのように接続されているかを一目で把握するために使います。

接続ポート番号/IPアドレス/ホスト名/機器型番などが載っていると望ましいです。

簡易ですが、例としては以下のようなものです。

良い例

good sample.png

悪い例

bad sample.png

※ちなみに、大規模ネットワークの構成図はこんな感じ(ページ下部:ShowNet トポロジー)

http://archive.interop.jp/2013/shownet/point.html

・機器のコンフィグ

機器がダウンしてからコンフィグを取ろうとしても、当たり前ですが遅いです。

機器交換に必要となるコンフィグ/ログ情報は何か事前に確認して保管しておきましょう。

コンフィグの保管は顧客の責任範疇である場合が多いです。

・機器の設置場所

保守ベンダは基本的に機器の場所を知らないので、機器の前まで案内してもらいます。

トラブル時に迷って時間を浪費しないようにしましょう。


障害がおきたらまず一次切り分け

まずは、影響範囲を確認します。ログを採取するのは二の次です。

たまにログさえ保守ベンダに送れば、何が起きているか説明しなくても、悪い箇所をたちどころに見つけ出せると勘違いしている方がいますが、そんなことは不可能です。1

準備した構成図を見ながら、どこなにいつからいつまで使えなくなったのかを確認しましょう。

■例として、先ほどの構成図を使ってみます。

good sample.png

影響範囲の聞き取りをしたところ、3階のフロア全体でネットワークに繋がらなくなったと申告がありました。

その他の1階、2階は使えているようです。

少なくともFLOORSW-1F,2F,CORE-MAIN経由の通信はできてそう=このスイッチ達は大丈夫そうです。

3階のフロアスイッチが怪しいことはすぐにわかります。

構成図を見るとすぐに気づけますが、3階のフロアスイッチだけCORE-BACKUPにしか繋がってないですね。

CORE-BACKUPも怪しそうですね。

この二つのスイッチを重点的に調べればよいことがわかります。

次に、1Fか2FからCORE-BACKUPとFLOORSW-3Fにpingを飛ばしてみましょう。

windowsならコマンドプロンプトから[ping IPアドレス]です。

CORE-BACKUPにpingを打つなら[ping 10.0.0.101]となります。

CORE-BACKUPの反応があればフロアスイッチ(かその間のケーブル、はたまたCORE-BACKUPのポート)が怪しいことがわかりますし、反応がなければCORE-BACKUPが怪しいでしょう。

1次切り分けとは、このようにして論理立てて被疑箇所を絞り込んでいく事です。

今回は簡易な構成なのでそうでもないですが、実際の環境で構成図なしで同じことをやる時の苦痛は想像に難くないと思います。


被疑箇所が絞り込めたら

ネットワークがダウンしてしまっていると、パソコン越しにできることは何もないので、現物を見てみるしかありません。

電源が入っているか/LEDの状態はどうか/コンソール接続できるならログでエラーがでてないか。。。などなど

LEDの状態が何を示すかはマニュアルを読まないとわかりませんし、ログについては解析するにも知識が必要です。

確認できた情報をまとめて保守ベンダーの担当者に投げましょう。

但し、保守ベンダは多数の顧客のサポートをしているので、あなたの会社の機器構成を把握していません。数が多すぎてできる訳ありません

問い合わせがあって、情報提供をうけてからはじめてどんな機器がどのように接続されているか、どういった設定になっているかを確認しはじめます。

この時に、構成図やコンフィグをぱっと出せれば、どの機器が怪しいか、(接続ポートが書いてあれば)どのポートが問題ありそうかが比較的短時間でわかります。(型番がわかれば)取って貰うべきログのコマンドは何かがすぐに言えます。2

怪しい機器が本当に壊れているのかを確認するのは、一般的には保守ベンダの仕事です。

お疲れ様でした。ここまでくれば単純な障害であればほとんど解決したようなものです。あとはベンダの指示に従いましょう。


最後に

最後のほうは飽きてきて雑になってますが、実践的なトラブルシューティングの手順をもとに、如何に事前の準備が重要か少しでも理解いただけたら幸いです。





  1. ネットワークは複数の機器が相互に接続してなりたっています。例えば、対向機器が故障しても、ケーブルが抜けても、あるいは自身のポートが壊れたときでも、「インターフェースがDOWNした」以上の情報はログからわからない場合がほとんどです。他の場合でも、何が起こっているかを踏まえて、ログの出方から、どんな事が起きたのだろうかとストーリー(仮説)を作ってみて、ログ出力から整合性を検証する、といった作業が必要になります。 



  2. 「構成図なくても、コンフィグ送ったんだから見ればどんな構成かわかるでしょ」という方がたまにいます。確かに頑張ればわからなくもない時もあります。但し時間が掛かります。掛かった時間の分、障害が継続します。それで怒られても知らんがな