☰

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

헤더는 잘 통과하지만 다운로드는 아무데도 도달하지 않습니다. 이것이오직웹 서버 이런 종류의 문제가 있지만 여전히 짜증나고 모든 곳에서 점보 프레임을 포기하는 것 외에 다른 수정 사항이 있는지 확인하고 싶습니다.

다운로드하는 청크의 크기가 1448바이트 이하이면 부분 파일을 다운로드할 수 있다고 판단했습니다. 범위 0-1447 또는 10000-11447을 사용할 수 있으므로 파일의 위치가 아니라 청크의 크기입니다. 내 라우터의 WAN MTU는 1500으로 설정되어 있었기 때문에 1400에 도달할 때까지 단계적으로 줄여보려고 했지만 여전히 아무런 차이가 없었습니다.

이더넷 인터페이스에서 점보 프레임 사용을 중지하면 문제가 사라지기 때문에 이것이 Path MTU 블랙홀 검색의 문제라고 생각했습니다. 하지만 (제가 알 수 있는 한) 블랙홀 발견을 위한 모든 설정이 완료되어 있으며 핑에서는 아무런 문제도 발견되지 않습니다.

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와 다르게 바이트를 계산한다고 생각합니다. (ICMP 헤더의 8바이트는 데이터로 계산되지만 IP 헤더의 20바이트는 데이터로 계산되지 않습니다. 대부분은 둘 중 하나도 계산하지 않고 일부는 둘 다 계산합니다.)

나는 단지 이 망가진 웹 사이트 때문에 내 LAN에서 점보 프레임의 성능 이점을 포기하고 싶지 않지만 물론 내 팟캐스트도 원합니다. 그래서 시도해 볼 만한 제안을 찾고 있습니다.

내 Mac에는 2개의 이더넷 포트가 내장되어 있으므로 두 번째 포트를 MTU 1500에 연결하고 강제로 curl해당 포트를 사용하도록 했습니다. Curl은 해당 포트를 사용하고 있지만 해당 포트의 MTU는 다운로드 작동 여부에 영향을 미치지 않는다고 말했습니다. 중요한 것은 첫 번째 활성 이더넷 포트의 MTU였습니다. 나도 그게 무슨 뜻인지 모르겠어요.

제안할 사람 있나요?

답변1

해결 방법:

  • 인터페이스 MTU를 1500으로 낮춥니다. 시스템 기본 설정 -> 네트워크, 인터페이스(예: 내장 이더넷)를 선택하고 고급... 버튼, 이더넷 탭, MTU 드롭다운을 클릭하거나 구성을 자동으로 설정합니다. 이렇게 하면 문제가 해결되지만 LAN(적어도 이 컴퓨터에서는)에서 점보 프레임을 사용할 수 없습니다.
  • Linux에 있는 경우: iptables이 호스트에 대해서만 TCP MSS를 고정하는 데 사용합니다. --set-mss 1460

해결책:

  • MTU를 낮추거나 경로 MTU 검색이 작동하도록 서버 구성을 수정합니다.

공교롭게도 마침내 CDN 회사에서 솔루션을 구현할 수 있는 사람을 찾았고, MTU를 낮추어 문제를 해결했습니다.

관련 정보