UDP/TCPネットワークパケットを強制的に事前決定されたNexthopにする方法はありますか？

私はクライアントにサーバーSへの要求を発行しています。UDP/TCP要求を仮定します。 HOP1はロードバランサスイッチであり、パケットをServerSにルーティングする方がパスHOP4->HOP5が良いと検出されたとします。私の質問は、HOP1がクライアントによって生成されたpktを受信した後、パケットがSに達するように、すなわちHOP4のみを介して計算された最良の経路をとるように強制することができます。UDP/TCPネットワークパケットを強制的に事前決定されたNexthopにする方法はありますか？

私が考えていた

、次のようにPKTのフィールドSA、DA、MAC-SA、MAC-DAフィールドを設定する必要があり、そのHOP1：

SA : HOP1 
DA : ServerS 
SMAC - HOP1MAC 
DMAC - HOP4MAC

だろうと仕事を？より良いアプローチはありますか？

私の他の疑問は、それがサーバーS.ので、HOP4のクライアントとして偽装し、クライアントの要求がServer Sからの応答を受け取ることになる転送するのでServer Sため、HOP4がクライアントとして現れる、ということです。 HOP4は、受信した応答が実際にはCLient CLであり、それ自体ではないことをどのように判断できるのですか？ NATは絵になるのですか？誰かが光を当てることはできますか？

出典

2016-11-04 Abhishek Sagar

IPにはソースルーティングオプションがありますが、有料のネットワークエンジニアはソースルーティングを許可するルータを設定していません。ネットワークルーティングは決定論的である必要があり、ルーティングプロトコルはどの方向にパケットを送るべきかを決定します。エンドデバイスやアプリケーションがこれを行うことを許可すると、これが中断されます。

MACアドレスはレイヤ2アドレスであり、レイヤ2フレームはレイヤ3パケットから削除され、各ホップで破棄されます。パス内の各ホップに対して新しいレイヤ2フレームが作成され、ネットホップで取り除かれ廃棄されます。 MACアドレスはLANにのみローカルであり、ルータホップを越えて生き残ることはできません。ソースLANにローカルではない宛先MACアドレスを使用すると、障害が発生することがあります。実際、すべてのレイヤ2プロトコルがMACアドレスを使用するわけではなく、ホップ間のリンクのどれかがMACアドレスを使用していないかどうかを知る方法がありません。 MACアドレスを使用するレイヤ2プロトコルのうち、48ビットのMACアドレスを使用するものと、64ビットのMACアドレスを使用するものがあります。

実際には、アプリケーションやホストがパケットの経路を保証する方法はありません。それはルータの仕事です。

出典

2016-11-04 14:19:06

ほとんどすべての場合、ルーターはIPソースルーティングを無視します。また、宛先MACアドレスが別のLAN上にある場合、最初のルータはホストからフレームを受信しません。 MACアドレスを含むレイヤー2アドレスは、LAN上でのみ関連するか、またはそれまでに見られ、LANトラフィックは宛先MACアドレスでLAN上のホストに送信されます。宛先MACアドレスが異なるLAN上にある場合、ルータを含むソースLAN上のホストは、その宛先MACアドレスを持つフレームを取得しません。 –

レイヤ2アドレスはLAN上でフレームを配信し、レイヤ3アドレスはLAN間でフレームを配信します。 –

私はネットワーキングの分野でもっと知恵を得て、この質問に答えました。 Source packet routing (SPRING)は、これを達成するための新しいネットワーキングです。その他の手法はTunneling - Ip in IP encapsulation,GRE tunnelsなど

出典

2017-09-12 13:48:50

ほとんどのルータはソースルーティングを無視します。ホストにパケットのルーティング方法を指示させるのは、本当に悪い考えです。これにより、注意深く設計されたネットワークが中断され、自動的に損傷を回避する動的経路指定というIPルーティングの考え方が失われます。 –

UDP/TCPネットワークパケットを強制的に事前決定されたNexthopにする方法はありますか？

答えて

関連する問題