MTR

MTR이란?

My traceroute의 약어.

 

Traceroute인데 protocol(TCP/UDP)를 지정하여 사용가능하다.

=> 여기에서 조금 오해가 있을 수 있는데 이번글에서 MTR이 TCP에 대해 어떻게 동작하는지 설명하도록 하겠다.

 

mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool.
As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME.
by sending packets with purposely low TTLs.
It continues to send packets with low TTL, noting the response time of the intervening routers.
This allows mtr to print the response percentage and response times of the internet route to HOSTNAME.
A sudden increase in packet loss or response time is often an indication of a bad (or simply overloaded) link.
The results are usually reported as round-trip-response times in miliseconds and the percentage of packetloss.

MTR은 traceroute와 ping을 합쳐 놓은 네트워크 툴이다.

TTL 낮은 패킷을 만들어 목적지로 가는 경로상의 홉에서 응답 속도를 체크하여 네트워크 지연을 살펴볼 수 있다.

 

 

이 프로그램을 찾게된 사유는 TCP로도 체크 가능하다는 점이었다.

   => 이게 참 계륵이다.

 

 

사용법은 man page 참고하시고....

mtr [-BfhvrctglxspQemniuTP46] [--help] [--version] [--report] [--report-wide] [--report-cycles COUNT] [--curses] [--split] [--raw] [ --xml] [--mpls] [--no-dns] [--show-ips] [--gtk] [--address IP.ADD.RE.SS] [--interval SECONDS] [--max-ttl NUM] [--first-ttl NUM] [--bitpattern NUM] [--tos NUM] [--psize BYTES | -s BYTES] [--tcp] [--udp] [--port PORT] [--timeout SECONDS] HOSTNAME [PACKETSIZE]

 

예시를 보며 어떻게 동작하는지 살펴보자

 

1. 일반적 사용

[root@localhost ~]# mtr -n -c 1 kaist.ac.kr --report
Start: Sat Jun 18 23:12:18 2022
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.222.1              0.0%     1    0.7   0.7   0.7   0.7   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 125.141.249.141            0.0%     1    2.2   2.2   2.2   2.2   0.0
  4.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  5.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  6.|-- 112.174.101.110            0.0%     1    4.9   4.9   4.9   4.9   0.0
  7.|-- 112.188.134.130            0.0%     1    5.0   5.0   5.0   5.0   0.0
  8.|-- 211.230.12.2               0.0%     1   11.4  11.4  11.4  11.4   0.0
  9.|-- 143.248.117.4              0.0%     1    6.8   6.8   6.8   6.8   0.0
 10.|-- 143.248.117.29             0.0%     1    7.5   7.5   7.5   7.5   0.0
 11.|-- 143.248.117.62             0.0%     1    5.6   5.6   5.6   5.6   0.0
 12.|-- 143.248.155.130            0.0%     1    7.5   7.5   7.5   7.5   0.0
 13.|-- 143.248.155.65             0.0%     1    7.6   7.6   7.6   7.6   0.0

 

kaist.ac.kr로 한번 때려봤다.

끝부분(13번)에서 응답이 제대로 왔다면 중간 홉(2, 4, 5)로스 100%는 무시해도 된다.

중간 장비에서 보안과 시스템 보호(Control Plane Policing) 목적에서 발생하는 로스로 분석해야 합당하다.

 

그리고 패킷은 어떻게 나왔나하면!

DNS 쿼리 응답받고 icmp 패킷을 여러개 보내는데 TTL을 1부터 하나씩 늘려서 보낸다.

ping request의 TTL부분을 유심히 보자.

 

홉마다 TTL이 만료되며 Time to live exceeded 메세지를 출발지로 되돌려 준다.

출발지가 해당 메세지를 받으면 그것이 홉마다의 응답속도로 기록이 되는 형태이다.

 

그러니까 1번 홉의 결과는 출발지로부터 1번홉까지 갔다 오는 응답속도

2번 홉의 결과는 출발지로부터 1번홉을 거쳐 2번까지 갔다 오는 응답 속도

3번 홉의 결과는 출발지로부터 1,2번홉을 거쳐 3번까지 갔다 오는 응답 속도

이런식이다.

 

 

출발지 <-> 7번홉 rtt는 5.0ms이고 출발지 <->8번홉 rtt는 11.4ms인데 그럼 둘 간의 갭이 6.4ms이니 이것을 7,8번간 사이의 지연으로 봐도 될까?

