少し前まで、私はIGP相互作用スキームを変更するプロジェクトの参加者でした。プロジェクトの一環として、ライブネットワークに移行する必要がありました。 プロジェクトの規模を考慮して、作業はいくつかの独立した段階に分割されました。ネットワーク設計の観点から、次の段階にシームレスに移行し、テストが予想と異なる動作を示した場合にルーター構成を前の段階にロールバックするための移行計画を作成しました。 構成を計画する際に、複雑で単純な一連の変更を含むグループにステージを分割し、複雑なグループに割り当てたステージの構成を準備するために、ステージと正常な完了後に更新される関連初期データのジェネレーターと環境を作成し、次の構成の準備の開始点として機能します。
古い構成の一部のみをクリーンアップする必要がある最後から2番目の段階で、この段階で手動で作成された実行可能コマンドのセットにいくつかの「子供の」構文エラーがあるため、サービスの計画外の中断に直面しました。 エラーをすばやく修正したため、作業に割り当てられたウィンドウ内に収まり、有益な結論を導き出しました： テンプレートを使用してさまざまな構成ブロックの入力を自動化できる場合は、できるだけ頻繁に実行してください 。 大規模なタスクではこれによりエラーが発生する可能性が低くなりますが、通常の操作では時間を節約できます。 出口では、最小限の時間で簡単に操作できる統合構成が得られます。
理想的な世界では、ネットワークエンジニアがプログラミングの経験から利益を得る理由を考えることはできませんでしたが、現実の世界とそれに関する私たちのアイデアはしばしば一致しません。 多くのネットワークエンジニアは、ネットワーク上の何かを特定の方法で構成する必要がある状況に慣れているように見えるかもしれませんが、何らかの理由で、または誤って異なって構成されています-ブロードキャストトラフィックのSTPフィルターまたは抑制がクライアントインターフェイスに登録されていませんCoPPフィルターの一部のセクション、コミュニティに割り当てられたプレフィックスのBGPタイプの不一致、バックボーンインターフェイスのMTUの欠落など。 苦痛のリストは非常に長い間続くことができるので、 ライブネットワークのサービスとコンポーネントの構成は、確立されたテンプレートと必要なパラメーターセットに準拠しているかどうかを定期的に検証する必要があります 。 検証の前に、構成要素を類型化する必要があります。これは、それ自体が大きく有用な作業です。 構成要素をセットに、セットをサブセットに展開し、それぞれに必要なテンプレートと必要なプロパティセットを割り当てます。 たとえば、スイッチポートは複数のクライアントポートに属している場合があります。また、ERPSの場合は、1つまたは複数のリング内で転送中です。 入力には、通常、説明フィールドを使用します。たとえば、ポートの場合、次のようになります。id / type / speed / phb / mon_s / mon_b / remote 、
- Id-たとえば、client1
- タイプは、次の値を受け入れることができます：CUST2-第2レベルサービスのクライアント、CUST3-第3レベルサービスのクライアント、BB-第3レベルのトランクMPLSポート、AG-集約デバイスへのMPLSポート、AC-デバイスにアクセスするMPLSポート、BR-トランクポート第2レベル、TR-第3レベルの中継ポートなど
- 速度-実際の帯域または契約帯域。
- php-分類のタイプ、QOS PHBの再描画および処理。
- mon_s-NOCまたは監視システムの変更のアラーム表示に対する反応のタイプ。
- mon_b-緊急事態に対するデバイスのローカル応答のタイプ。
- remote-応答機器とポートの識別子。
BGPグループを類型化する場合、良いスタートは、いずれかのセットのグループのメンバーシップを決定するコンテンツです。UP-上位レベルのオペレーターの場合、DN-顧客の場合、PR-交換ポイントまたはPPR-プライベートジョイントの場合、IAS-Inter-AS関節。 これらの各グループは、必要な送信または受信プレフィックスのセットによって順番に入力できます。
操作のために、次のように入力することも役立ちます。
- RSVPパス-冗長/なし、アラーム/データ、プライマリ/バックアップ、レーンありまたはなし、地域内または地域間。
- 擬似配線-イーサネット/ TDM、SLAの有無にかかわらず、広いまたは狭いキャビティ、冗長性の有無にかかわらず。
- VPLSまたはVPNインスタンス-サービスまたはクライアント、SLAの有無、ワイドまたはナローキャビティ。
既に書いたように、タイピングは検証の必要条件としてだけでなく、ネットワーク内のオブジェクトの正式な説明を取得するための別のプロセスとしても考慮されるべきであり、作業の計画、リスクの評価、イベントの重要度の決定に役立ちます。 NOCの変更が、午前3時半に冗長性のあるRSVPパスで緊急表示を検出した後、サポートの第2レベルのネットワークエンジニアを起こす代わりに、このインシデントに対応する反応レベルを割り当てると便利です。
タスクに応じて、リストと入力規則は広範囲に変化する可能性があり、このプロセスを非常に真剣に受け止めて、構成の検証の段階で検証規則を単純にし、テンプレートに冗長性と交差点がないようにします。 入力規則に空白のスポットや例外を残さないことをお勧めします。この場合、「すべてまたは無」規則に従って作業することをお勧めします。 例外がある場合は、それらからルールを作成して、個々の特性を持つ多くのオブジェクトを、統一された特性を持つ複数の要素セットに分解できるようにします。 たとえば、ネットワーク上のCEとのジョイントがアクティブ-アクティブまたはアクティブ-バックアップのいずれかである場合、これを個別のタイプとして反映します。
検証手順の記述は、操作機器のメーカーの構成ブロックを表す構文に非常に密接に関連しています。 機器のオペレーティングシステムでXMLまたはJSONの形式で構成を表示できる場合、これらの形式のフィールドを確認するのは楽しいため、これ以上話す必要はありません。 ただし、製造元の構成ブロックの外観が少しフォーマルでない場合でも、急いでこのベンチャーを放棄しないでください。 この作業の良いヘルプは、構成ブロックの必須またはオプションのパラメーターだけでなく、使用されるトークンの正確なシーケンスと関係を示すCLIリファレンスとコマンドガイドです。 たとえば、Huaweiルーターの次のコマンド
mpls rsvp-teタイマーの再送信{増分値の増分| 再送信値間隔} *
パターン{x |に一致 y | ...} *、これは1つ以上のオプションの引数を意味します。 バリデータコードを記述する際にメモリに依存しないことをお勧めします。機器の現在のソフトウェアバージョンに必要なコマンドの説明が記載されたページを開いたままにしてください。
私にとっては、構成ファイルを解析する2つのアプローチを特定しました。単純な場合、メーカーのトークンの辞書と組み合わせて正規表現を使用するのが論理的です。 これは、移植性がほとんどない非常に柔軟なアプローチではありませんが、これらのタイプのチェックは非常に簡単に実装されます。 より詳細な分析のため、または構成を別のメーカーの機器に転送するタスクのために、構成ファイルをツリーとして検討し、その要素は親子関係によって接続されていることを提案します。このようなデータ構造では、さまざまな条件に従って検索と選択を整理するのが非常に簡単です。
入力手順がエラー、欠落または不要なコマンドを報告するだけでなく、タイプを認識できなかった構成の場所を示す場合にも役立ちます。 これにより、いくつかの作業サイクルの後に白い斑点を取り除き、ネットワーク機器の構成を統一されたビューにすることができます。 構成検証システムの実装に関する私の経験が示すように、バリデーターから直接見つかったエラーを急いで排除しないでください。バリデーターの結果とネットワークオブジェクトの分類との間のフィードバックを維持するための時間が必要です。 そのため、特定の時点まで、作業の結果を注意深く監視し、適切な調整を行うことをお勧めします。 また、見つかったエラーの結果に基づいて構成を自動編集するシナリオに特に注意し、生成されたコマンドのシーケンスを注意深く監視して、このシーケンスが検証手順の順序に依存しないようにすることをお勧めします。これは、マルチスレッド環境で特に当てはまります。 この矛盾のささいな例は、グローバルテーブルで宣言される前に、欠落しているVLAN番号をポートに追加することです。 良い方法では、 各コマンドを実行した後、インタープリターの応答を確認する必要があります 。これにより、プレフィックスエクスポートポリシーが欠落しているネイバーのBGP宣言など、半分の構成の可能性を最小限に抑えます。
しかし、ネットワークエンジニアは単一の構成で忙しくはありません;時々、彼らが言うように、上からネットワークを見る必要があります。 この問題に役立つのは、グラフの理論とそれらのアルゴリズムです。 この分野の初期知識により、ネットワーク内の閉じたリングと開いたリングを見つけ、クラスターまたはデバイスのグループの接続の程度を評価し、部分的な障害シナリオを予測し、障害とリスク領域の境界を決定し、他の分析および創造的なタスクを解決できます。