.png)
Azure で複数の VM を実行しています。VM は NSG を含むサブネットで実行されています。NIC は NSG を使用せず、高速ネットワークも使用しません。
VM が TCP を使用して同じサブネットの別の VM と通信する場合、SYN パケットの MSS 値が 42 減少することがわかります。つまり、MSS=876 の TCP SYN を同じネットワークの別の VM に送信すると、他の VM は MSS=834 の TCP SYN をキャプチャします。
クライアント：
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
サーバ：
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
当社では複数の NVA を使用しており、SYN パケットは複数のホップを経由して移動します。実際に MSS が複数回削減されていることがわかります。当初は 84 の削減が測定されましたが、場合によっては 138 の削減も測定されました (実際には 42 の倍数ではありません)。つまり、ネットワークの効率が 10% 以上削減されることになります。
私は、さまざまなネットワーク アプライアンスが MSS をどのように扱うかを調べてきました。ほとんどの場合、MSS は、静的な値またはパス MTU に固定されることによって、固定値に設定されます。PaloAlto は、ネットワーク インターフェイスの MTU (固定値) を基準とした「調整」を使用します。Arista では、入力トラフィックまたは出力トラフィックに上限値を設定できますが、これも絶対値です。PaloAlto などの一部のファイアウォール ベンダーは、DoS 攻撃が発生して SYN クッキーがアクティブになると MSS を減らしますが、その場合の MSS は 8 つの可能な値のいずれかになります。
この MSS -= 42 のメカニズムは TCP に支障をきたすと考えています。クライアントがジャンボ フレームをサポートしていて、MSS 8860 を送信すると、Azure のサーバーは 8876 を受信し、サーバー自身は 1330 を応答しますが、クライアントは 1246 を受信します。クライアントはパケットのペイロードが 1246 バイトであることに同意しますが、サーバーは 1330 バイトのペイロードを送信します。
最大の問題は、トラフィックが「偶然」に機能するケースがあることです。エクスプレス ルート側ではクランプが適切に行われていませんが、この -42 により、パケットのルーティング方法がわずかに変更されるまで、MSS は実際に「適合する」値に削減され、どこかで構成ミスがあったことが突然判明します。
この減少を説明する方法はありますか? この動作はどこにも文書化されていないと思います。
編集
ただ読んでいるRFC879
MSS は、データ フローの各方向で完全に独立して使用できます。その結果、2 つの方向の最大サイズがかなり異なる可能性があります。
RFC によれば、これは正当なようです。それでも、奇妙な動作です。
答え1
物理ネットワークとは対照的に、SDN ネットワークはカプセル化ヘッダー (GRE) に追加の「バイト」を消費します。 表示される IP は CA (顧客アドレス) ですが、クラウド プロバイダーでのルーティングを必要とする PA (プロバイダー アドレス) もあります。 したがって、クラウド プロバイダーはバックエンド ルーティングを行うためにインフラで追加の TCP クランプを適用するため、利用可能な MSS が少なくなります。