ハイブリッドクラウドシナリオにおける BGP 冗長パス障害 - イベントレビュー

1 問題の背景

これは、基本的なネットワーク運用と保守に関する事故レビューレポートです。

歴史的な理由により、当社のさまざまな環境間の相互接続はシリアル接続を採用しており、コアリンクと転送ノードは共有リソースを使用します。これは、下の図の赤い部分です。共有リソースの信頼性と安定性が低く、障害シナリオでの権限が不十分であったため、私は困惑し、この状況を変えようと決意しました。既存のリソースを整理した後、基本的なネットワークアーキテクチャの移行プロセスは次のようになります。

写真

相互接続モードが純粋な静的ルーティングから完全な BGP 環境に変更されました。ハイブリッドクラウドアーキテクチャであるため、すべてのネイバーは EBGP に基づいて接続され、サブインターフェイスが展開されます。ルーティング構造を次の図に示します。

写真

AS の分布は図に示されており、クローズド接続/デュアルアップリンク/EBGP と非常によく似ています。これらの機能は、BFD およびトリガーされた更新と組み合わせることで、異常な状況下でミリ秒レベルのルーティング収束を完全に実現し、障害のあるリンクを排除した後、トラフィックをバックアップパスにすばやく切り替えることができます。
しかし、予想通り、予期せぬ事態に遭遇しました。カットオーバーはスムーズに進み、アーキテクチャの変更は計画どおりに完了しました。しかし、高可用性機能を検証する過程で光パスの中断が発生し、EBGP-5 ネイバーのステータスがアイドル状態になり、オフィス環境とホストされた IDC 間の接続が失われました。

写真

問題のあるリンクの両端のモジュールの光パワーが適切な範囲内であることを確認します。これにより、基本的にモジュール障害の可能性が排除されます。マネージド IDC サイドマウントメーターテストでは、OTDR が近端減衰を示し、リンクステータスが利用できないことが確認されました。位置を固定した後、パイプ井戸の仮設工事によりリンクが中断されたと報告されました。しかし、EBGP ネイバーはダウンしています。理論的には、ルートは冗長パスを通じて学習されるはずです。接続が失われるのはなぜですか?

2. 探索する

そのため、トラブルシューティングの焦点は高可用性に移りました。

2.1 近隣ステータスの確認

まず、すべての EBGP ネイバーの関係ステータスを確認し、それらがすべて確立されていることを確認します。

写真

2.2 ルートの有効性チェック

次に、オフィス環境のルートアナウンスの詳細と管理対象 IDC イントラネットの出口方向を確認し、両側の BGP プロセスルートアナウンスが成功していることを確認します。

写真

2.3 ルートフィルタリング

次に、イントラネット出力方向のプレフィックスリストをチェックして、有効なフィルタリングロジックに誤検知がないことを確認します。

2.4 ルーティング更新をトリガーするために手動で新しいネットワークセグメントを作成する

最後に、オフィス環境のイントラネット出力デバイスにループバックを追加し、新しいサブネットと対応するルートを設定して公開し、EBGP ネイバーのルート送受信ステータスを確認してみましたが、状況は同じままでした。

3. 原因を分析する

上記のテスト調査の結果、以下の特徴が判明しました————

両端のデバイスは正しく構成されており、ルーティング通知は正常です。
クラウドネットワークコンポーネントの L3 ノードのローカルルーティングテーブルには、直接接続されたネイバーによって通知されたルートが含まれており、正確で完全なルーティング更新を受信できることを示しています。
クラウドネットワークコンポーネントを通過した後、対応するルーティング情報がネクストホップデバイス (つまり、この記事の問題のあるリンクのリモートデバイス) のルーティングテーブルに見つかりません。
さらに、マネージド IDC でデバッグを有効にしてルーティング更新をリアルタイムで印刷するテストを実行し、クラウド上の EBGP ネイバーから受信したルーティング更新に、オフィス環境が属するネットワークセグメントのルーティング情報が含まれていないことを確認しました。

まとめると、オフィス環境とマネージド IDC イントラネットの出力方向では、両端のデバイスがクラウド上の L3 ノードへのローカルルートを宣言し、クラウド上の L3 ノードもルーティング情報を正常に受信して独自のルーティングテーブルに追加できます。ただし、クラウド上の L3 ノードは、このルーティング情報をリモートのオフクラウドデバイスに転送しません。約 2 時間苦戦した後、私は古い概念である水平セグメンテーションについても考えました。しかし、私はプロダクトマネージャーが「専用回線アクセスポイントは単なるチャネルなので、リンクとして扱ってください」と明確に強調していたことを思い出しました。さらに、ソリューション設計中にサブインターフェースの構成が追加されました。結局、私はループ防止の落とし穴に陥ってしまいました。最終的に、クラウドサービスプロバイダーからのアフターアップグレードの確認により、問題は解決しました。わんわんめいはわおと思った、555555

4つの解決策

この問題に対して、アフターサービスとさまざまな詳細を確認し、解決策を確定しました————

クラウド上に別の L3 ノードを作成します。
この新しく作成された L3 ノードは、それぞれオフィス環境とホストされた IDC の専用アクセスポイントを接続します。
管理対象 IDC およびオフィス環境のイントラネット出力ノードはそれぞれサブインターフェイスを作成し、新しく追加された専用回線アクセスポイントに接続し、クラウド上に新しく作成された L3 ノードと EBGP ネイバー EBGP-6 および EBGP-7 を確立します。
管理対象 IDC およびオフィス環境のイントラネット出力ノードは、新しく作成されたサブインターフェイスを通じて、クラウド上の新しい EBGP ネイバーにローカルルーティング情報を公開します。
新しく追加された 2 セットのネイバー関係 (EBGP-6 と EBGP-7) は、EBGP-5 に冗長パスとルーティング更新チャネルを提供できます。調整されたソリューションは次の図に示されています。

写真

5 結論

全体的に見ると、問題は実は非常に単純です。異なる AS 間のサブインターフェイスと EBGP ネイバーを使用すれば、AS パスや水平分割などのループ防止ロジックによって制限されることはないと考えられていました。しかし、これは実際には考え方の誤解であり、その後の複雑さと時間の損失を引き起こしました。

BGPv4 が今でも現代のインターネットの基盤となっているのは事実ですが、クラウドサービスは新しいコンテンツをもたらしました。さまざまなクラウドベースの機能と製品は、エンタープライズネットワークとデータ通信の従来の技術的概念と比較して、大きな変化を遂げてきました。基礎をマスターすることを前提として、新製品や新機能のアップデートと反復を理解し、これらの違いに関連するシナリオとターゲットとなる問題点を真に理解する必要があります。この方法によってのみ、利点を正しく発揮し、価値を反映し、上位レベルのサービスに対する安定的かつ永続的なサポートを提供することができます。