안녕하세요. 소심비형입니다. 오늘은 Ping에 이어서 Tracert에 대해서 알아보겠습니다. Ping은 목적지까지 도착 시간을 알 수 있지만, Tracert는 목적지까지 찾아가는 시간 및 경로를 파악하기 위한 용도로 사용됩니다.

 

윈도우와 유닉스는 아래 명령어를 통해 확인할 수 있습니다.

• Window 계열: tracert

• Unix 계열: traceroute

 

Tracert의 timeout(*)

종종 목적지 중간 경로에 있는 장비에서 timeout현상(* 표시)이 나타날 수 있습니다. 이는 source와 destination간의 네트워크 상태를 정확히 파악할 수 있는 정보는 아닙니다. 그 이유는 아래 3가지 정도로 요약할 수 있습니다.

1. IP 장비에서는 ICMP Packet이 아닌 다른 일반적인 Packet보다 많은 시간을 할애하도록 설계된 경우가 있는데 해당 IP 장비가 매우 바쁠 경우에는 정상적인 상태일지라도 ICMP Time exceed를 전달하지 않는 경우가 있습니다.

2. 중간 경로에 있는 IP 장비가 ICMP Echo reply 또는 ICMP Time exceed를 발생하지 않는 경우로, 이런 장비들은 주로 Firewall인 경우가 많습니다. 하지만, Firewall이라고 해서 ICMP Echo reply나 ICMP Time exceed를 생성하지 않는 것은 아닙니다. 해당 장비의 관리자 설정에 따라 좌우되기 때문입니다.

3. traceroute 수행 시 중간 경로상의 timeout 현상에 대해 무시하는 경우가 많습니다. 최종 목적지와의 Ping 상태가 좋은지를 파악하는 것이 더 중요합니다.

 

아래는 Ping이 응답하지 않거나 실패하는 일반적인 요인입니다.

 

 

No Reply의 경우 AD 또는 Router 설정을 확인해야 합니다. 아래 이미지와 같이 라우터 4에서 응답을 하지 않는 경우, tracert의 4번째 요청에서 "xxx.xxx.xxx.xxx *  *  *" 응답을 받게 됩니다. 명령은 tracert speedguide.net 입니다.

 

 

가상 환경에서 집에 있는 리눅스 서버로 핑을 날려보면 한번에 도착하는 것을 알 수 있습니다.

 

 

네이버로 핑을 날려보면 상당히 많은 라우터를 거쳐서 도착하는 것을 알 수 있습니다. 중간에 패킷이 유실되는 것도 볼 수 있고, 6, 7과 같이 No Reply이거나 혹은 Can't Reply일수도 있습니다. Can't Reply는 라우터가 바빠서 ICMP ECHO REQUEST에 대해 응답을 할 수 없는 경우입니다. 단지 응답만 하지 않을뿐 기능상 문제가 발생되는건 아닙니다.

 

 

위의 3, 4와 8과 같이 Long Delay가 발생할 수도 있습니다. 위 결과를 보면 네이버까지 가는데 어느 지점에서 병목 현상이 발생하는지 파악할 수 있습니다. 3, 4에서 Delay가 증가하는 것을 볼 때 2번 라우터와 3, 4라우터간에 연결하고 있는 회선의 사용량이 많을 것이라 추측할 수 있습니다. 만약, Delay가 높게 나온다면 ICMP 처리에 대한 우선 순위가 낮게 설정되었을 가능성이 높습니다. 위의 속도를 보면 평균적으로 비슷하게 나오는 것을 알 수 있습니다. 1번이 유난히 작게 나온 이유는 집에 있는 KT 홈 허브이기 때문입니다. 이 후 부터는 외부의 라우터로 찾아가게 됩니다.

 

참고로 traceroute의 수행 상태가 늦게 보여진다면 Source에서 기본적으로 Reverse domain name을 점검하기 때문일수도 있습니다. 당연히 일반 PC에서는 아무런 효과가 없고, 서버에서 좀 더 빠른 결과를 보려면 아래 명령 옵션을 사용합니다.

• Window 계열: tracert -d ngmsoftware.com
• Linux 계열: traceroute -n ngmsoftware.com

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천3 비추천0