ネットワークの謎を解く: リバースエンジニアリングの技術
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
断続的なネットワークの問題に関連して、トラブルシューティングを行ったり、サポート ケースに対処したり、顧客から電話を受けたりした人は何人いますか? 私はたくさん想像するでしょう。 何らかの形の IT 関連分野にいるほとんどの人は、より分析志向の傾向があります。 分析的な心で、私たちはしばしば、それが起こり続けるなら、それを繰り返すことができなければならないと考えます. ほとんどの場合、あなたは正しいです。 しかし、私は XNUMX 年近くさまざまな形態の IT 業務を行ってきたので、必ずしもそうであるとは限りません。
断続的なネットワークの問題は、簡単には再現できないイベントです。 また、同じ時刻に発生したり、常に同じユーザーに影響を与えたりすることもありません。 さまざまな立場でこの種の問題に取り組んできた者として、それらに出くわすのは恐ろしいことです。 あなたは無力感を感じ、時には自分の正気を疑います!
NetBrain 問題を特定し、どこかで開始することができました。 問題を解決するには、問題を理解する必要があります。 NetBrain、どこから始めればよいかをすぐに理解できたかどうかはわかりません。
実話: アップグレードから XNUMX 週間後の断続的な停止
以前、7K/5K/2K アーキテクチャが登場して市場を席巻していた頃に、レガシー Cisco 環境から新しい Cisco Nexus 環境にアップグレードしているクライアントがいました。 コンサルティング契約の一部には、開始前にネットワーク評価が含まれていました。 なんで？ 新しいアーキテクチャへのシームレスな移行を確実にし、すべてのベースがカバーされていることを確認したかったのです。 停止、ダウンタイム、またはいかなる種類の影響もないように努めています。 しかし、時には私たちの手に負えないことが起こります。 （もしかして、予感？）
カットオーバーが完了すると、すべてのテストに合格し、すべてのチームが満足しました。 コールバックを受け取ったのは、24 週間後、XNUMX 週間後、または XNUMX 週間後ではありませんでした。 クライアントが電話をかけたとき、標準的な運用を開始して約 XNUMX 週間が経過しました。断続的な停止があり、何が問題なのかを理解するために私たちの助けが必要でした。 これは、ランダムなアプリケーションとランダムなユーザーに影響を与えるように見える問題でした。 ほとんどの人と同じように、新しいデータ センター コアが彼らの問題だとすぐには思いませんでした。 なんで？ XNUMX週間でした！ 経験によると、ほとんどの問題は発生し、存在するとしても XNUMX 時間以内または最長で XNUMX 週間以内に通知されます。
NMS ソリューションが問題を解決しないのはなぜですか?
私たちが最初にしたことは何ですか？ 気合 NetBrain ネットワークの更新された検出を再実行し、インストール後のマップと比較しました。 XNUMX つのスキャン間で、CLI コマンドが XNUMX つも異なっていない、完全に重複していました。 私たちが去ってから何も変わっていないことについて話し合い始めたので、IT ディレクターと副社長は、チームが混乱していないことに安心しました。 (私たちも気分が良くなりました。) しかし、目前の問題を解決することに誰も満足していませんでした.断続的なグレムリンは、トラフィックの切断とブラックホールを引き起こすように見えました.
NetBrain ワンクリックで、ライブ状態と過去のスナップショットの間でほぼすべてのネットワーク データを比較できます。
私たちは、キャンパス、データ センター、およびいくつかのリモート サイトの大規模なマップを監視モードで一晩、合計で最大 16 時間放置することに同意しました。 翌日戻ってきたとき、7 台目の Nexus XNUMXK の継続的な平均値の一部が大きく変動していることに気付きました。 最後に、開始する場所がありました。 私たちは、Splunk、SolarWinds、およびその他のいくつかのツールを含むネットワーク管理ソリューションから始めました. 彼らは前夜に何の問題も見ませんでした。 彼らはそれらを見逃しましたか、それともしきい値が低すぎましたか?
戻って行く NetBrain、7 番目の Nexus 7K ではトラフィックが変動しているように見えました。これは、最初の Nexus XNUMXK で見られた通常の受信/送信トラフィック パターンとは一致しませんでした。 これまでと同じ数の vPC リンクを使用してペアで実行すると、これは奇妙でした。
見えないものは直せない
私たちは何を見つけましたか？ トラフィックをブラックホール化する断続的なバグを発見しました。 バグは避けられません。 それらは、あらゆる製品、ソフトウェア、またはソリューションで発生します。 この場合、スロット 3 からスロット 2 にデータを渡そうとしたときに、バックプレーン ファブリック モジュールがトラフィックをブラックホール化する原因となる特定のモジュールにたまたまヒットしました。バックプレーン モジュールは故障しなかったため、アラートは発生しませんでした。 トラフィックのブラックホール化は、他の要因によるバッファ オーバーフローで発生します。顧客は、データ処理の上限に近づくほど十分なデータをポンピングしていませんでした。 コードリリースで問題が解決しました。 幸せな顧客。
NetBrain 「正常であること」に関する他のすべての合理的な手段が失敗した状況について貴重な洞察を提供しました。 他のツールは、必要なものをキャッチするように調整できたかもしれませんが、あまりにも多くの重大ではない問題について警告することにもなりました. NetBrain 問題を特定し、どこかで開始することができました。 問題を解決するには、問題を理解する必要があります。 NetBrain、どこから始めればよいかをすぐに理解できたかどうかはわかりません。
ワンクリックの履歴比較分析は XNUMX つの方法にすぎません NetBrain イライラする断続的な問題に取り組むのに役立ちます。 また、問題が検出された瞬間に、24 時間年中無休の監視ソリューション、チケット システム、IDS/SIEM から自動分析をトリガーすることもできます。
私たちはこれを「ジャスト イン タイム」自動化と呼んでいます。ここでデモをスケジュールして、実際の動作を確認してください。 ジャストインタイムの自動化を見せて