YoutubePing·tracert 사용법과 결과 해석, 네트워크 장애 찾는 순서
요약
Ping·tracert는 ICMP 메시지로 상대 장비와 통신이 되는지, 그리고 어느 구간에서 끊기는지 확인하는 기본 네트워크 진단 명령어입니다.
센서·게이트웨이·서버 사이의 통신이 끊겼을 때 원인이 케이블인지, 주소 설정인지, 중간 장비인지 범위를 좁히는 첫 도구로 씁니다.
이 글에서는 Windows 기준 ping 기본값(4회 전송, 32바이트, 응답 대기 4,000ms)과 tracert 기본값(최대 30홉)을 정리하고 결과 메시지별 의미와 현장 점검 순서를 예시로 설명합니다.
모니터링 화면에서 센서 하나가 갑자기 "통신 끊김"으로 바뀌면 현장 담당자가 먼저 궁금한 것은 센서 고장인지 네트워크 문제인지입니다. 장비를 뜯어 보기 전에 노트북 한 대로 ping을 쳐 보면 대부분 몇 분 안에 문제 구간이 드러납니다.
그런데 ping 결과를 잘못 읽어 엉뚱한 곳을 고치는 일도 많습니다. "요청 시간이 만료되었습니다"가 나왔다고 해서 상대 장비가 꺼졌다고 단정할 수는 없고 tracert에 별표(*)가 줄줄이 찍혀도 실제 통신은 정상일 수 있습니다. 아래에서 명령어가 어떻게 동작하는지부터 결과를 읽는 법과 현장에서 확인하는 순서까지 차례로 다룹니다.
1. Ping·tracert란?
Ping은 상대 장비에 ICMP(Internet Control Message Protocol) 에코 요청을 보내고 에코 응답이 돌아오는지, 왕복에 몇 ms가 걸리는지 보여 주는 명령어입니다. 응답이 오면 내 PC에서 상대 장비까지 IP 수준의 통신이 된다는 뜻입니다.
tracert(trace route)는 목적지까지 가는 길에 거치는 라우터를 한 단계씩 보여 주는 명령어입니다. Windows에서는 tracert, 리눅스·맥에서는 traceroute라는 이름을 씁니다. ping이 "닿는가"를 묻는다면 tracert는 "어디까지 닿는가"를 알려 줍니다.
2. Ping과 tracert는 어떻게 동작할까?
2-1. Ping의 동작: ICMP 에코 요청과 응답
Ping은 ICMP 타입 8(에코 요청)을 보내고 상대가 타입 0(에코 응답)으로 돌려주기를 기다립니다. 정해진 시간 안에 응답이 없으면 시간 만료로 표시하고 중간 라우터가 길을 찾지 못하면 타입 3(목적지 도달 불가) 메시지가 돌아옵니다.
2-2. tracert의 동작: TTL을 1씩 늘리기
IP 패킷에는 TTL(Time To Live)이라는 숫자가 있고 라우터를 하나 지날 때마다 1 이상 줄어듭니다. TTL이 0이 되면 라우터는 패킷을 버리고 보낸 쪽에 ICMP 타입 11(시간 초과)을 돌려줍니다. tracert는 이 규칙을 이용해 TTL 1, 2, 3… 순서로 패킷을 보내고 돌아온 시간 초과 메시지의 주소를 모아 경로를 그립니다. 홉마다 3번씩 보내므로 결과에 시간 값이 세 칸씩 나옵니다.
| ICMP 타입 | 이름 | 진단에서 뜻하는 것 |
|---|---|---|
| 8 | 에코 요청 (Echo) | ping·tracert가 보내는 패킷 |
| 0 | 에코 응답 (Echo Reply) | 목적지까지 정상 도달 |
| 3 | 목적지 도달 불가 (Destination Unreachable) | 코드 0 네트워크, 1 호스트, 3 포트 도달 불가, 4 분할 필요(DF 설정됨) |
| 11 | 시간 초과 (Time Exceeded) | 코드 0은 전송 중 TTL 만료, tracert가 경로를 찾는 근거 |
3. 현장에서 자주 쓰는 ping·tracert 옵션은?
Windows 명령 프롬프트(cmd) 기준으로 정리했습니다. 옵션은 "-" 또는 "/" 어느 쪽으로 써도 됩니다.
| 명령 | 기능 | 기본값·사용 예 |
|---|---|---|
| ping -t | 멈출 때까지 계속 전송 | Ctrl+Break로 중간 통계, Ctrl+C로 종료. 간헐 끊김 관찰용 |
| ping -n 횟수 | 보낼 횟수 지정 | 기본 4회. 손실률을 볼 때는 -n 100 |
| ping -l 크기 | 데이터 크기(바이트) | 기본 32, 최대 65,500 |
| ping -f | 분할 금지(DF) 설정 | IPv4 전용. -l과 함께 MTU 문제 확인 |
| ping -w ms | 응답 대기 시간 | 기본 4,000ms |
| ping -a | IP를 이름으로 역조회 | 어떤 장비인지 이름 확인 |
| tracert -d | 이름 조회 생략 | 결과가 빨리 나옴. 사내망에서는 거의 항상 붙임 |
| tracert -h 홉수 | 최대 홉 수 | 기본 30홉 |
| tracert -w ms | 홉별 응답 대기 | 기본 4,000ms. 응답 없으면 * 표시 |
| pathping | 경로 + 홉별 손실률 | 홉마다 100회, 250ms 간격 전송 |
4. Ping 결과는 어떻게 읽을까?
같은 사내망의 게이트웨이(192.168.0.50)에 ping을 보냈을 때 정상이라면 "192.168.0.50의 응답: 바이트=32 시간<1ms TTL=64" 같은 줄이 4번 나오고 마지막에 "보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실)" 통계가 붙습니다. 같은 스위치 안의 유선 장비라면 응답 시간은 보통 1ms 안팎이고 수십 ms가 나오거나 값이 크게 출렁이면 무선 구간이나 과부하를 의심합니다.
응답 줄의 TTL 값으로 상대 장비의 종류를 짐작할 수도 있습니다. Windows의 기본 TTL은 128이고 리눅스 계열은 보통 64에서 시작하므로, 같은 망에서 TTL=128이 보이면 Windows PC, TTL=64면 리눅스 기반 장비일 가능성이 큽니다. 같은 IP에서 평소와 다른 TTL이 나오면 IP가 다른 장비와 겹친 것은 아닌지 확인해 볼 만합니다.
| 결과 메시지 | 의미 | 먼저 볼 곳 |
|---|---|---|
| 응답: 시간=xx ms | 정상 통신 | 통신은 되므로 포트·프로그램 설정 쪽 확인 |
| 요청 시간이 만료되었습니다 (Request timed out) | 대기 시간 안에 응답 없음 | 장비 전원, 상대 방화벽의 ICMP 차단, 경로 중간 차단 |
| 대상 호스트에 연결할 수 없습니다 (Destination host unreachable) | 경로나 상대 장비를 찾지 못함 | 응답 주소가 내 PC면 같은 망에서 상대가 안 보이는 것, 라우터면 그 뒤 경로 |
| 전송하는 동안 TTL이 만료되었습니다 (TTL expired in transit) | 라우터를 지나다 TTL이 0이 됨 | 라우팅 루프 가능성, tracert로 반복되는 주소 확인 |
| 일반 오류 (General failure) | 내 PC에서 패킷을 내보내지 못함 | 내 PC 랜카드·케이블·IP 설정, 보안 프로그램 |
"대상 호스트에 연결할 수 없습니다"가 내 PC 주소에서 돌아오는 경우는 따로 기억해 둘 만합니다. Windows는 이 응답을 통계에서 받음으로 집계해 손실 0%로 보일 수 있으니 통계 숫자만 보고 정상으로 판단하면 안 됩니다. 이 경우 같은 망 안에서 상대 장비를 찾지 못한 것이므로 상대 장비 전원과 케이블, 그리고 내 PC와 상대 장비가 같은 망 주소인지부터 봅니다. 같은 망을 판단하는 계산은 서브넷 마스크와 게이트웨이, 같은 망 계산법 글에 정리되어 있습니다.
5. tracert 결과는 어떻게 읽을까?
사무실 PC(192.168.10.20)에서 공장동 모니터링 서버(192.168.30.5)까지 tracert -d를 실행한 예입니다. 첫 칸은 홉 번호, 가운데 세 칸은 세 번 보낸 패킷의 왕복 시간, 마지막 칸은 응답한 장비 주소입니다.
| 홉 | 1회 | 2회 | 3회 | 주소 |
|---|---|---|---|---|
| 1 | <1 ms | <1 ms | <1 ms | 192.168.10.1 (사무동 게이트웨이) |
| 2 | 1 ms | 1 ms | 1 ms | 10.0.0.2 (코어 스위치) |
| 3 | * | * | * | 요청 시간이 만료되었습니다. |
| 4 | * | * | * | 요청 시간이 만료되었습니다. |
2홉까지는 응답하고 3홉부터 끝까지 별표만 나온다면 코어 스위치 다음 구간, 즉 공장동 게이트웨이(192.168.30.1)로 가는 링크나 그 장비 자체를 먼저 봅니다. 마지막으로 응답한 홉의 다음 구간이 의심 구간이라고 기억하면 됩니다.
반대로 중간 홉 하나만 별표이고 그 뒤 홉과 목적지가 정상 응답하면 장애가 아닙니다. 보안 설정이나 장비 정책 때문에 시간 초과 메시지를 돌려주지 않는 라우터가 있어서 그 홉만 보이지 않는 것입니다. 특정 홉의 시간만 수백 ms로 튀고 다음 홉은 다시 낮아지는 경우도 그 라우터가 ICMP 응답을 낮은 우선순위로 처리한 결과일 때가 많아 목적지 응답 시간이 정상이라면 크게 신경 쓰지 않아도 됩니다.
6. 손실률·MTU·소요 시간은 어떻게 계산할까?
6-1. 패킷 손실률
기본 4회 ping으로는 간헐적인 끊김을 잡기 어렵습니다. ping -n 100 192.168.30.5 를 실행해 "보냄 = 100, 받음 = 97"이 나왔다면 손실률은 (100 − 97) ÷ 100 × 100 = 3%입니다. 같은 스위치 안의 유선 구간에서 손실이 반복해서 보인다면 케이블 접촉이나 포트 불량을 먼저 의심합니다.
6-2. MTU 확인 (ping -f -l)
작은 ping은 되는데 큰 데이터 전송만 실패하면 경로의 MTU(Maximum Transmission Unit)를 의심합니다. 이더넷의 일반적인 MTU 1,500바이트에서 IP 헤더 20바이트와 ICMP 헤더 8바이트를 빼면 1,500 − 20 − 8 = 1,472바이트입니다. ping -f -l 1472 대상주소 가 성공하고 1473에서 "패킷을 조각화해야 하지만 DF가 설정되어 있습니다" 같은 메시지가 나오면 그 경로의 MTU는 1,500바이트입니다. 1472가 실패하면 크기를 줄여 가며 성공하는 최대값을 찾고 거기에 28을 더하면 실제 경로 MTU가 나옵니다.
6-3. 명령이 끝나는 데 걸리는 시간
tracert는 응답이 없는 홉에서 패킷 3개마다 기본 4,000ms를 기다리므로 홉 하나에 최대 12초가 걸립니다. 목적지까지 응답이 전혀 없으면 30홉 × 12초 = 360초, 6분 가까이 기다려야 하므로 사내망에서는 tracert -d -h 10 -w 1000 처럼 범위를 줄여 쓰는 편이 낫습니다. pathping은 홉마다 100회를 250ms 간격으로 보내므로 5홉 경로라면 100 × 0.25초 × 5 = 125초 동안 통계를 모읍니다.
| 계산 | 식 | 예시 결과 |
|---|---|---|
| 손실률 | (보냄 − 받음) ÷ 보냄 × 100 | (100 − 97) ÷ 100 × 100 = 3% |
| ping 최대 데이터 크기 | MTU − IP 헤더 20 − ICMP 헤더 8 | 1,500 − 28 = 1,472바이트 |
| tracert 최대 대기 | 최대 홉 × 3회 × 대기 시간 | 30 × 3 × 4초 = 360초 |
| pathping 통계 시간 | 횟수 × 간격 × 홉 수 | 100 × 0.25초 × 5 = 125초 |
7. 센서 통신이 끊겼을 때 현장 점검 순서는?
네트워크 장애는 가까운 곳부터 먼 곳으로 한 구간씩 확인하면 빨리 찾습니다. 아래 순서는 센서 게이트웨이나 데이터로거가 사내망을 거쳐 모니터링 서버로 데이터를 보내는 구성을 기준으로 했습니다.
그림 1. 가까운 곳부터 ping을 보내고 처음으로 응답이 끊기는 구간을 점검합니다.
그림 1은 점검을 내 PC에서 시작해 게이트웨이, 현장 장비, 서버 순서로 넓혀 가는 흐름입니다. 단계마다 응답이 오면 다음 단계로 넘어가고 처음으로 응답이 끊기는 단계의 구간을 집중해서 봅니다.
- 내 PC 확인 : ipconfig로 내 IP·서브넷 마스크·기본 게이트웨이를 확인하고 ping 127.0.0.1로 PC 자체의 TCP/IP가 정상인지 봅니다.
- 기본 게이트웨이 ping : 실패하면 내 PC의 케이블·스위치 포트·IP 설정 문제입니다.
- 현장 장비 IP ping : 게이트웨이나 데이터로거 주소로 ping -n 20을 보냅니다. 같은 망인데 실패하면 장비 전원, 랜 케이블, 장비 IP 설정을 봅니다.
- 서버 IP ping : 현장 장비가 데이터를 보내는 서버 주소까지 닿는지 확인합니다.
- tracert -d : 다른 망을 거치는데 실패하면 마지막으로 응답한 홉을 찾아 그 다음 구간 장비를 점검합니다.
- 이름(도메인) 확인 : IP로는 되는데 서버 이름으로 ping이 안 되면 DNS나 hosts 설정 문제입니다.
- ping -t 장시간 관찰과 기록 : 간헐적 끊김은 10~30분 이상 켜 두고 끊긴 시각을 모니터링 시스템의 수집 누락 시각과 맞춰 봅니다.
ping이 정상인데도 데이터가 안 들어온다면 네트워크 경로는 살아 있는 것이니 포트 번호, 통신 프로토콜 설정, 방화벽의 포트 허용 여부로 넘어갑니다. Modbus 장비라면 Modbus 통신 오류 해결 방법 글의 타임아웃·예외 코드 점검으로 이어 가면 됩니다. 점검 결과는 날짜·시각·명령어·결과를 그대로 남겨 두어야 같은 증상이 다시 생겼을 때 비교할 수 있습니다.
8. 자주 생기는 문제와 해결 방법
| 증상 | 흔한 원인 | 해결 |
|---|---|---|
| 장비는 켜져 있는데 ping만 시간 만료 | 장비나 PC 방화벽이 ICMP 에코 요청 차단 | 장비 웹 화면 접속이나 해당 포트 연결로 확인. PC라면 방화벽 인바운드 규칙 확인 |
| 수십 번에 한두 번씩 시간 만료 | 케이블 접촉 불량, 포트 불량, 무선 간섭 | ping -t로 관찰하며 케이블·포트를 하나씩 바꿔 봄 |
| 응답이 왔다 안 왔다 하고 TTL 값이 바뀜 | 같은 IP를 두 장비가 사용 (IP 충돌) | arp -a로 MAC 주소 확인, 고정 IP 목록 정리 |
| 작은 ping은 되고 큰 전송만 실패 | VPN·터널 구간의 MTU 축소 | ping -f -l로 경로 MTU 확인 후 장비 MTU 조정 |
| 100m가 넘는 구간 장비만 불안정 | 랜 케이블 거리 초과·등급 부족 | 케이블 등급과 길이 점검, 필요하면 광 구간으로 교체 |
케이블 문제로 보일 때는 랜 케이블 CAT5e·CAT6·CAT6A 차이 글에서 등급별 거리 기준을 함께 확인하면 좋습니다. 고정 IP를 쓰는 산업 장비가 많은 현장이라면 DHCP vs 고정 IP 차이 글처럼 주소 대장을 따로 관리해 두면 IP 충돌을 줄일 수 있습니다.
9. 관련 산업용어
■ ICMP
IP 네트워크에서 오류와 상태를 알리는 제어 메시지 규약입니다. ping과 tracert가 모두 ICMP 메시지를 이용합니다.
■ TTL (Time To Live)
IP 패킷이 지날 수 있는 라우터 수의 한도입니다. 라우터를 지날 때마다 줄어들고 0이 되면 패킷이 버려집니다.
■ 홉 (Hop)
패킷이 라우터 하나를 지나가는 한 단계입니다. tracert 결과의 줄 번호가 홉 번호입니다.
■ RTT (Round Trip Time)
패킷이 상대에게 갔다가 돌아오기까지 걸린 왕복 시간입니다. ping 결과의 "시간=" 값으로 RTT를 확인합니다.
■ MTU (Maximum Transmission Unit)
한 번에 보낼 수 있는 최대 패킷 크기입니다. 일반 이더넷은 1,500바이트를 씁니다.
10. 자주 묻는 질문
Q. ping은 되는데 프로그램 통신이 안 되면 무엇이 문제인가요?
네트워크 경로보다 포트·프로토콜 설정 쪽 문제일 가능성이 큽니다. ping은 ICMP만 확인하므로 방화벽에서 해당 포트가 막혀 있거나 장비의 통신 설정이 다르면 ping이 되어도 데이터는 오지 않습니다.
Q. ping이 안 되면 장비가 꺼진 건가요?
아닐 수도 있습니다. 보안 설정으로 ping에 응답하지 않는 PC나 장비가 있으므로 웹 화면 접속이나 해당 포트 연결로 한 번 더 확인합니다.
Q. tracert 결과에 별표(*)만 나오는 홉은 장애인가요?
뒤 홉과 목적지가 정상 응답하면 장애가 아닙니다. 시간 초과 메시지를 돌려주지 않는 라우터는 tracert에서 별표로만 보입니다.
Q. 사내망 ping 응답 시간은 몇 ms가 정상인가요?
같은 스위치 안의 유선 장비는 보통 1ms 안팎입니다. 무선이나 여러 장비를 거치는 구간은 더 길어질 수 있으므로 평소 값을 기록해 두고 그 값과 비교하는 편이 정확합니다.
Q. ping -t는 어떻게 멈추나요?
Ctrl+C를 누르면 멈추고 통계가 나옵니다. 멈추지 않고 중간 통계만 보려면 Ctrl+Break를 누릅니다.
11. 마무리
Ping은 상대에게 닿는지를, tracert는 어느 구간까지 닿는지를 보여 줍니다. 점검은 내 PC, 게이트웨이, 현장 장비, 서버 순서로 가까운 곳부터 넓혀 가고 처음으로 응답이 끊기는 구간이 점검 대상입니다. ping 실패가 곧 장비 고장은 아니며 ICMP 차단이나 응답하지 않는 라우터 때문일 수 있으니 다른 방법으로 한 번 더 확인합니다. 평소 정상일 때의 응답 시간과 경로를 기록해 두면 장애가 났을 때 비교 기준이 됩니다.
참고 기준 : IETF RFC 792 「Internet Control Message Protocol」(1981), Microsoft Learn Windows Commands 「ping」「tracert」「pathping」 문서
태그 : Ping, tracert, 핑테스트, traceroute, ICMP, TTL, pathping, 패킷손실, 응답시간, 네트워크장애, 요청시간만료, 대상호스트연결불가, MTU, 기본게이트웨이, 산업용네트워크
- 다음글Wi-Fi 2.4GHz 5GHz 차이와 산업 현장 IoT 센서 선택 기준 26.11.13