☰

OS X パス最大転送単位 (PMTU) ブラックホール ルーター検出の失敗

tag-icon • tag-icon macos tcp mtu
OS X パス最大転送単位 (PMTU) ブラックホール ルーター検出の失敗

これはすべて、Mac でポッドキャストをダウンロードしようとしたときに始まりました。イーサネット インターフェイスがジャンボ フレームを使用するように設定されていると、Snow Leopard と Lion の両方でこの問題が発生します。

prompt> curl -v -o x.mpg http://audio.wnyc.org/freakonomics_specials/freakonomics_specials041112.mp3 
* About to connect() to audio.wnyc.org port 80 (#0)
*   Trying 204.93.180.53... Local Interface en0 is ip 172.16.1.2 using address family 2
* Local port: 0
* connected
* Connected to audio.wnyc.org (204.93.180.53) port 80 (#0)
> GET /freakonomics_specials/freakonomics_specials041112.mp3 HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: audio.wnyc.org
> Accept: */*
> 
OK
< Server: nginx/0.7.65
< Date: Mon, 16 Apr 2012 23:39:03 GMT
< Content-Type: audio/mpeg
< Content-Length: 42075070
< Last-Modified: Tue, 10 Apr 2012 21:15:08 GMT
< Connection: close
< Content-Disposition: attachment
< Accept-Ranges: bytes
< 
  0 40.1M    0     0    0     0      0      0 --:--:--  0:00:24 --:--:--     0^C

ヘッダーは問題なく届きますが、ダウンロードがまったく進みません。これがのみWeb サーバーでこのような問題が発生していますが、それでも煩わしいので、どこでもジャンボ フレームを放棄する以外に解決策があるかどうかを確認したいと思います。

ダウンロードするチャンクのサイズが 1448 バイト以下であれば、部分的なファイルをダウンロードできると判断しました。範囲は 0 ～ 1447 または 10000 ～ 11447 を使用できるので、ファイル内の位置ではなくチャンクのサイズが問題となります。ルーターの WAN MTU は 1500 に設定されていたので、1400 になるまで段階的に減らしてみましたが、それでも変化はありませんでした。

イーサネット インターフェイスでジャンボ フレームの使用をやめるとこの問題は解消されるので、これは Path MTU ブラック ホール検出の問題だと思っていました。しかし、ブラック ホール検出用にすべて設定してあり (私の知る限り)、ping では問題は発生しません。

ping  -g1435 -G1445 204.93.180.53PING 204.93.180.53 (204.93.180.53):
(1435 ... 1445) data bytes
1443 bytes from 204.93.180.53: icmp_seq=0 ttl=51 time=69.223 ms
1444 bytes from 204.93.180.53: icmp_seq=1 ttl=51 time=75.542 ms
1445 bytes from 204.93.180.53: icmp_seq=2 ttl=51 time=72.136 ms
1446 bytes from 204.93.180.53: icmp_seq=3 ttl=51 time=73.732 ms
1447 bytes from 204.93.180.53: icmp_seq=4 ttl=51 time=72.057 ms
1448 bytes from 204.93.180.53: icmp_seq=5 ttl=51 time=73.377 ms
1449 bytes from 204.93.180.53: icmp_seq=6 ttl=51 time=71.717 ms
1450 bytes from 204.93.180.53: icmp_seq=7 ttl=51 time=73.293 ms
1451 bytes from 204.93.180.53: icmp_seq=8 ttl=51 time=71.874 ms
1452 bytes from 204.93.180.53: icmp_seq=9 ttl=51 time=73.206 ms
1453 bytes from 204.93.180.53: icmp_seq=10 ttl=51 time=71.289 ms

実際、ping は 1494 バイトまで動作しますが、Mac は他の *nix とは異なる方法でバイトをカウントしていると思います。(Mac は ICMP ヘッダーの 8 バイトをデータとしてカウントしますが、IP ヘッダーの 20 バイトはカウントしません。ほとんどの Mac ではどちらもカウントされず、一部の Mac では両方がカウントされます。)

この壊れた Web サイト 1 つだけのために、LAN 上のジャンボ フレームのパフォーマンス上の利点を放棄したくはありませんが、もちろんポッドキャストも必要です。そこで、試すべきことについての提案を探しています。

私の Mac には 2 つの内蔵イーサネット ポートがあるので、2 番目のポートを MTU 1500 で接続し、curlそのポートを強制的に使用するようにしてみました。Curl ではそのポートを使用していると表示されましたが、そのポートの MTU はダウンロードが機能するかどうかには影響しませんでした。重要なのは、最初のアクティブなイーサネット ポートの MTU でした。それが何を意味するのかは私もわかりません。

誰か提案はありますか?

答え1

回避策:

  • インターフェイスの MTU を 1500 に下げます。システム環境設定 -> ネットワークでインターフェイス (例: 内蔵 Ethernet) を選択し、詳細... ボタン、Ethernet タブ、MTU ドロップダウンをクリックするか、構成を自動に設定します。これで問題は解決しますが、LAN 上でジャンボ フレームを使用できなくなります (少なくともこのコンピューターからは)。
  • Linux の場合:iptablesこのホストのみの TCP MSS をクランプするために使用します。 --set-mss 1460

解決：

  • MTU を下げるか、パス MTU 検出が機能するようにサーバー構成を修正します。

結局、CDN 会社で解決策を実装できる人を見つけることができ、MTU を下げてもらい、問題は解決しました。

関連情報