Tunnel over Tunnel のときのMTUについて

あまり無いとは思いますが, Tunnelを張った先で更にTunnelを張るような構成(Tunnel over Tunnel)のとき, エンド間でのDFビットを立てたpingではMTU値を正しく測定できません。

例えば以下の図の構成を考えた時, PC1とPC2との通信においてGREのカプセル化が2回かかります。

その時、PC1~PC2間の通信で最適なMTU値は

1500 – 24 – 24 = 1452

となります。

Gre over Gre 構成の一例

しかし, Pingで確認しようとすると, ICMPが2回カプセル化されてしまい, 2つ目のトンネルではDFビットが認識されずフラグメントされてしまいます。
そのため, MTUが判定されるのは1つ目のGREトンネルのみとなり, 正しくMTUを計測されることができません。

例えばPC1からのpingの結果が以下のようになったとしても, 2本目のGREトンネルの中ではフラグメント化されています。

$ /bin/ping 192.168.2.12 -s 1448 -M do
PING 192.168.2.12 (192.168.2.12) 1448(1476) bytes of data.
1456 bytes from 192.168.2.12: icmp_seq=1 ttl=62 time=1.70 ms
1456 bytes from 192.168.2.12: icmp_seq=2 ttl=62 time=1.81 ms
1456 bytes from 192.168.2.12: icmp_seq=3 ttl=62 time=6.20 ms
^C
--- 192.168.2.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.700/3.239/6.204/2.097 ms

$ /bin/ping 192.168.2.12 -s 1449 -M do
PING 192.168.2.12 (192.168.2.12) 1449(1477) bytes of data.
ping: local error: Message too long, mtu=1476
ping: local error: Message too long, mtu=1476
ping: local error: Message too long, mtu=1476
^C
--- 192.168.2.12 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2110ms

ICMPがフラグメント化されている様子

こういった構成では, しっかりMTU値を計算し, 最初のルータにおいて適切なMTU値(今回の構成では1452バイト)を設定しておく必要があります。