パーフェクト・ストーム (なぜ失敗したのか)

by トッド・ブリストル 2017 年 6 月 2 日

ようこそ！ パーフェクトストーム!

このシリーズでは、 それほど明白ではない 「間違った」ことの「正しい」組み合わせが発生し、その結果、到達可能性や接続性などの損失が生じるシナリオ。失敗について話し合った後、戻って何が起こったのかを判断します (なぜ失敗したのか?)。 また、どのように障害が防止または最小化されたかについても見ていきます。 NetBrain.

始めましょう！！

ネットワークの概要: シナリオとは?

このシナリオでは、受け入れテスト中に、ネットワークのセクションがクラウド ベースのリソースと通信できないことがわかります。

作業中のネットワーク環境は次のとおりです。

図 1: AWS クラウドへのデータセンター接続

RT1 と RT2 はそれぞれ BGP を介して AWS 環境にピアリングし、それぞれ異なる 物理的な AWS へのパス。 これら 172.16.110.0 つのルーターは、1 ネットワーク全体で相互に iBGP 関係を持っています。 さらに、RT2 ​​と RT172.16.110.0 は、10.70.28.0 ネットワークと 10.70.28.0 ネットワークの 1 つの別個のネットワークで OSPF を実行します。 2 ネットワーク上のトラフィック (RT3 および RT3 から) は、ファイアウォールを通過して、データ センター サブネットのレイヤー XNUMX ルーティング/トラフィックを処理する XNUMX 番目の OSPF ネイバーである RTXNUMX に到達します。

失敗の概要: 間違ったものの正しい組み合わせ

過去 11 晩 (午後 10.17.1.0 時) に、10.192.16.0 ネットワーク上のネットワーク管理ステーションが、10 ネットワーク内の AWS ホストに対してパフォーマンス テストを実行しました。 テストは通常​​、完了するまでに 15 ～ 2 分かかります。 テストの最終夜である XNUMX 日目の夜、テストは、AWS Circuit プロバイダーのメンテナンスウィンドウ (メンテナンスが実行されている場所) の真ん中である午前 XNUMX 時まで延期されます。 物理パス A）。 データ センター内のどのホストからも接続関連の問題は報告されていませんが、ネットワーク管理ステーションから実行されたパフォーマンス テストは失敗しました。 なぜ失敗したのか?

トラブルシューティングの方法論

環境を詳しく見て、何が変わったのかを見て、それらの変化が環境にどのように影響したかを判断しましょう。 では、テストの第 XNUMX 夜と第 XNUMX 夜はどうなったのでしょうか? 見てみましょう：

• ネットワーク管理ステーションは、VPC F の背後にある AWS のホストに到達しようとしました。
• ステーションからのトラフィックは、RT1 ​​である HSRP プライマリ ゲートウェイに送信されました。
• RT1 には、VPC F に関連付けられた AWS BGP ピア (VGW) から学習した、192.16.0 への BGP がインストールされたルートがありました。
• トラフィックはピアに向かって転送されました。
• VPC ホストからのリターン トラフィックは、RT1 ​​が 1 ネットワークを AWS に向けてアドバタイズしたため、その VPC から RT10.17.1.0 に向けて転送されました (RT1 と RT2 の両方がこれらのルートをアドバタイズしましたが、RT2 はそのアドバタイズでパスをプリペンドしました)。
• RT1 は、着信トラフィックを 17.1.0 に直接接続されたインターフェイスに向けました。 駅がある場所。
• 成功！！

では、第三夜に何が起こったのかを具体的に見てください!! まず、わかっていることを特定することから始めます。ISP のプライマリ接続が切断されました。

図 2: 問題の表示、つまり ISP プライマリ接続のダウン

次に、回路の中断がルーティング テーブルにどのように影響したかについて話しましょう。特に RT1 についてです。 ISP メンテナンス ウィンドウの前に、RT1 ​​のテーブルには、VPC F の eBGP ピアからの eBGP ルートがありました。

RT1#船 ip ルート 10.192.16.0

10.192.16.0/24 のルーティング エントリ

「bgp 65535」で認識、距離 20、メトリック 0

タグ 7224、タイプ外部

ospf 1 による再配布

ospf 1 サブネットによってアドバタイズされたルート マップ DENY-SUMM

192.168.8.6 00:04:10 前からの最終更新

ルーティング記述子ブロック:

* 192.168.8.6、192.168.8.6:00:04 前の 10 から

ルート メトリックは 0、トラフィック シェア カウントは 1

AS ホップ 1

ルートタグ 7224

MPLS ラベル: なし

RT1＃

