今回は、
「『クラウド』サービスとのL2延伸（結論）」
というタイトルでお送りします。
前回、
「クラウドサービスとのL2延伸（備忘録的要素90%） - 器用貧乏、仮想化をあつかう
https://masaod94.hatenablog.com/entry/2021/08/29/212912」
で書いた話が決着つきました。
簡単に問題点だけ改めて書くと
VMware Cloud にL2延伸している環境で
一部のサーバだけをVMC側に移行した際に
オンプレに残している一部のサーバと
通信を行うとエラーが発生する（ことがある）。
全部がダメではなく、ICMPだったりは大丈夫、、、で
アプリが通信すると駄目になる。
結論、
問題の原因としては、L2延伸によって
Maximum Transmission Unit（MTU）が実質上小さくなることでした。
L2延伸と言ってますが結局VPNですから、
カプセル化する際の余計なヘッダが乗ってくる分
パケットサイズが制限されてしまうことによって、
パケットの断片化が起こりますからね。
（↑断片化されるような環境でも、仕組み上は、自動的に断片化して再結合して通信してくれるんですが、、、）
サーバの設定であったり、アプリケーションの設定で問題が発生することがありますからそこにハマっていたんでしょう。
今回は、ユーザの方で担当していたアプリケーション（DBだからミドルウェア？）の設定で、、、という話だったようです。（細かい設定までは教えてもらえませんでした・・）
そんなわけで、ユーザのDBチームの方で設定を変えて、
リトライした結果、通信の問題は起こらなくなったというわけでした。
まとめ？得られたノウハウ？としては、
アプリ含めてMTU小さくなって問題が出るアプリや
その設定が無いか事前に確認しておかないといけないですねー。
そういえば、余談ですが、
類似の話、、（なのか？）で、
昔もパケット断片化の問題あり、、、
この話はUNIXサーバ（OS）で断片化する際の断片化のやり方がまずくて、
構築していたベンダーさんに「なんでそんな非推奨な設定にしてるの？」と、
話をしましたが、、、。
その際の技術情報はIPAで公開されているこちらですね。
この中の「5) Protocol Stackのセキュア化」の話で、
これによって、うちが構築していた経路上のVPN装置で通信を
ドロップしていたという話だったような、、、。
ご参考まで。
