☰

Ошибка OS X в максимальной единице передачи данных (PMTU) Обнаружение маршрутизатора Black Hole

tag-icon • tag-icon macos tcp mtu
Ошибка OS X в максимальной единице передачи данных (PMTU) Обнаружение маршрутизатора Black Hole

Все началось, когда я пытался загрузить подкаст на свой Mac. Это происходит и в Snow Leopard, и в Lion, когда интерфейс Ethernet настроен на использование Jumbo Frames.

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

Заголовки проходят нормально, но загрузка никуда не идет. ЭтотолькоУ меня возникла подобная проблема с веб-сервером, но она все равно раздражает, и я хотел бы узнать, есть ли решение, кроме как отказаться от больших кадров везде.

Я определил, что могу загрузить частичный файл, если размер загружаемого фрагмента составляет 1448 байт или меньше. Я могу использовать диапазон 0-1447 или 10000-11447, так что это не позиция в файле, а размер фрагмента. WAN MTU на моем маршрутизаторе был установлен на 1500, поэтому я пробовал уменьшать его пошагово, пока не достиг 1400, но это все равно не имело никакого значения.

Я думал, что это проблема с обнаружением Path MTU Black Hole, потому что проблема исчезает, когда я прекращаю использовать jumbo-кадры на интерфейсе Ethernet. Но у меня все настроено для обнаружения black hole (насколько я могу судить), и 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-системы. (Я думаю, что он считает данными 8 байт заголовка ICMP, но не 20 байт заголовка IP, в отличие от большинства, которые не считают ни то, ни другое, а некоторые считают и то, и другое.)

Я не хочу отказываться от преимуществ производительности больших кадров в моей локальной сети только ради этого одного сломанного веб-сайта, но, конечно, я хочу свой подкаст. Поэтому я ищу предложения, что можно попробовать.

У моего Mac есть 2 встроенных порта Ethernet, поэтому я попробовал подключить второй с MTU 1500 и принудительно curlиспользовать этот порт. Curl сказал, что использует этот порт, но MTU этого порта не влиял на то, работала загрузка или нет. Важен был MTU первого активного порта Ethernet. Я тоже не знаю, что это значит.

Есть у кого-нибудь предложения?

решение1

Обходные пути:

  • Уменьшите MTU интерфейса до 1500. Системные настройки -> Сеть, выберите интерфейс (например, Встроенный Ethernet), нажмите кнопку Дополнительно..., вкладку Ethernet, выпадающий список MTU или установите для параметра Настроить значение Автоматически. Это решает проблему, но означает, что вы не сможете использовать Jumbo-кадры в локальной сети (по крайней мере с этого компьютера).
  • Если бы это было в Linux: используйте iptablesдля ограничения TCP MSS только для этого хоста. --set-mss 1460

Решение:

  • Исправьте конфигурацию сервера, чтобы уменьшить MTU или включить функцию обнаружения MTU пути.

Так уж получилось, что мне наконец удалось найти человека в компании CDN, с которым можно было поговорить и который мог реализовать это решение. Они снизили MTU, и это решило проблему.

Связанный контент