그럴수도 있고 아닐수도 있다.

정확한 답은.... "홉이 늘어날 수록 증가하는 수치만 보여진다는 홉별 갭이 홉 간의 지연으로 볼 수도 있다"가 될 것 같다.

 

출발지 <-> 8번홉 rtt는 11.4ms인데 출발지 <-> 9번홉 rtt는 6.8ms이다.

아니 어떻게 8번홉 보다 더 긴 9번홉이 더 빠른 응답을 받을 수 있을까?

지속적으로 증가하지 않은 케이스이니 8홉에서 지연이 많이 발생한다고 볼 수 없겠네? 정도로 받아들이면 좋을 것 같다.

 

 

2. TCP사용

자 그럼 TCP로도 체크를 해보자.

일단 kaist.ac.kr 홈페이지 443포트가 열려있으니 그걸로 체크를 해보자

 

[root@localhost ~]# mtr -n -c 1 -T -P 443 kaist.ac.kr --report
Start: Sat Jun 18 23:09:49 2022
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.222.1              0.0%     1    0.8   0.8   0.8   0.8   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 125.141.249.141            0.0%     1    1.9   1.9   1.9   1.9   0.0
  4.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  5.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  6.|-- 112.174.101.102            0.0%     1    5.5   5.5   5.5   5.5   0.0
  7.|-- 112.188.135.130            0.0%     1    7.4   7.4   7.4   7.4   0.0
  8.|-- 211.230.12.2               0.0%     1   26.2  26.2  26.2  26.2   0.0
  9.|-- 143.248.117.5              0.0%     1    7.5   7.5   7.5   7.5   0.0
 10.|-- 143.248.117.30             0.0%     1    9.9   9.9   9.9   9.9   0.0
 11.|-- 143.248.117.62             0.0%     1    5.8   5.8   5.8   5.8   0.0
 12.|-- 143.248.155.130            0.0%     1    7.7   7.7   7.7   7.7   0.0
 13.|-- 143.248.155.65             0.0%     1  202.2 202.2 202.2 202.2   0.0

 

이번에도 8번홉이 조금 이상한데 일단 기분탓이니 넘어가자.

 

여기서 이상한점 1. TCP 443을 체크하는데 중간 장비들은 뭔데 응답하지?

            이상한점 2. 목적지 응답속도는 icmp(6.7ms)와는 달리 엄청 크네(202.2ms)?

 

패킷을 들여다보자.

retransmission은 응답없는 2, 4, 5번홉에 대한 것이니 무시하자

이상한점1

   정답 : TTL 만료되면 TCP 패킷에도 ICMP로 응답함. 중간 홉에서 443 포트가 열려있어서 응답하는게 아님.

   패킷번호 6,9,13,15,17,19,21,23,25를 보면 된다.

 

 

이상한점2

  정답 : 목적지가 응답이 가능할 경우 TCP는 ICMP와 동작방식이 다름.   

  여담 : 여러번 시도해봤는데 202~203 사이가 나왔다, 그리고 snu.ac.kr도 동일했다.

  패킷번호 43을 보면 TCP 델타가 0.19151700이다.

  이 TCP 스트림을 따보면 아래와 같은 패킷이 나온다.

 

 

시간은 1번 프레임부터 지난 시점으로 변경하였음

여기서 202를 찾아내야 한다

가설1. 3way handshake 이후 종료까지의 갭이 202이다.

가설2. SYN이후부터 출발지에서 보내는 FIN, ACK까지의 갭이 202이다.

뭐가 되었든... 3way handshake 이후 191ms가 지난 시점에서야 출발지에서 psh,ack가 발생한다.

목적지 TCP 응답 결과가 202.2가 나왔지만 출발지에서 출발이 늦었으니 응답도 늦었을뿐 목적지의 잘못은 아니지 않느냐.

 

결론 : MTR로 TCP 응답 속도를 측정하는건 에바다

 

---

22.06.19 11:10 추가

게이트웨이에 웹이 띄워져있어서 게이트웨이로 TCP mtr을 해봤다.

확인 사살!

 

[root@localhost ~]# mtr -n -c 1 -T -P 80 192.168.222.1 --report
Start: Sun Jun 19 11:06:47 2022
HOST: localhost.localdomain       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.222.1              0.0%     1  202.0 202.0 202.0 202.0   0.0