今回はAuto-VPNにおけるMTU値に関して少し検証してみましたのでまとめたいと思います。
検証する上でよく分からない部分も幾つかありました。
しかし、私がInternet上で得られる情報以外の知識を得られたと思いますのでこの投稿は有意義なものになると信じています。
1.検証構成について
今回の検証は少し特殊な環境になります。
Auto-VPNにおけるHUB拠点はMTU値1500Byteの回線を使用し、Spoke拠点はPPPoE回線配下に位置します。
しかし、Sopke側のMXは直接PPPoE回線には接続されておらず、上位に別のMXが存在します。
2. PCからICMPを使ってMTU値を確認
まずはSpkeのMX配下にあるクライアントからサイズを1472、DFビットをセットしたICMPパケットをHUB配下のIPアドレスに送信します。
すると、MTUが1432であるとSpkeのMXから応答があります。
確認のため返信のあったMTU値から再度サイズを調整してICMPを送信してみます。
ICMPのサイズを1404(1432 - 28)Byteでは問題なくICMPは到達し、
1405Byteでは失敗することが確認できました。
3. Packet Captureによる確認
ICMPのサイズを1404Byteに設定し、Pingを送信して、各ポイントでパケットをキャプチャしてみます。
まずはSpoke側MXのLAN側でキャプチャを行います。
Wireshark上では1446と表示されています。
Ethernetヘッダ(14Byte)、IPヘッダ(20Byte)、ICMPヘッダ(8Byte)を引くと1404Byteとなることがわかります。
次にSpoke側MXのWAN側のキャプチャを行います。
Auto-VPNによるカプセリングが行われていますので、UDPパケットとして確認ができます。
Wiresharkでは1510Byteとして表示がされています。
オリジナルのパケットは1446ByteでAuto-VPNでカプセリングされると、1510Byteとなるため、1510 - 1446 = 64ByteのOverheadとなることがわかります。
(Overheadに関しては後で考察します)
HUB側のMXからの戻りのパケットを確認してみます。
戻りのパケットはWireshark上では1466Byteと78Byteの2つのPacketにFragmentされていることがわかります。
この1466Byteというのは、Ethernetヘッダである14Byteを差し引くと1452Byteとなり、PPPoEのMTU値である
1454Byteよりも少し小さいサイズとなっていることが分かります。
オリジナルのICMPパケットはDFをセットしているにも関わらず、Auto-VPNでカプセリングされたパケットにはDFはセットされていません。
よって、途中経路でAuto-VPNのパケットがFragmentされてしまったとしても問題なく到達ができると言うことになります。
念の為、対抗のHUB側MXのLAN側でキャプチャを取得します。
こちらでは802.1qヘッダが付与されているのでWireshark上では4Byte大きい数字に見えますが、Spoke側で取得したパケットサイズと同じICMPパケットを確認することができます。
この試験により、Auto-VPNは途中経路にて想定したMTU値よりも小さい回線が存在したとしてもUDPパケットはフラグメントされ、対抗のMXにてReassembleされ元のパケットに戻されて通信を行うと言うことがわかりました。
4.MTU値1432の謎
ここでいくつかの謎が発生しました。
Auto-VPNにおけるMTU値は何故1432Byteとなっているのか？
と言うことです。
下記URLを参照してみると、Auto-VPNにおけるOverheadは最大69Byteとあります。
Auto-VPNのMTU値である1432ByteにOverheadである69Byteを足すと、
1432 + 69 = 1501
となり、Ethernetでの一般的なMTU値である1500Byteを超えてしまいます。
ですので、推測としては実はOverheadの最大値である69Byteは間違いでそれよりも小さい数値となるのではないか？と言うことです。
実際に今回の検証においては、Overheadは64Byteと計算されていますので、この検証結果が正しければパケットサイズは1500Byteを超えることが無いと言うことになります。
まとめ
今回の検証結果から、Auto-VPNは
・MTU値は1432Byte
・Overheadは68Byte以下(Documentの69Byteは多分間違い。または若干のバッファを考慮している)
・UDP化されたAuto-VPNパケットはDFは適用されない
・途中経路でFragmentされてしまったAuto-VPNパケットは対抗のMXで再組立される
と言うことになります。
Auto-VPNの通信としては上記により成立するのは間違いないのですが、MXの負荷を考えるとPacketのフラグメントおよび再組立は発生しない方が良いと思うのですが、現状のMXではその辺りの調整する方法は無いと思いますので、これは受け入れるのしか無いのかもしれません。
