☰

내 ISP에서 mtr이 Traceroute보다 더 안정적인 이유는 무엇입니까?

tag-icon • tag-icon ipv6 traceroute
내 ISP에서 mtr이 Traceroute보다 더 안정적인 이유는 무엇입니까?

결과 traceroute6가 잘리고 결과가 mtr전체 경로에 걸쳐 있습니다. 왜 이런 일이 발생합니까?

mtr은 기본적으로 ICMP ECHO를 사용합니다., Traceroute와 마찬가지로. Traceroute를 실행해도 sudo결과는 변경되지 않습니다. -M tcp아니면 -M udp아닐 수도 있습니다 -M icmp.

(저는 의도적으로 IP의 "프로덕션 버전"을 테스트하고 있습니다. 레거시 "실험 버전"은 예상대로 작동합니다 :-).

지하철

$ time mtr -n --report -c 1 google.co.uk
Start: Thu Aug 11 11:29:08 2016
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fdaa:bbcc:ddee:0:924d:4af  0.0%     1    5.7   5.7   5.7   5.7   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  5.|-- 2a00:2380:3013:9000::8     0.0%     1   23.1  23.1  23.1  23.1   0.0
  6.|-- 2a00:2380:13::23           0.0%     1   23.2  23.2  23.2  23.2   0.0
  7.|-- 2a00:2380:2001:5000::d     0.0%     1   19.2  19.2  19.2  19.2   0.0
  8.|-- 2001:4860:0:1::1049        0.0%     1   13.0  13.0  13.0  13.0   0.0
  9.|-- 2001:4860:0:1::8f          0.0%     1   19.6  19.6  19.6  19.6   0.0
 10.|-- 2a00:1450:4009:809::2003   0.0%     1   24.0  24.0  24.0  24.0   0.0

real    0m6.229s
user    0m0.002s
sys 0m0.011s

추적 경로 6

$ time traceroute -6 -n google.co.uk
traceroute to google.co.uk (2a00:1450:4009:809::2003), 30 hops max, 80 byte packets
 1  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9  3.351 ms  3.324 ms  5.569 ms
 2  * * *
 3  * * *
 4  2a00:2302::1103:100:37  20.128 ms !X  20.118 ms !X  20.120 ms !X

real    0m0.221s
user    0m0.000s
sys 0m0.006s

추적 경로 6

Tracepath는 수퍼유저 권한이 필요하지 않고 멋진 옵션이 없다는 점을 제외하면 Traceroute와 유사합니다.

UDP 포트 또는 임의의 포트를 사용합니다.

Tracepath6은 Traceroute6의 좋은 대체품이자 Linux 오류 대기열 애플리케이션의 전형적인 예입니다.

$ time tracepath6 -n google.co.uk
 1?: [LOCALHOST]                        0.035ms pmtu 1488
 1:  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9                   4.101ms 
 1:  fdaa:bbcc:ddee:0:924d:4aff:fe06:1c9                   3.161ms 
 2:  no reply
 3:  2a00:2302::1103:100:36                               17.379ms asymm  5 
 4:  2a00:2302::1103:100:37                               17.222ms !A
     Resume: pmtu 1488 

real    0m5.068s
user    0m0.001s
sys 0m0.005s

결과는 실행마다 약간씩 다릅니다. 때로는 홉 3이 표시되지 않는 경우도 있습니다. 홉 3 또는 4의 주소도 변경됩니다(사용된 도구에 관계없이). 두 개의 다른 경로가 사용되는 것처럼 보입니다.

대화형으로 실행 하면 mtr결국 홉 3(홉 4는 아님)을 찾을 수 있습니다. 점프는 80-90%의 손실을 보여줍니다. (NANOG 목록에서 언급했듯이 mtr :-)과 같은 도구의 결과를 완전히 이해하려면 전문적인 네트워킹 지식이 필요합니다.

답변1

Traceroute 맨페이지에는 !XICMP 지침 중 하나가 표시됩니다.실수응답(필수 "TTL 초과" 제외) traceroute보자마자 포기하세요. 더 튼튼해 보이네요 mtr.

이것은 이상한 경우입니다. TTL이 충분히 큰 패킷이 통과하도록 허용되는 경우 "TTL 초과" 응답이 "관리 금지"로 대체되는 이유를 이해할 수 없습니다. mtr이 이상한 일을 참아 주셔서 감사합니다 :).

이동 시간이 지나면 몇 가지 추가 설명이 인쇄될 수 있습니다: !H, !N 또는 !P(호스트, 네트워크 또는 프로토콜에 연결할 수 없음), !S(소스 라우팅 실패), !F(조각화 필요), !X(관리 통신) 금지됨), !V(호스트 우선순위 충돌), !C(우선순위 컷오프 유효) 또는 !(ICMP 도달 불가능 코드). 거의 모든 탐색 결과에 도달할 수 없는 상황이 발생하면 Traceroute는 포기하고 종료됩니다.

관련 정보