こんにちは、ネットワーク ワーカーの友人です
スイッチはローカル エリア ネットワークにおいて非常に重要なネットワーク デバイスであり、その動作ステータスはクライアント システムのオンライン ステータスと密接に関係していることはわかっています。
しかし、実際の業務プロセスでは、スイッチの状態が外部から影響を受けやすく、LAN内にさまざまなネットワーク障害が発生します。
ネットワークを安定して運用するためには、スイッチの故障を防ぐために、平常時からスイッチを適切に管理・保守する必要があります。
企業ネットワーク デバイスの接続にはさまざまな物理リンクが使用され、データ パケットの転送を正確に完了するために、さまざまなネットワーク プロトコルもデバイス間で実行されます。
ネットワーク機器、ケーブル、ネットワークプロトコルが原因でネットワーク障害が発生する場合があり、いかに迅速にトラブルシューティングを完了するかが上級ネットワークエンジニアの基本資質となります。
物理的な接続が適切でなく、ping が送信できない状況に遭遇したことはありますか? この状況に通常どのように対処しますか?
ネットワークのトラブルシューティングに関しては、今日の記事がすべてを理解するのに役立ちます。
本日の記事閲覧特典：「ネットワークのトラブルシューティングに役立つツール集」
必要な友人は、私にプライベート メッセージを送り、秘密のコード「トラブルシューティング」を送信してください。上位 20 名にはツール リソースのコレクションが無料で送信されます。
01 ネットワーク障害の程度はどの程度ですか?
ネットワーク障害とは、ネットワークが何らかの原因で所定の機能を失い、業務に影響を与える現象を指します。
ユーザーの観点から見ると、サービスに影響を与える現象はすべて障害として定義できます。
一般的な障害の症状と分類は次のとおりです。
02 ネットワークのトラブルシューティングのプロセス
非構造化ネットワークのトラブルシューティング プロセスを実行する場合、直感に基づいてこれらの手順を行ったり来たりするだけであり、最終的には問題の解決策が見つかる可能性がありますが、効率を保証する方法はありません。
複雑なネットワーク環境では、構造化されていないネットワークのトラブルシューティング プロセスが原因で新たな障害が発生する可能性があり、ネットワークのトラブルシューティングがより困難になります。
したがって、構造化されたネットワークのトラブルシューティング プロセスに従って、調整の失敗箇所を特定し、修正する必要があります。
企業内には、財務、人事、物流、マーケティング、研究開発などの複数の部門があります。これらの部門間のネットワークには、相互接続と相互訪問が必要です。ネットワークの正常な動作を保証するために、企業では次のような状況が発生する可能性があります。
1. 大企業と中堅企業はネットワーク保守部門を設置し、専門のネットワークチームを構築します。
2. コストを節約するために、小規模企業は通常、独立したネットワーク保守部門を持たず、ネットワークを専門のネットワーク保守会社に委託します。
3. 機器メーカーにサポートを求め、メーカーのアフターサービス番号に電話してください。
一般に、ネットワーク障害を最初に認識するのはネットワーク保守担当者ではなく、他の業務関連部門の担当者です。
ネットワークエンジニアのもとには、「パソコンが突然インターネットに接続できなくなった」「Webページが正常に表示されなくなった」「ゲームがプレイできなくなった」など、さまざまな相談が寄せられることがあります。
電話で上記についてユーザーに質問し、トラブルシューティング レポートに文書化します。
なぜユーザーの役職レベルや仕事内容などを知る必要があるのでしょうか？エンタープライズ環境では、異なるレベルのユーザーが異なるネットワーク アクセス権を持っている可能性があるためです。
なぜ障害を確認する必要があるのですか?
ユーザーの説明があいまいで、報告された障害が実際の障害箇所ではない可能性があるため、障害の確認には経験豊富なエンジニアが必要です。
障害を確認するための 4 つの要素:
- 障害の件名: どのネットワーク サービスに障害があるか。
- 障害パフォーマンス: 障害の現象は何ですか。
- 障害時間: ユーザーが障害を発見した時間、および専門家が推測した障害が発生したリアルタイム時間。
- 障害の場所: どのネットワーク コンポーネントに障害が発生したか。故障現象を正確に説明してください。
最後に、障害が自分の責任に属するかどうか、つまり障害を処理するための対応する権限が与えられているかどうかを確認する必要があります。
収集する必要がある情報: 情報収集の段階では、主に文書やネットワーク変更などの障害関連情報を収集します。
この情報の収集方法:
- 機器独自の操作コマンドを使用するか、パケットキャプチャツールやネットワーク管理ソフトウェアなどの情報収集ツールを使用します。認可を取得します:
- 情報セキュリティに対する高度な要件が求められるネットワーク環境では、情報の収集には承認が必要であり、場合によっては書面による承認文書への署名が必要になります。情報収集段階でのリスク評価:
- ルーターやスイッチ上で「デバッグ」コマンドを実行するなど、一部の情報収集操作によりデバイスの CPU 使用率が高くなりすぎ、ひどい場合にはデバイスがユーザーの操作指示に応答しなくなり、追加の障害が発生することがあります。 。
- したがって、情報を収集する際には、これらのリスクを評価し、新たな障害が発生するリスクと既存の障害を解決する緊急性との関係のバランスを取る必要があり、これらのリスクをユーザーに明確に通知し、ユーザーが携帯するかどうかを決定できるようにする必要があります。リスクの高い情報収集を行う作業。
障害の根本原因が行ごとに特定され、障害が解消されれば、ネットワークのトラブルシューティングのプロセスは終了します。
複雑なネットワーク環境では、ユーザーから報告された障害が解消されたことを確認できる一方で、障害現象が解消された後も一定期間監視する必要があります。トラブルシューティング プロセス中に新たな障害が発生していないことを確認します。
仕上げ作業には、関連書類の照合、情報の発表などが含まれます。前回のネットワークトラブルシューティングで変更した設定やソフトウェアをすべてバックアップし、トラブルシューティング資料を整理して引き渡す必要があります。
同じ失敗が二度と起こらないように、この段階でユーザーに改善提案を行う必要があります。
03 ネットワーカーの古典的なネットワーク トラブルシューティング プロセス、収集する価値があります。
当時私が担当していたオフィスビルには複数の企業が入居していましたが、各社が独立してインターネットにアクセスできるように、オンライン状態が他社の影響を受けないようにするため、コアスイッチとしてルーティングスイッチを採用しました。建物のネットワーク。
同時に、スイッチ上のユニットごとに異なる仮想作業サブネットが設定されます。
各ユニットが異なるフロアに分散しているため、各フロアに分散している企業の数は完全に同じではなく、2～3ユニットのフロアもあれば、5～6ユニットのフロアもある。
異なるフロアにあるユニットワークサブネットはすべて、対応するフロアのスイッチを介してビル内LANに接続され、ビル内ネットワークのハードウェアファイアウォールを介してインターネットにアクセスします。
ネットワーク管理効率を向上させるために、ネットワーク管理者は通常、リモート接続を通じてスイッチを管理および保守します。
しかし、その日の朝出勤し、LANコアスイッチの各スイッチポートの動作状況をスキャンして診断していたところ、スイッチポートの1つがダウンしていることが判明しました。
そこで、ネットワーク管理ファイルを確認したところ、そのポートが 5 階の 2 階のスイッチに接続されていることがわかりました。
このフロアのスイッチにリモートでログインしたところ、長時間ログインに失敗し、ping コマンドでスイッチの IP アドレスをテストしたところ、「リクエストタイムアウト」という結果が返されました。
なぜ誰も障害を報告しないのかと思っていたところ、案の定電話が鳴り、案の定、5階の利用者から次々とネットワーク障害の報告が始まりました。
上記の故障症状から、フロアスイッチの動作状態が予期せぬものである可能性が考えられます。
そこで故障したスイッチの現場まで走って機器の電源を切り、しばらくしてから再度電源を入れて再起動しました。
ブート操作が完了した後、ping コマンドを使用してスイッチの IP アドレスをテストしました。
このとき返される結果は正常であり、リモートログイン操作はスムーズに行えます。
しかし、30 分後、障害のあるスイッチで再び同じ障害現象が発生し、ping コマンドをテストしたところ、異常なテスト結果が返されました。
その後、心配になって起動テストを繰り返したところ、故障したスイッチは正常にpingが通らないことが分かりました。
01 徹底した調査
先ほども言いましたが、DNS は電話帳に相当します。
再起動を繰り返しても問題が解決しないことから、この種の障害現象はネットワーク管理の過程で頻繁に発生することを考えると、障害の原因はさらに複雑であると推測されます。
そこで、次のような考えに基づいて徹底的な調査を実施しました。
ビル全体のネットワークで考えると、この現象は5階のとあるフロアのスイッチでのみ発生するので、このフロアのスイッチ自体の不具合が原因ではないかと暫定的に判断します。
障害の原因を正確に特定できるようにするために、障害のあるスイッチを正常に動作しているスイッチと交換して、障害がまだ存在するかどうかを確認します。
同時に、問題が疑われるスイッチを独立したネットワーク作業環境に接続します。
30 分間のテストと観察の後、独立したネットワーク環境に接続されている障害のあるスイッチが正常に動作しており、その IP アドレスをこのネットワーク環境で ping スルーできることがわかりました。
新しく交換したスイッチを建物のネットワークに接続した後、正常に ping できなくなりました。
これらの現象から、5階のスイッチに不具合が発生する可能性はほぼないと考えます。障害のあるスイッチ自体の状態要因を排除した後、建物ネットワーク全体のネットワーク構成とネットワーク状態を再検討しました。
ビル内の他のフロアの利用者は通常通りインターネットにアクセスできるため、5階の一部の利用者だけがインターネットにアクセスできなくなります。
5 階のネットワーク情報を確認すると、5 階に 5 台のユニットが分散配置されていることがわかりましたが、当時、ネットワーク管理者は 5 階に 2 台のフロア スイッチを配置し、それらをカスケード接続していました。
同時に、5 つの仮想作業サブネットがこれら 2 つのスイッチに分割され、各ユニットが独自の仮想作業サブネット内で独立して動作できるようになります。
コアスイッチの該当ポートがダウンしているため、5階の全ユニットがインターネットにアクセスできなくなっているのに、なぜ今一部のユーザーだけが障害を報告しているのでしょうか?
勤務時間になるとすぐに、ネットワーク障害を報告しなかった他の数社にすぐに電話しました。彼らが受け取った答えは、ネットワーク アクセスが異常であることに気づき、建物のネットワーク管理者に助けを求めるところだったというものでした。
このように、5 階のすべてのユニットがインターネットに正常にアクセスできないため、障害の原因はこれらのユニットの仮想稼働サブネットにあると考えられます。
5階の5台のトラブル対応範囲をロックした上で、5階のスイッチの機器を再起動することでネットワーク障害を一時的に復旧できると思います。
わずか 30 分後には、同じネットワーク障害現象が再び発生します。
この特殊な現象と比較すると、ネットワーク ブロードキャスト ストームにより、一定時間内にスイッチがブロックされ、最終的にコア スイッチの対応するスイッチング ポートがブロックされたのではないかと考えられます。
障害の分析を容易にするために、ネットワーク監視ツールを使用して、5 階のスイッチのカスケード ポートのネットワーク送信データ パケットを分析しました。
入力パケット流量、出力パケット流量ともに通常値の100倍近くと非常に多く、4階のネットワークでネットワーク輻輳が発生していることが分かりました。
では、ネットワークウイルスによって引き起こされるネットワークの混雑とは何でしょうか?
それともネットワークループによるネットワーク輻輳でしょうか?
障害が発生したスイッチのカスケードポートのステータス情報の変化、特に出力ブロードキャストパケットの変化を観察する予定です。出力ブロードキャスト パケットが毎秒増加し続ける場合、10 回中 9 回、5 階のネットワークにネットワーク ループがあることが証明されます。
この分析のアイデアに基づいて、コンソール制御ケーブルを使用して障害のあるスイッチに直接接続し、システム管理者としてシステムのバックグラウンドにログインします。
同時にdisplayコマンドでスイッチのカスケードポートの出力ブロードキャストパケットの変化を1秒ごとに確認し、それぞれの結果を比較します。
テストを繰り返した結果、障害のあるスイッチの出力ブロードキャスト パケットのサイズが実際に増加し続けていることがわかりました。
これは、5 階の 5 つのユニットにネットワーク ループが存在する必要があることを示しています。
5 階にある 2 つのスイッチを注意深く確認したところ、それらの間の物理的な接続は正常であることがわかりました。
さらに、2 つのスイッチの各スイッチ ポートは、5 階の各部屋の壁のインターネット ソケットに直接接続されています。
論理的に言えば、各部屋がカスケード接続にスイッチを使用しない限り、ネットワーク ループは発生しないはずです。
さて、5階のネットワークにネットワークループ現象が発生していることが判明したので、誰かがスイッチを勝手に使ってインターネットを拡張しているはずで、後は拡張スイッチを見つけて物理的な接続を確認するだけです。特定の障害のあるノードを素早く見つけることができます。
そこで、5 階の各ユニットのネットワーク管理者に電話して、各事務室を確認し、下位スイッチを使用している部屋を報告するよう依頼しました。
検査結果がフィードバックされるまでにそれほど時間はかかりませんでしたが、下位スイッチを使ってインターネットを拡張している部屋が10部屋ほどありました。
現時点で、この 10 部屋のネットワーク接続がネットワーク ループ現象の可能性が最も高いことがわかっていますが、どの部屋ですか?
ネットワーク接続を確認するには、各部屋のサイトに順番に行く必要がありますか?
真剣に考えた結果、ネットワーク情報を見つけて、これら 10 部屋で使用されているスイッチング ポート番号を 1 つずつ調べました。
次に、ネットワーク ケーブルを使用してこれらのスイッチ ポートに直接接続し、これらのポートの表示モード状態で、障害のあるスイッチの IP アドレスに順番に ping を送信します。
その結果、6 番目のスイッチ ポートに ping を実行したところ、このポートからは正常に ping できないことがわかりました。
スイッチポートに問題があるかどうかを判断するために、displayコマンドを使用してスイッチポートのビューモードでスイッチポートのステータス情報を表示しました。
確認および分析した結果、スイッチ ポートの入出力パケットのサイズが明らかに異常であることがわかりました。したがって、障害が発生したスイッチの異常な動作状態の原因はスイッチ ポートにあると推測します。
アーカイブを調べたところ、スイッチング ポート番号に基づいて、対応するインターネット アクセス ルームがすぐに見つかりました。
現場に到着すると、部屋のインターネットポートは2つだけで小さなハブに接続されており、その2つのハブに数台のパソコンが接続されていました。
さらに恐ろしいのは、ネットワーク ケーブルがこれらを直接接続しているため、2 つのハブ間にネットワーク ループが形成されていることです。
ループによって引き起こされたブロードキャスト ストームにより、障害のあるスイッチのカスケード ポートが最終的にブロックされ、その結果、建物のネットワーク全体がインターネットに正常にアクセスできなくなりました。
02 トラブルシューティング
余分なネットワークケーブルを取り外した後、スイッチポートのステータス情報を再度確認しました。入力および出力のパケット サイズが正常に戻っていることがわかりました。
再度、コアスイッチの該当スイッチポートの状態を確認したところ、原因の「down」状態が「up」状態に変化しており、この時点でコアスイッチ上の障害スイッチにpingを送信することができました。通常は4階。
これは、実際に 5 階の部屋のユーザーがスイッチまたはハブの使用を違法に延長したことによって問題が引き起こされたことを示しています。その後、インターネット ユーザーにさらに問い合わせを行ったところ、彼らの部屋は前夜に掃除され、そのときにネットワーク ケーブルもすべて抜かれていたことがわかりました。
清掃作業が終わると、インターネットユーザーは接続知識があまりないため、勝手に接続してしまい、最終的にはネットワークループ現象を引き起こします。
ほとんどの一般ユーザーにとって、スムーズなネットワーク エクスペリエンスは実感できますが、ネットワークの安定した運用は一夜にして実現できるものではなく、最前線で働くネットワーク ワーカーの継続的な努力と粘り強さが必要です。
彼らには脱帽です！
仕上げ: Lao Yang丨 10 年以上の上級ネットワーク エンジニア、乾物を改善するためにネットワーク ワーカーを増やす、公式アカウントに注目してください: ネットワーク エンジニア クラブ