ただし、サーキット ブレークの後、RT1 ​​のルーティング テーブルは非常に異なって見えます。 RT1s テーブルには 2 10.192.16.0 ネットワークのエントリで、2 つはギガビット イーサネット 0/3 インターフェイスの RT2 に向けられ、もう 0 つはギガビット イーサネット 1/XNUMX インターフェイスの RTXNUMX に向けられています。

RT1#船 ip ルート 10.192.16.0

10.192.16.0/24 のルーティング エントリ

「ospf 1」、距離 110、メトリック 400 で認識

タグ 7224、extern 2 と入力、メトリック 1 を転送

bgp 65535 による再配布

GigabitEthernet10.170.28.12/0 の 1 からの最終更新、00:00:37 前

ルーティング記述子ブロック:

* 172.16.110.12、10.70.28.12:00:00 前の 41 から、GigabitEthernet0/3 経由

ルート メトリックは 400、トラフィック シェア カウントは 1

ルートタグ 7224

10.70.28.12、10.70.28.12:00:00 前の 37 から、GigabitEthernet0/1 経由

ルート メトリックは 400、トラフィック シェア カウントは 1

ルートタグ 7224

VIRL-PHX-AWS-RT1#

しかし、これがどのように失敗を引き起こすのでしょうか? 余分なものはどうですか 有効な ルートにより、管理ステーションの VPC F への接続が失敗しますか? これを理解するには、VPC F と管理サブネットの間でトラフィックがどのように流れるかを見てください。 インバウンド トラフィックは、VPC F から R2 (使用可能な唯一のパス) に流れ、次に管理サブネットに流れます。

図 3: インバウンド トラフィック フローの理解

アウトバウンド トラフィックは別のパスをたどります。 このアウトバウンド パスは、最初は 10.17.1.0 サブネットの HSRP アクティブ メンバーによって決定されます。 RT1のままです。 現在、トラフィックは RT2 経由でアウトバウンドに流れていますが、RT1 ​​は 10.17.1.0 サブネットのアクティブ ルーター (デフォルト ゲートウェイ) のままです。 これを念頭に置いて、以下のアウトバウンド フローに従います。

図 4: アウトバウンド トラフィック フローの理解

デフォルト ゲートウェイ (RT1 で表される) に向かう最初のパスを確認できますが、 XNUMX つの等しいホップ 2 番目のパスで表されます。 172.16.110.0 つは 2 ネットワーク経由で RT10.70.28.0 へ、もう XNUMX つは XNUMX ネットワーク経由で RTXNUMX へ。 と RT3 への 2 つの等しいレイヤ XNUMX ルート RT1 は負荷分散を行い、トラフィックの一部をファイアウォール (2B) パス経由で送信します。 ファイアウォールは不完全な会話を確認し、「非対称ルーティング」を呼び出して中断します。

根本原因分析

何が起こったのかをよりよく理解できるようになったので、次のことを自問するのに良い時期かもしれません。どうやってこれが来るのを見ることができたでしょうか?」 このような状況に備えるために、どのような質問を自問する必要がありますか?また、ネットワーク インフラストラクチャのアンダーレイ/オーバーレイの可視性を向上させるツールはどれですか? どうすればより良くなることができますか？ネットワークトラブルシューティング」そして「シューター」だけではありませんか？

HOW NETBRAIN 助けられたかもしれない

上記の例では、問題を特定したときに問題が特定されました。 traffic path. 以下、私が使用した NetBrain グラフィカルに表現する traffic path 送信元 (この場合は RT1 を使用しました...) から送信先に到達する方法をルーターに問い合わせます。

図 5: を作成する traffic path NetBrain

以下、 NetBrain は、RT1 ​​ルーティング テーブルからの実際のメンテナンス前/メンテナンス後のデータを提供します。 traffic path上で見ました。

図 6: ルーター 1 のルーティング テーブルを決定するために使用 traffic paths

そして最後に、（を使用して NetBrain RT1 のメンテナンス前後の BGP ネイバーの状態を比較するには 1) BGP このシナリオのすべてのイベントのルートであるピアの状態… アイドル (またはその他の確立されていない状態) と RTXNUMX の BGP ネイバー間の確立された状態。

図 7: 「前」と「後」の構成の比較

使い方 NetBrain ととも​​に VIRL オン パケット は、ネットワークのパフォーマンスと特性をリアルタイムでシミュレートし、監視/記録するための優れた組み合わせであり、実際の「本番環境に似た」ビルドアウトを使用して、簡単に文書化して本番環境に転送できます (構成、監視など)。

の詳細については NetBrain, https://www.netbraintech.com/プラットフォーム/