지식 베이스

MTR로 패킷 손실을 찾고 올바르게 해석하기

보고된 패킷 손실의 대부분은 트랜짓 라우터의 ICMP 속도 제한입니다. 티켓을 작성하기 전에 MTR을 올바르게 실행하고 두 가지를 구분하는 방법을 설명합니다.

설치

apt install -y mtr-tiny     # Debian
dnf install -y mtr          # AlmaLinux

제대로 실행하기

mtr -rwbc 200 <destination>
  • -r 보고 모드, 붙여넣을 수 있는 결과로 종료됨
  • -w 넓은 출력, 긴 호스트 이름도 잘림 없이 표시
  • -b 각 홉의 이름과 주소 표시
  • -c 200 200회 반복, 약 3분 30초, 증거와 일화의 차이

패킷 10개로는 아무것도 증명할 수 없습니다. 10회 실행에서 손실이 보이면, 결론을 내리기 전에 200회 실행하십시오.

마지막 홉부터 읽기

라우터는 자신에게 보내진 패킷의 우선순위를 낮춥니다. 수백 기가비트를 처리하는 전송 라우터는 만료된 TTL 프로브에 여유가 있을 때만 응답하고, 바쁠 때는 버립니다. 이로 인해 실제로 중요한 패킷은 모두 정상 도착하는데 보고서 중간에 손실로 표시될 수 있습니다.

대부분의 보고서에는 두 가지 규칙이 적용됩니다:

  1. 7번 홉에서 손실이 보이지만 8번 이후 홉에서는 없으면 속도 제한입니다. 무시하십시오.
  2. 7번 홉에서 시작해 목적지까지 계속 손실이 있으면 실제 손실이며, 손실이 시작된 홉을 조사하십시오.

지연 시간도 마찬가지입니다. 80밀리초를 추가한 후 다음 홉에 이전 수치로 전달하는 홉은 전달이 느린 것이 아니라 응답이 느린 것입니다.

ICMP는 사용자 트래픽이 아님

서비스가 TCP에서 실행된다면 TCP로 테스트하십시오:

mtr -rwbc 200 --tcp --port 443 <destination>

ICMP를 엄격히 제한하는 네트워크도 TCP는 그대로 통과시키는 경우가 많습니다. 반대의 경우, 즉 ping에는 응답하면서 사용자가 실제로 접속하는 포트는 차단하는 방화벽이 있는지 확인할 가치가 있습니다.

매번 양방향으로

라우팅은 비대칭인 경우가 많습니다. 우리 쪽에서 클라이언트로의 경로는 클라이언트에서 우리 쪽으로의 경로와 다르며, 한쪽 끝의 보고서는 그중 하나만 설명합니다. 인스턴스에서 클라이언트 방향으로, 클라이언트에서 인스턴스 방향으로 MTR을 실행하고 둘 다 첨부하십시오. 우리 경로의 절반은 셸 없이도 루킹 글라스에서 확인할 수 있습니다.

TCP 카운터로 교차 검증

MTR은 경로를 설명합니다. 소켓 통계는 그 결과를 설명합니다:

ss -ti state established
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

깨끗해야 할 연결에서 재전송률이 1% 이상이면 보고서를 뒷받침합니다. 손실로 가득한 MTR과 함께 재전송이 0이면 속도 제한 외에 다른 것이 아님을 의미합니다.

보내실 내용

  • MTR 보고서 2개, 200회 실행, 스크린샷이 아닌 텍스트로
  • 목적지, 전송 프로토콜, 포트
  • 시간대가 포함된 타임스탬프, 손실이 지속적인지 버스트인지 여부
  • 인스턴스 ID

이중 약 절반은 중간 홉의 속도 제한으로 확인되며, 첫 응답에서 알려드립니다. 나머지는 보통 1시간 내에 우회할 수 있습니다: 우리 네트워크 내부 손실은 우리 책임이고, 하나의 전송 경로에서 손실이 발생하면 트래픽을 다른 경로로 이동하면 됩니다.

준비 완료

도시를 고르고, 크기를 고르고, 코인으로 결제하세요.

신원 확인 양식도, 승인을 기다리는 담당자도, 검증을 위한 전화도 없습니다. 청구서가 결제되면 자격 증명이 받은 편지함에 도착합니다.