ネットワークの謎を解く: リバースエンジニアリングの技術
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
休憩して、その日の残りのピザがあった会議室に向かうことにしたのは午前2時頃でした。 私はおいしいピザが大好きですが、ネットワークの更新がうまくいかない真夜中は、おいしいピザでさえあまり美味しくありません。
本社エリアのすべてのアクセス スイッチは前の週に交換され、このスイッチ更新プロジェクトのその部分は滞りなく進みました。 しかし、今夜、私たちは主要な製造施設でデバイスの交換に取り組んでいました。そこでは驚きの連続でした。 簡単なアクセススイッチの単純な交換であったはずのものが、心痛と英雄の夜に変わりました.
XNUMX 分間足を止めてピザのスライスをつかみ、ソーダを飲みながら、同僚や、最初にネットワークのドキュメントを提供してくれた顧客と話をする機会がありました。 私たちはお互いに完全に怒っているわけではありませんでしたが、微妙な非難ゲームの始まりを感じました.
- ドキュメントにこれほど多くのスイッチが記載されていないのはなぜでしょうか?
- VoIP over Wireless を使用していて、カスタム QoS が必要であるとお客様が言わなかったのはなぜですか?
- データセンターから制御室に向かう膨大な量のトラフィックを、なぜ誰もが見なかったのでしょうか?
このプロジェクトの範囲は、私が行った以前のネットワーク リフレッシュ プロジェクトとあまり変わらなかったので、実際のテクノロジはそれほど苛立たしいものではありませんでした。 真夜中の素晴らしいスナックであるはずだったものを食べるのがとても難しかったのは、品質の欠如のためにこのプロジェクトがいかに貧弱に計画されたかを認識したことでした ネットワークのドキュメント と ネットワーク検出.
多数のオーバーレイを構成する複雑さに悩まされることも、ソフトウェア バグの回避策を見つけることに苦労することもありませんでした。 代わりに、不十分な計画とプロセスに苦労していました。
XNUMX 番目のスライスをつかむために、私は顧客に、吊り天井や文書化されていない壁に取り付けられたラックに隠れている他のスイッチを考えられるかどうか尋ねました。 彼はそれができなかったので、確かめるために散歩に行こうと提案した。 何時だったかを考えると、それを聞くのは好きではありませんでしたが、製造施設で効果的に機能するためにカスタム QoS ポリシーを必要とする無線電話システムで VoIP を使用しているという話を初めて聞いたときも同様に嫌いでした。
数人のエンジニアを残してリラックスし、最後の生ぬるいペパロニパイを食べて、私たちは探求を始めました。 私の顧客と私はこれらの問題について心から話し合っており、それが彼の切迫感を構築するのに本当に役立ちました.
ご覧のとおり、コントロール センターは、データ センターに戻る 1 ギガのトランク リンクを飽和させるのに十分なトラフィックを生成していましたが、この設計では、ポート チャネルも、少なくとも 10 つの XNUMX ギガ トランク リンクも必要としませんでした。 これは、どのようなネットワーク リフレッシュ サイクルでも当然のことでした。しかし、顧客もプリセールス担当者も、ベースライン トラフィック分析を実行しませんでした。
また、今夜はその場でカスタムの QoS ポリシーを作成していたので、その有効性を真に検証する方法は、ネットワークに負荷がかかっている次の日になるまでないと説明しました。 私たちがすべきだったのは、可能な限りネットワークをシミュレートし、構成をプログラムでプッシュすることです。 残念ながら、関連する QoS 設定とサービス ポリシーをすべてのトランク ポートに追加するには、すべての新しいスイッチを XNUMX つずつ変更する必要がありました。
彼が同意してうなずき、今夜の変更をロールバックして、翌日再編成できるようにすると申し出たのを覚えています。 これに関する唯一の問題は、すでに午前 2 時を過ぎていて、ロールバックするために必要なすべての作業が完全に手動で行われることでした。 十分な時間があるかどうか確信が持てませんでした。
私たちは前進することを選択しましたが、夜中から深夜まで作業することに落ち着きました。 午前 4 時ごろ、プロジェクト マネージャーが大量のコーヒーを持って現場に到着しました。 その時までに私たち全員がまだ第二の風をつかんでいたわけではないので、私はそれを感謝しました.
私のチームは、顧客がそれらを交換するのに十分な数を購入していなかったため、新しい設計に統合したさらにいくつかの不正なスイッチを見つけました。 QoS ポリシーを理解するために、電話システムに関するドキュメントを探しましたが、当初の考えでは、通話がどのように行われるかをわざわざ調べようとは思いませんでした。 ただし、ネットワークに負荷がかかっていない深夜でも、テスト通話は非常に貧弱でした.
私たちは情報不足で働いていました。 適切なネットワーク検出が行われず、ネットワーク上でアプリケーションがどのように機能するかを理解していなかったため、ネットワーク デバイスを簡単に更新する必要がありましたが、実行できませんでした。 このプロジェクトに着手する前に、いくつかの重要な考慮事項を考慮に入れていませんでした。
私たちの最初のステップは、文書化とネットワーク検出を通じてネットワークに関する情報を収集することでした。 交換するスイッチの数を数えるだけでは十分ではありません。
NetBrain ダイナミックでこれに対処します ネットワーク マップ 正確なドキュメントを数分で作成します。 アセットとトポロジーの検出のためにネットワークを手動でクロールするエンジニアのチームは必要ありません。
これは、在庫スプレッドシートを作成するだけではありません。 ネットワーク デバイスの更新を成功させるには、プラットフォームとソフトウェアのバージョンを特定して、新しい設計で適切な機能を計画できるようにすることから始めます。 NetBrain は、このデータをプログラムによってオンデマンドでキャプチャします。これは、午前 2 時の私のような欲求不満のエンジニアにとって非常に便利だったでしょう。
次に、新しいギアの機能と構文を評価するメカニズムが必要でした。 たとえば、スイッチを 1 ギガ トランクから 10 ギガ トランクにアップグレードすると、スパニング ツリーまたはルーティングの決定に影響を及ぼす可能性があり、変更ウィンドウ タイマーが開始する前に、これをテストして評価する必要があります。
私の場合、オンザフライで迅速に QoS 構成を評価する機能が必要でした。 確かに、ネットワークに負荷がかかっていない状態で QoS 構成をテストすることは非常に困難ですが、構文の実際の実装をテストすることも同様に重要です。これは、プラットフォームによって構文が大きく異なる可能性があるためです。
そして XNUMX つ目は、多数のデバイスをプログラムで操作する方法がありませんでした。 構成の展開と構成のロールバックの両方でこれをプログラムで実行できると、ネットワークの更新を、全員が参加するシナリオから、XNUMX 人のエンジニアが処理できる管理可能なプロジェクトに変えることができます。
NetBrain すべてのスイッチをラックに収めることはできませんが、動的なネットワーク検出、オンデマンドのドキュメント、およびプログラミング性の向上の必要性に対処します。
その製造組織のネットワーク更新プロジェクトは成功に終わりましたが、それを実現するために 30 人のエンジニアのチームで XNUMX 時間ぶっ通しで働きました。 コーヒーもピザも役に立ちましたが、必要な情報を事前にオンデマンドで取得するための適切なツールがあれば、XNUMX 日を節約できたでしょう。