非対称ルーティング-原因と影響？

私が自分のネットワークで「非対称ルーティング」と定義したものを持っている顧客に出くわすことがあります。簡単に言うと、同じIPサブネット上に2つのゲートウェイがあります。クライアントは1つのゲートウェイ（つまり172.16.1.1）を指すように構成されていますが、どこかに接続してルーティングする別のデバイス（つまり172.16.1.2）があります。主に、このような設定は、2つの異なるタイプのWAN接続がある場合に見られました。1つはインターネット接続、もう1つは企業MPLS接続です。

私は個人的に、上記の種類のネットワーク設計に惹かれていません。各サブネットにはゲートウェイが1つだけ必要です。私の観点から見ると、上記のシナリオでは、クライアントがデフォルトゲートウェイ（172.16.1.1）にパケットを送信し、それらのパケットが他のルーター（172.16.1.2）に転送されて返信されるため、クライアントに問題が発生する可能性があります。と、172.16.1.2を通過するだけでクライアントに到達します。クライアントは、返信パケットが172.16.1.1から送信されることを期待するか、期待する必要がありますか。

この問題についてご意見や技術的な見解をいただければ幸いです。

HSRPやVRRPなどのFirst Hop Redundancy Protocolsを検討することをお勧めします。

実際、2つのゲートウェイを持つことは非常に優れたネットワーク設計になる可能性があります。これは、ルーターに障害が発生した場合でも、他のルーターがシームレスに引き継ぐことができるためです。ただし、ご存じのとおり、サブネット上の各クライアントを手動で再構成する必要がある場合、この移行を行うのは簡単ではありません。

HSRP（Cisco以外のギアを使用している場合はVRRP）などのプロトコルを使用すると、サブネット上の2つ（またはそれ以上）のルーター（またはL3スイッチ）で単一のIPアドレスを共有できます。最初のルーターのアドレスは.2、seondのアドレスは.3、「仮想IPアドレス」は.1で、両方のルーターが構成を通じて認識しています。プライマリルーターに障害が発生した場合、セカンダリはこれを検出して仮想IPアドレスを引き継ぐことができます。つまり、クライアントは.1をゲートウェイとして構成するだけで十分です。

ルーティングの設計に関しては、現在のセットアップに大きく依存します。両方のゲートウェイが同じインターネットエッジにつながる可能性があります。その場合、問題は発生しない可能性があります。非対称ルーティングは、主にパケットが間違った順序で配信されるリスクがあるために悪い場合がありますが、ここでも、話しているトポロジに大きく依存します。

私が今言ったことには多くの設計原則が含まれていました。両方のプロトコルを調査して、環境に最適なものを決定することをお勧めします。シスコのギアを使用している場合、HSRPはこの問題を解決するために広く使用され、よく理解されている方法です。

インターネット全体が非対称ルーティングで構築されているため、非常に一般的です。クライアントは、パケットを受信するインターフェイスとパケットの送信元に関心がありますが、そのインターフェイスでクライアントに渡されたルーターではありません。

ただし、状態を追跡しているデバイス（特にファイアウォール）とNATが関係している場合は、非対称ルーティングが問題になる可能性がありますが、私の知る限り、これはあなたの例では当てはまりません。

ネットワーククライアントは、4つの値の組み合わせに基づいてトラフィックフローを識別します。

• 送信元アドレス
• 送信元ポート
• 宛先アドレス
• 宛先ポート

異なる接続ごとに、上記の4つの値は異なる組み合わせを形成し、応答パケットを正しいフローに一致させるために使用されます。ご覧のとおり、ゲートウェイまたはネクストホップアドレスはリストに含まれていないため、クライアントは、パケットの送信に使用したのと同じゲートウェイを経由してパケットが戻ってきても問題ありません。したがって、ネットワーククライアントは、リモートエンドからトラフィックを受信できるとすぐに非対称ルーティングを気にしません。実際、TCP / IPはもともと非対称ルーティングをサポートするように設計されていました。

ただし、ネットワークの中間デバイスに焦点を当てている場合、特定の機能を提供するために接続内のすべてのパケットを確認する必要があるデバイス/テクノロジーを使用しているとすぐに、非対称ルーティングは許容されません。たとえば、NAT、ステートフルファイアウォール、または一部のWANオプティマイザ。このようなシナリオでの非対称ルーティングは、意図した機能が提供されないか、最悪の場合、パケットがドロップして通信を不可能にします。

私は自分の前の回答に同意しますが、何かを追加する必要があります。いずれかのゲートウェイ、または2つのゲートウェイのうちの1つだけを介して渡されるホップにフィルタリングがある場合、問題が発生する可能性があります。（ソースマシン、宛先マシンなどの両方のゲートウェイ経由で渡されるホップ、および「両方のゲートウェイパスに共通」のホップは、次のシナリオには関係ありません）

たとえば、Aがゲートウェイ1を介してBにパケットを送信し、パケットがゲートウェイ2を介して戻る場合、ゲートウェイ2がフィルタリングを行っていると、応答パケットがドロップされる可能性が高くなります（そのゲートウェイが開始接続パケットを認識しなかったため、 t応答を期待します。したがって、応答パケットの宛先/ポートが通常フィルタリングされる場合、それはフィルタリングされます。）

（もちろん、多くの同様のシナリオがあります）

非対称ルートが問題を引き起こすその他の2つの領域は次のとおりです。1. MTUディスカバリ-2つのパスの最小MTUが異なる場合、エンドポイントMTUパスディスカバリは2つのMTUのうち最大のものをもたらす可能性があり、その結果ドロップします。最大サイズのパケット。たとえば、一方のパスがVPNトンネルを通過し、もう一方のパスが通過しない場合、VPNトンネルのMTUは小さくなります。pingは正常に機能しますが、大きなファイルの転送は常に失敗します。2.接続のトラブルシューティングは、2つのパスのいずれかが壊れていても、もう1つは壊れていない場合、さらに困難になります。帯域外管理チャネルを必要とする接続の両側から実行されない限り、リバースパスの中間点を検出できないため、古き良き「traceroute」はまったく役に立ちません...