[Network] 24. ping이 실패하면 정말 서버가 죽은 것일까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

서비스에 접속되지 않을 때 가장 먼저 떠올리는 명령이 있다.

ping server.example

응답이 오면 “Network는 정상”이라고 말하고, 응답이 없으면 “Server가 죽었다”고 말하기 쉽다.

하지만 ping이 묻는 질문은 그보다 좁다.

이 Destination을 향한 ICMP Echo Request가 전달되고
누군가 Echo Reply를 만들며
그 Reply가 다시 이 Host까지 돌아올 수 있는가?

HTTP Port가 열려 있는지, TLS Certificate가 유효한지, Application이 요청을 처리할 수 있는지는 묻지 않는다.

반대로 Echo Reply가 없다고 Destination Host가 반드시 꺼져 있는 것도 아니다.

Firewall이 ICMP만 차단하거나 Reply의 Return Path가 끊겼을 수 있다.

진단 도구의 결과를 정확히 쓰려면 “무엇을 증명했는가?”와 “무엇은 아직 모르는가?”를 함께 적어야 한다.

 

이번 글에서는

ICMP Echo Request/Reply, Identifier, Sequence Number, Round-Trip Time(RTT), Packet Loss, TTL/Hop Limit, Destination Unreachable을 따라가며 ping의 관찰 범위를 정리한다.

---

ㅁ ping은 어느 Protocol로 대화할까?

일반적인 ping은 Internet Control Message Protocol(ICMP)의 Echo Message를 사용한다.

IPv4에서는 다음 Type과 Code를 사용한다.

Echo Request
Type 8, Code 0

Echo Reply
Type 0, Code 0

 

IPv6에서는 ICMPv6의 Type이 다르다.

ICMPv6 Echo Request
Type 128, Code 0

ICMPv6 Echo Reply
Type 129, Code 0

 

TCP나 UDP처럼 Destination Port를 지정하지 않는다.

ping 198.51.100.20:443  (X)

 

ping은 Host의 특정 Web Service가 아니라 IP 계층의 ICMP 응답 가능성을 관찰한다.

---

ㅁ Echo Message에는 무엇이 들어 있을까?

ICMP Echo Message의 대표적인 Field는 다음과 같다.

Type
Code
Checksum
Identifier
Sequence Number
Data

ㅇ Identifier

한 Host에서 여러 ping Process가 동시에 실행될 때 Request와 Reply를 구분하는 단서로 사용할 수 있다.

운영체제와 구현에 따라 Process ID나 별도 값에서 정할 수 있지만 항상 Process ID와 같다고 단정할 수는 없다.

 

ㅇ Sequence Number

각 Echo Request의 순서를 표시한다.

icmp_seq=1
icmp_seq=2
icmp_seq=3

어느 Request의 Reply가 사라졌거나 순서가 바뀌었는지 확인하는 데 도움이 된다.

TCP Sequence Number처럼 Byte Stream의 위치를 나타내는 번호는 아니다.

 

ㅇ Data

크기와 Pattern을 조절할 수 있는 Payload다. 일부 구현은 전송 시각을 넣어 RTT 계산에 사용할 수 있다.

 

ㅇ Checksum

전송 오류를 탐지한다. 공격자가 다시 계산할 수 있으므로 TLS 같은 암호학적 Integrity나 상대 Authentication을 제공하지 않는다.

---

ㅁ Hostname을 ping하면 ICMP부터 보낼까?

ping server.example처럼 이름을 사용하면 먼저 이름을 IP Address로 바꿔야 한다.

1. Resolver가 server.example 조회
2. A 또는 AAAA Address 선택
3. 선택한 Address로 ICMP Echo Request 전송

 

DNS가 실패하면 Echo Request 자체를 한 번도 보내지 못한다.

ping: unknown host
ping: cannot resolve

이 결과는 Destination이 ICMP에 응답하지 않았다는 뜻이 아니다.

Hostname ping 실패
→ DNS 단계 또는 Address 선택 문제 가능

IP Address ping 성공
→ ICMP 경로는 되지만 이름 조회 문제 가능

진단할 때 이름과 IP를 나누어 시험하는 이유다.

dig server.example
ping 198.51.100.20
ping server.example

명령과 Option은 운영체제에 따라 다를 수 있다.

---

ㅁ Echo Request가 나가기 전에도 여러 단계가 필요하다

Destination Address를 알았다고 Packet이 즉시 Wire로 나가는 것은 아니다.

Host는 다음 과정을 거친다.

Destination이 같은 Subnet인가?
        ↓
Routing Table에서 Route 선택
        ↓
Outgoing Interface와 Next Hop 결정
        ↓
ARP 또는 NDP로 Next-Hop Link Address 확인
        ↓
ICMP Echo Request를 Frame에 실어 전송

 

따라서 ping 실패는 Destination Host 하나만의 문제가 아닐 수 있다.

• Local Interface가 Down
• Address나 Subnet Mask 오류
• Route 없음
• Default Gateway 오류
• ARP/NDP 실패
• Local Firewall의 Outbound Drop
• Network Namespace나 VRF를 잘못 선택

Echo Request가 Local Host를 실제로 떠났는지 Capture로 확인해야 원격 Host를 의심할 근거가 생긴다.

---

ㅁ Echo Reply가 오려면 어떤 길이 완성되어야 할까?

Echo Request는 Forward Path를 지나 Destination에 도착한다.

Destination IP Stack이 Echo Reply를 만들면 Reply는 Return Path를 따라 돌아온다.

Source
  │ Echo Request
  ▼
Forward Path
  │
  ▼
Destination
  │ Echo Reply
  ▼
Return Path
  │
  ▼
Source

Forward Path가 정상이어도 Return Route가 없으면 Source는 Reply를 받지 못한다.

Request는 Destination 도착
Reply는 Return Path에서 Drop
Source에서 본 결과: Timeout

한쪽에서 응답이 없다는 사실만으로 어느 방향이 끊겼는지 알 수 없다.

양 Endpoint와 중간 지점의 Capture가 필요한 이유다.

---

ㅁ ping 성공은 정확히 무엇을 증명할까?

ping Reply 하나를 받았다면 최소한 다음 사실의 증거가 생긴다.

선택한 Source에서 Echo Request를 보낼 수 있었다.
Request가 해당 Address에 응답하는 지점까지 도달했다.
그 지점이 Echo Reply를 생성했다.
Reply가 Source까지 돌아왔다.
해당 시점의 ICMP 왕복이 완료됐다.

 

그러나 다음까지 증명하지는 않는다.

TCP 443이 열려 있다.
TLS Handshake가 성공한다.
Certificate가 유효하다.
HTTP가 200을 응답한다.
Database와 Dependency가 정상이다.
사용자 요청의 업무 처리가 성공한다.
다음 Packet도 반드시 같은 경로로 성공한다.

ping 성공은 ICMP Reachability의 긍정적인 증거이지 모든 Layer의 Health Check가 아니다.

---

ㅁ 누가 Echo Reply를 보냈는지도 항상 단순할까?

Destination IP가 하나의 물리 Server만을 가리킨다고 보장할 수 없다.

• Anycast Address를 여러 지점이 광고할 수 있다.
• Load Balancer나 Network Appliance가 Address를 소유할 수 있다.
• High Availability 전환으로 응답 장비가 바뀔 수 있다.
• NAT와 Tunnel 때문에 실제 Application Server와 ICMP 응답 지점이 다를 수 있다.

VIP가 ping에 응답
≠ 뒤의 모든 Backend가 정상

Echo Reply의 Source IP와 Capture 위치, 실제 Service Architecture를 함께 확인해야 한다.

ICMP Echo 자체에는 TLS Certificate 같은 암호학적 상대 인증이 없다.

공격자가 Packet을 위조할 수 있는 환경에서는 Reply를 받았다는 사실만으로 응답 주체의 강한 Identity까지 증명하지 못한다.

---

ㅁ ping 실패는 무엇을 의미할까?

Echo Reply를 받지 못했다면 다음 중 하나 이상일 수 있다.

Echo Request를 보내지 못함
Echo Request가 Forward Path에서 Drop
Destination이 Echo Request를 무시
Destination가 Down
Echo Reply가 Return Path에서 Drop
ICMP가 Rate Limit
응답이 Timeout보다 늦게 도착
Packet 크기가 Path MTU 문제를 만남

ping 실패가 증명하는 것은 좁다.

정해진 시간과 조건 안에서 기대한 Echo Reply를 관찰하지 못했다.

“Server Down”은 가능한 가설 중 하나일 뿐이다.

---

ㅁ Firewall이 ICMP만 막을 수 있을까?

Firewall은 Protocol과 ICMP Type별로 다른 Policy를 적용할 수 있다.

TCP 443                 ALLOW
ICMP Echo Request       DROP
ICMP Fragmentation Needed ALLOW
ICMP Time Exceeded      Rate Limit

이 환경에서는 HTTPS가 정상이어도 ping은 실패할 수 있다.

ping 실패
curl 성공

 

반대로 ICMP Echo를 허용하고 TCP 443을 차단할 수도 있다.

ping 성공
curl Timeout

 

“ICMP 허용 여부”와 “Application Service 허용 여부”는 별도의 Firewall Rule이다.

---

ㅁ ICMP를 모두 막는 것이 안전할까?

ICMP에는 Echo 외에도 IP 전달에 필요한 오류와 제어 메시지가 있다.

Destination Unreachable
Fragmentation Needed
Time Exceeded
Parameter Problem

 

IPv6에서는 Neighbor Discovery와 Packet Too Big 같은 ICMPv6 기능이 정상 동작에 중요하다.

Echo Request에 응답하지 않겠다는 Policy와 모든 ICMP를 Drop하는 Policy는 다르다.

ICMP Echo를 제한
≠ ICMP 전체를 차단

Type, Code, Direction, Rate와 관련 Connection State를 기준으로 필요한 Control Traffic을 구분해야 한다.

---

ㅁ ping 출력의 한 줄은 무엇을 뜻할까?

Linux 계열의 설명용 출력은 다음처럼 보일 수 있다.

64 bytes from 198.51.100.20: icmp_seq=1 ttl=52 time=18.4 ms

 

각 항목을 나누어 보자.

64 bytes
→ 구현이 보고한 ICMP Message 크기

from 198.51.100.20
→ Echo Reply의 Source Address

icmp_seq=1
→ 어느 Echo Request에 대한 Reply인지 나타내는 Sequence

ttl=52
→ Reply가 Source에 도착했을 때 남은 IPv4 TTL

time=18.4 ms
→ Request 전송부터 Reply 수신까지 측정한 RTT

 

출력 형식과 Byte 계산은 구현마다 다르다.

예를 들어 Linux의 일반적인 기본값에서 ICMP Data 56바이트에 ICMP Header 8바이트를 더해 64 bytes라고 표시할 수 있고, IPv4 Header 20바이트까지 포함한 IP Packet은 84바이트가 될 수 있다.

ICMP Data   56
ICMP Header  8
IPv4 Header 20
----------------
IP Total    84

 

Ethernet Frame 전체 크기는 여기에 Link Layer Header와 Trailer가 더 필요하다.

---

ㅁ RTT는 어디까지의 시간일까?

Round-Trip Time(RTT)은 Source에서 Request를 보내고 Reply를 받을 때까지의 왕복 시간이다.

RTT
= Forward Path 전송과 Queue 대기
+ Destination 처리 시간
+ Return Path 전송과 Queue 대기
+ 양 Endpoint의 Scheduling 영향

 

RTT 20ms라고 Forward와 Return이 각각 10ms였다고 단정할 수 없다.

Forward  3ms + Return 17ms = RTT 20ms
Forward 15ms + Return  5ms = RTT 20ms

 

일반 ping의 RTT만으로 One-Way Delay와 어느 방향의 지연인지 분리할 수 없다.

One-Way Delay를 정확히 비교하려면 양 Endpoint의 Clock Synchronization과 별도 측정 설계가 필요하다.

---

ㅁ 첫 번째 Reply만 느리면 Network가 불안정할까?

명령 실행 후 첫 결과가 나오기 전에는 다음 준비가 추가로 필요할 수 있다.

• DNS Cache Miss
• ARP 또는 NDP Neighbor Resolution
• Route와 Neighbor Cache 생성
• 무선 절전 상태 해제
• 방화벽이나 Tunnel의 초기 State 생성

DNS Resolution 시간은 일반적으로 각 Echo Reply 줄의 time=으로 표시되는 ICMP RTT에 포함되지 않지만,

사용자가 명령을 실행한 뒤 첫 결과를 보기까지의 시간에는 영향을 준다.

첫 Echo Request 자체는 ARP/NDP와 State 준비 때문에 대기할 수 있으며

정확히 어느 시간이 RTT에 포함되는지는 구현과 측정 지점에 따라 확인해야 한다.

이후 Packet은 이미 만들어진 Cache와 State를 사용할 수 있어 더 빨라질 수 있다.

icmp_seq=1 time=25 ms
icmp_seq=2 time=3 ms
icmp_seq=3 time=3 ms

첫 값 하나만으로 지속적인 Network 지연이라고 결론 내리지 않는다.

반대로 첫 Packet을 항상 버리고 나머지만 평균 내면 실제 사용자가 겪는 Connection Setup 비용을 놓칠 수 있다.

측정 목적에 따라 Cold Start와 Steady State를 구분한다.

---

ㅁ Packet Loss는 어떻게 계산할까?

ping은 보낸 Echo Request 수와 받은 Echo Reply 수로 Loss 비율을 계산한다.

5 packets transmitted
4 packets received

Packet Loss = (5 - 4) ÷ 5 × 100
            = 20%

이 결과는 보낸 ICMP Echo Sample 중 Reply를 받지 못한 비율이다.

같은 시간의 TCP Application Packet도 정확히 20% 손실되었다는 뜻은 아니다.

Router와 Host는 Control Plane 보호를 위해 ICMP Echo를 Rate Limit하거나 낮은 우선순위로 처리할 수 있다.

ICMP Echo Loss 20%
TCP Service Traffic 정상

가능한 장면이다.

반대로 ICMP는 잘 통과하지만 특정 Queue, DSCP Class, Tunnel 또는

큰 Packet에서 Application Traffic만 손실될 수도 있다.

---

ㅁ 평균 RTT만 보면 충분할까?

설명용 통계가 다음과 같다고 하자.

min/avg/max/mdev = 10.1/20.0/80.2/15.4 ms

• min: 관찰한 Sample 중 가장 작은 RTT
• avg: 산술 평균 RTT
• max: 가장 큰 RTT
• mdev 또는 stddev: RTT 변동 폭을 나타내는 통계

평균이 같아도 사용자 경험은 다를 수 있다.

경로 A: 19, 20, 21ms
경로 B: 5, 5, 50ms

평균은 비슷할 수 있지만 변동성은 다름

실시간 음성과 Game은 평균 RTT뿐 아니라 변동, 흔히 Jitter라고 부르는 현상과 Loss에 민감하다.

다만 ping 출력의 mdev와 Application이 정의하는 Jitter 지표가 항상 같은 계산은 아니다.

Sample 수와 간격, 크기, 시간대를 함께 기록해야 비교가 의미 있다.

---

ㅁ Reply의 TTL로 Router 수를 정확히 알 수 있을까?

출력의 ttl=52는 Reply가 Source에 도착했을 때 남은 TTL이다.

Destination이 처음 설정한 Initial TTL을 알면 지나온 Hop 수를 추정할 수 있다.

가정한 Initial TTL 64
- 도착 TTL 52
= 약 12 Hop

그러나 Initial TTL은 운영체제와 설정에 따라 64, 128, 255 등 다를 수 있다.

중간 Tunnel과 장비가 TTL 처리에 영향을 줄 수도 있다.

도착 TTL만 알고 Initial TTL은 모름
→ 정확한 Hop 수를 확정할 수 없음

TTL 값으로 운영체제나 경로 길이를 추측할 수는 있지만 확정적인 Identity 증명으로 사용하면 안 된다.

각 Hop을 관찰하려는 질문은 다음 글의 traceroute가 더 직접적으로 다룬다.

---

ㅁ Sequence가 빠지거나 순서가 바뀌면 무엇을 볼까?

다음 Reply를 받았다고 하자.

icmp_seq=1
icmp_seq=3
icmp_seq=2

2번이 늦게 도착해 Reply 순서가 바뀌었다.

가능한 원인은 다음과 같다.

• ECMP나 경로 변화
• 서로 다른 Queue 지연
• Wireless 재전송
• Endpoint Scheduling

같은 Sequence의 Reply가 여러 번 오면 Duplicate Packet이나 중복 응답일 수 있다.

한 번의 Reordering만으로 Routing Loop나 심각한 장애를 단정하지 않는다.

Capture에서 IP ID, ICMP Identifier, Sequence, 시간과 경로 변화를 함께 본다.

---

ㅁ Timeout과 Unreachable은 같은 실패일까?

응답이 전혀 없으면 ping은 Timeout처럼 보일 수 있다.

Request timeout

이는 Request 또는 Reply가 사라졌다는 뜻일 뿐 Drop 위치와 이유를 알려 주지 않는다.

반면 Host나 Router가 명시적인 ICMP 오류를 돌려줄 수도 있다.

Destination Network Unreachable
Destination Host Unreachable
Communication Administratively Prohibited

오류 문장만 보지 말고 누가 ICMP 오류를 보냈는지 확인한다.

Local Host가 Network Unreachable 생성
→ Local Route 문제 가능

First-Hop Router가 Host Unreachable 생성
→ 다음 Hop의 ARP 실패나 Route 문제 가능

중간 Firewall이 Administratively Prohibited 생성
→ 해당 정책 지점에서 거절 가능

ICMP 오류도 잘못 생성되거나 중간에서 바뀌고 차단될 수 있으므로 Source Address와 인용된 원래 Packet을 확인한다.

명시적인 오류는 Silent Timeout보다 원인 범위를 줄이는 강한 단서지만 최종 판결은 아니다.

---

ㅁ Destination Host Unreachable이면 Destination이 답했을까?

이 문장은 실제 Destination Host가 보냈다는 뜻이 아닐 수 있다.

같은 Subnet의 Destination MAC Address를 찾지 못한 Source가 오류를 만들 수도 있고,

중간 Router가 다음 Hop으로 전달하지 못해 만들 수도 있다.

From 10.22.1.1 Destination Host Unreachable

이 경우 10.22.1.1이 오류 생성 지점이라는 단서다.

원래 ping 대상과 오류 메시지의 Source를 구분해서 읽어야 한다.

---

ㅁ IPv4와 IPv6 중 어느 쪽을 시험했을까?

Hostname에 A와 AAAA Record가 모두 있으면

ping 구현과 운영체제 정책에 따라 IPv4 또는 IPv6 Address를 선택할 수 있다.

IPv4 ping 성공
IPv6 ping 실패

또는

IPv6 ping 성공
IPv4 ping 실패

한쪽 결과로 Dual-Stack 전체를 판단하면 안 된다.

환경에 따라 다음처럼 Address Family를 명시할 수 있다.

ping -4 server.example
ping -6 server.example

일부 운영체제는 ping6 같은 별도 명령을 사용하며 Option이 다를 수 있다.

IPv6 Link-Local Address는 어느 Interface의 Scope인지 함께 지정해야 할 수 있다.

fe80::1%eth0

같은 Address 문자열이라도 Source Address, Interface와 Network Namespace가 다르면 경로가 달라진다.

---

ㅁ Source Address를 바꾸면 결과가 달라질까?

Interface가 여러 개인 Host는 Destination Route에 따라 Source Address와 Outgoing Interface를 선택한다.

Firewall, Policy Routing과 Return Route는 선택한 Source에 따라 다르게 동작할 수 있다.

Source 10.0.0.10 → 성공
Source 192.168.0.10 → Return Route 없어 실패

Linux 계열에서는 환경에 따라 -I로 Interface나 Source Address를 지정할 수 있다.

ping -I eth0 198.51.100.20
ping -I 10.0.0.10 198.51.100.20

권한과 Option은 구현마다 다르다.

Container, Pod, VRF와 Network Namespace 안에서 발생한 장애라면

Host Shell이 아니라 실제 Traffic이 시작되는 Network Context에서 시험해야 한다.

Host에서 ping 성공
≠ Container에서도 같은 Route와 Policy로 성공

---

ㅁ 작은 ping은 되는데 큰 ping만 실패할 수 있을까?

Echo Data 크기를 늘리면 IP Packet 전체 크기도 커진다.

Ethernet MTU 1500, IPv4 Header 20바이트, ICMP Header 8바이트를 가정하면 다음과 같다.

ping Data 1472
+ ICMP Header 8
+ IPv4 Header 20
= IP Packet 1500

DF가 설정된 1501바이트 Packet은 PMTU 1500 경로에서 전달되지 못한다.

기본 크기 ping 성공
큰 DF ping 실패
→ Path MTU와 ICMP Fragmentation Needed 경로 조사

Linux의 설명용 명령은 다음과 같다.

ping -M do -c 2 -s 1472 198.51.100.20

-M과 -s의 의미는 운영체제마다 다르므로 해당 시스템의 Manual을 확인한다.

큰 Ping 실패가 곧 일반적인 작은 TCP Segment 실패는 아니지만 MTU Black Hole 가설을 시험하는 단서가 된다.

---

ㅁ ping이 느리면 Application도 같은 만큼 느릴까?

ICMP RTT는 Network 지연의 한 Sample이다.

Application 응답 시간에는 더 많은 단계가 포함된다.

DNS Resolution
+ TCP/QUIC Handshake
+ TLS Handshake
+ Request 전송
+ Server Queue와 업무 처리
+ Database와 외부 API
+ Response 전송
= 사용자가 느끼는 전체 시간

반대로 Network 장비가 ICMP를 낮은 우선순위로 처리하면

ping RTT만 높고 Application Traffic은 정상일 수 있다.

Service Latency를 측정하려면 실제 Protocol과 요청을 사용해야 한다.

curl -v --connect-timeout 3 https://server.example/
openssl s_client -connect server.example:443 -servername server.example

ICMP와 Application 측정을 경쟁시키는 것이 아니라 서로 다른 계층의 증거로 조합한다.

---

ㅁ 어디부터 ping해야 할까?

무작정 먼 Destination부터 시험하기보다 범위를 단계적으로 넓힌다.

 

ㅇ 1. Loopback

ping 127.0.0.1

Local IP Stack의 기본 동작을 본다. 성공해도 NIC와 외부 Network는 지나지 않았다.

 

ㅇ 2. 자신의 Interface Address

ping 10.22.1.2

Local Address 설정을 확인한다. 이 역시 Packet이 실제 Link를 왕복했다고 보장하지 않는다.

 

ㅇ 3. 같은 Link의 Default Gateway

ping 10.22.1.1

Local Interface, VLAN, ARP/NDP와 첫 Hop까지의 단서를 얻는다. Gateway가 Echo를 차단하면 실패할 수 있다.

 

ㅇ 4. Remote Address

ping 198.51.100.20

Routing된 ICMP 왕복을 시험한다.

 

ㅇ 5. Hostname

ping server.example

DNS Resolution과 선택된 Address까지 포함해 비교한다.

 

각 단계의 성공과 실패 경계가 원인 범위를 줄인다.

다만 중간 장비가 ICMP를 차단하면 그 경계가 실제 Data Path 장애 위치와 같지는 않을 수 있다.

---

ㅁ Service 상태는 무엇으로 확인할까?

ICMP 다음에는 실제 Service와 같은 Protocol을 시험한다.

질문: TCP Port가 열려 있는가?
도구: nc, telnet, TCP SYN 관찰

질문: TLS가 성공하는가?
도구: openssl s_client, curl -v

질문: HTTP가 정상 응답하는가?
도구: curl, Application Health Endpoint

질문: 업무 기능이 정상인가?
도구: 실제 Transaction과 Server Log

Linux와 macOS의 nc Option은 구현마다 다르지만 다음처럼 TCP 연결을 시험할 수 있다.

nc -v -w 3 198.51.100.20 443

TCP 연결 성공은 TLS와 HTTP 성공을 보장하지 않는다. 계층마다 다음 질문으로 한 단계씩 올라간다.

---

ㅁ 진단 결과를 어떻게 문장으로 써야 할까?

좋지 않은 결론은 관찰보다 범위가 넓다.

ping 실패
→ Server Down이다.  (근거 부족)

 

증거 범위에 맞는 문장은 다음과 같다.

10:30부터 10:35까지 Client A에서 198.51.100.20으로
IPv4 ICMP Echo Request 20개를 보냈지만 Echo Reply를 받지 못했다.
같은 시각 TCP 443 연결은 성공했다.
따라서 Host 전체 장애보다 ICMP Policy 또는 Echo 처리 차이를 우선 조사한다.

 

또 다른 예시다.

ICMP Echo Reply는 RTT 3ms로 돌아왔다.
TCP 443 SYN에는 응답이 없었다.
따라서 IP/ICMP 왕복 경로는 확인했지만 TCP 443 Policy와 Service 상태는 미확인이다.

도구 이름이 아니라 Source, Destination, Address Family, Protocol, 시간과 관찰 결과를 기록한다.

---

ㅁ Monitoring에서 ping 하나만 사용하면 무엇을 놓칠까?

ICMP Monitor는 가볍고 많은 Host의 기본 Reachability와 RTT 변화를 보기 좋다.

하지만 다음 장애를 놓칠 수 있다.

• Web Process Down
• TLS Certificate 만료
• Database Dependency 장애
• 특정 API의 권한 또는 업무 오류
• 큰 Response에서만 발생하는 MTU 문제
• DNS가 잘못된 Address를 반환하는 문제

반대로 Echo Rate Limit 때문에 Service가 정상인데 ICMP Monitor만 Alarm을 낼 수도 있다.

ICMP Check
+ TCP Port Check
+ TLS Certificate Check
+ HTTP Health Check
+ 실제 업무 Synthetic Transaction

여러 Layer의 Monitor를 조합하고 각 Alarm이 의미하는 범위를 분리한다.

---

ㅁ ping을 많이 보내면 더 정확해질까?

Sample이 늘면 일시적인 변동과 지속적인 현상을 구분하는 데 도움이 된다.

그러나 높은 빈도와 큰 Payload로 무제한 Probe를 보내면 Network와 Destination의 Control Plane에 부담을 준다.

ping -f 같은 Flood Option은 권한이 필요할 수 있으며 운영 Network와 허가받지 않은 Host에서 사용하면 안 된다.

관찰 목적에 맞는 간격, 횟수, Payload를 사용한다.

진단 목적: 짧은 구간에서 제한된 Sample
Monitoring : 합의된 주기와 Rate Limit
Load Test  : 별도 승인과 전용 도구

ICMP Rate Limit이 있는 환경에서는 Probe 빈도를 높일수록 오히려 인위적인 Loss를 만들 수 있다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Message와 관찰 범위로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
답장을 요청하는 빈 엽서	ICMP Echo Request	IPv4 Type 8 또는 ICMPv6 Type 128의 도달성 Probe
받은 엽서를 되돌려 보냄	ICMP Echo Reply	IPv4 Type 0 또는 ICMPv6 Type 129의 응답
여러 시험 엽서를 구분하는 접수표	Identifier	같은 ping Session의 Request와 Reply를 연결하는 단서
몇 번째 시험인지 적은 번호	ICMP Sequence Number	Loss, Reordering과 Duplicate Reply를 구분
보내고 답장을 받기까지 걸린 시간	RTT	Forward와 Return Path를 합친 왕복 시간
보냈지만 돌아오지 않은 엽서 비율	Packet Loss	관찰한 Echo Sample 중 Reply가 없던 비율
답장에 남은 중계 횟수	Reply TTL / Hop Limit	Reply가 Source에 도착했을 때 남은 수명 값
배달할 수 없다는 반송 안내	ICMP Destination Unreachable	Host나 Router가 전달 실패 이유를 알리는 오류
답장을 하지 않는 접수 정책	ICMP Filtering / Rate Limiting	Service 상태와 무관하게 Echo 응답을 제한할 수 있음
작은 엽서는 되지만 큰 엽서는 실패	Path MTU 문제	Packet 크기에 따라 전달 결과가 달라짐

 

ping 결과의 논리적 범위를 한 그림으로 모으면 다음과 같다.

Echo Reply 수신
        ↓
해당 Source·Destination·Address Family에서
그 시점의 ICMP 왕복은 확인
        ↓
TCP Port, TLS, HTTP, 업무 Health는 별도 확인

Echo Reply 미수신
        ↓
정해진 조건에서 Reply를 관찰하지 못함
        ↓
Local 전송, Forward Path, ICMP Policy,
Destination, Return Path 중 어디인지는 추가 증거 필요

---

ㅁ Packet Capture에서 직접 확인해 보기

IPv4 Echo Message를 보는 Wireshark Display Filter는 다음과 같다.

icmp.type == 8 || icmp.type == 0

 

ICMPv6 Echo는 다음과 같다.

icmpv6.type == 128 || icmpv6.type == 129

 

Command Line에서는 Interface를 지정해 관찰할 수 있다.

sudo tcpdump -n -vv -i eth0 'icmp or icmp6'

 

다음 Field를 비교한다.

Source / Destination IP
ICMP Type / Code
Identifier
Sequence Number
IPv4 TTL 또는 IPv6 Hop Limit
Packet Length
Request와 Reply의 Timestamp 차이

Source에서 Request만 보이고 Reply가 없다면

Source가 Packet을 보냈다는 증거는 생겼지만 Destination 도착 여부는 아직 모른다.

Destination Capture에서 Request가 보이면 Forward Path는 좁혀지고,

Reply도 보냈는데 Source에 없으면 Return Path를 조사한다.

---

ㅁ 격리된 Linux 환경에서 두 반례를 만들어 보기

다음 실습은 ip, iptables, tcpdump, python3, curl이 있는 개인 Linux VM에서 수행한다.

실제 Host Firewall이 아니라 새 Network Namespace 안에서만 ICMP를 차단한다.

ping-client                ping-router               ping-server
10.24.1.2 ────────── 10.24.1.1 | 198.51.100.1 ──── 198.51.100.2

 

Namespace와 가상 Link를 만든다.

sudo ip netns add ping-client
sudo ip netns add ping-router
sudo ip netns add ping-server

sudo ip link add veth-pc type veth peer name veth-pri
sudo ip link add veth-pro type veth peer name veth-ps

sudo ip link set veth-pc netns ping-client
sudo ip link set veth-pri netns ping-router
sudo ip link set veth-pro netns ping-router
sudo ip link set veth-ps netns ping-server

 

Address와 Interface를 설정한다.

sudo ip -n ping-client addr add 10.24.1.2/24 dev veth-pc
sudo ip -n ping-router addr add 10.24.1.1/24 dev veth-pri
sudo ip -n ping-router addr add 198.51.100.1/24 dev veth-pro
sudo ip -n ping-server addr add 198.51.100.2/24 dev veth-ps

sudo ip -n ping-client link set lo up
sudo ip -n ping-router link set lo up
sudo ip -n ping-server link set lo up
sudo ip -n ping-client link set veth-pc up
sudo ip -n ping-router link set veth-pri up
sudo ip -n ping-router link set veth-pro up
sudo ip -n ping-server link set veth-ps up

 

Route와 IPv4 Forwarding을 설정한다.

sudo ip -n ping-client route add default via 10.24.1.1
sudo ip -n ping-server route add default via 198.51.100.1
sudo ip netns exec ping-router \
  sysctl -w net.ipv4.ip_forward=1

 

Router Capture Terminal에서 ICMP와 HTTP Traffic을 저장한다.

sudo ip netns exec ping-router \
  tcpdump -n -vv -i any -s 0 -w /tmp/ping-scope.pcap \
  'icmp or tcp port 8080'

 

Server Terminal에서 간단한 HTTP Server를 실행한다.

sudo ip netns exec ping-server \
  python3 -m http.server 8080 --bind 198.51.100.2

 

정상 상태에서 Client가 ICMP와 HTTP를 각각 시험한다.

sudo ip netns exec ping-client \
  ping -c 2 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

두 요청이 모두 성공하는지 확인한다.

---

ㅁ ping 실패와 Service 성공을 만들어 보기

Router가 Client에서 Server로 가는 ICMP Echo Request만 Drop하게 한다.

sudo ip netns exec ping-router \
  iptables -I FORWARD 1 \
  -i veth-pri -o veth-pro \
  -p icmp --icmp-type echo-request -j DROP

 

다시 두 명령을 실행한다.

sudo ip netns exec ping-client \
  ping -c 2 -W 1 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

 

예상 관찰은 다음과 같다.

ping: Echo Reply 없음
curl: HTTP Response 수신

 

Rule Counter를 확인한다.

sudo ip netns exec ping-router \
  iptables -L FORWARD -n -v --line-numbers

 

ICMP Drop Rule을 제거한다.

sudo ip netns exec ping-router \
  iptables -D FORWARD \
  -i veth-pri -o veth-pro \
  -p icmp --icmp-type echo-request -j DROP

---

ㅁ ping 성공과 Service 실패를 만들어 보기

Server Terminal의 python3 -m http.server를 Ctrl+C로 종료한다.

 

Client에서 다시 시험한다.

sudo ip netns exec ping-client \
  ping -c 2 198.51.100.2

sudo ip netns exec ping-client \
  curl --connect-timeout 2 http://198.51.100.2:8080/

 

예상 관찰은 다음과 같다.

ping: Echo Reply 수신
curl: TCP RST 또는 Connection Refused

Host의 IP Stack과 ICMP는 동작하지만 TCP 8080에 Listening Socket이 없기 때문이다.

Capture에서 Echo Reply와 TCP SYN 뒤의 RST를 비교한다.

실습을 마치면 Namespace를 삭제한다. 내부 Firewall Rule과 가상 Interface도 함께 제거된다.

sudo ip netns del ping-client
sudo ip netns del ping-router
sudo ip netns del ping-server

ping -W Option의 단위와 지원 여부는 구현마다 다르다. 실제 운영 Network에 ICMP 차단 Rule을 추가하지 않는다.

---

ㅁ 핵심 정리

• IPv4 ping은 ICMP Type 8 Echo Request와 Type 0 Echo Reply를 사용하고 IPv6에서는 Type 128과 129를 사용한다.
• ICMP Echo에는 Port가 없으며 Identifier와 Sequence Number로 Request와 Reply를 구분한다.
• Hostname을 ping할 때 DNS가 실패하면 Echo Request를 보내기 전 단계에서 멈춘다.
• Echo Request 전에도 Route, Outgoing Interface와 ARP/NDP Neighbor Resolution이 필요하다.
• Echo Reply는 Forward Path와 Return Path가 모두 성립하고 ICMP Policy가 허용되어야 Source에 도착한다.
• ping 성공은 해당 시점의 ICMP 왕복 증거이며 TCP Port, TLS, HTTP와 업무 처리를 보장하지 않는다.
• ping 실패는 정해진 조건에서 Reply를 보지 못했다는 뜻이며 Host Down, 경로, Firewall, Rate Limit과 Return Path가 모두 후보다.
• RTT는 양방향 지연과 처리 시간을 합친 값이므로 One-Way Delay를 직접 분리하지 못한다.
• ICMP Packet Loss와 Application Traffic의 Loss는 Policy와 Queue가 달라 같지 않을 수 있다.
• Reply TTL은 남은 값이며 Initial TTL을 모르면 정확한 Hop 수를 확정할 수 없다.
• Timeout과 명시적인 Destination Unreachable은 제공하는 정보량이 다르고 오류의 Source를 확인해야 한다.
• IPv4와 IPv6, Source Address, Interface, Namespace가 달라지면 같은 Destination도 결과가 달라질 수 있다.
• 작은 Echo와 큰 DF Echo의 결과 차이는 Path MTU 문제의 단서가 된다.
• 진단은 Loopback, Local Address, Gateway, Remote IP, Hostname과 실제 Service 순서로 증거 범위를 넓힌다.
• Monitoring은 ICMP뿐 아니라 TCP, TLS, HTTP와 업무 Transaction Check를 계층별로 조합해야 한다.

 

핵심 용어: ping, Internet Control Message Protocol, ICMP, ICMPv6, Echo Request, Echo Reply, ICMP Type 8, ICMP Type 0, ICMPv6 Type 128, ICMPv6 Type 129, Identifier, ICMP Sequence Number, Round-Trip Time, RTT, Packet Loss, Jitter, TTL, Hop Limit, Destination Unreachable, Request Timeout, ICMP Filtering, Rate Limiting, Path MTU, Source Address, Address Family

ping은 Server의 생사를 판정하는 망치가 아니다. 특정 Source에서 특정 Address로 보낸 ICMP Echo가 왕복했는지 묻는 작은 질문이다. 답이 오든 오지 않든 그 범위를 넘어선 결론에는 다른 계층의 증거가 필요하다.

---

ㅁ 다음 이야기

ping은 Destination까지의 ICMP 왕복 여부와 시간을 보여 주지만 중간에 어떤 Router를 지났는지는 알려 주지 않는다.

어느 Hop까지 Packet이 갔는지 보려면 일부러 TTL이 작은 Probe를 보내 중간 Router에서 수명을 끝내야 한다.

그런데 traceroute의 * * *는 그 Router가 고장 났다는 뜻일까?

화면에 보이는 경로는 Forward Path 그 자체일까?

 

다음 글에서는 「traceroute는 보이지 않는 길을 어떻게 보여줄까?」라는 질문을 통해

  TTL, ICMP Time Exceeded, UDP·ICMP·TCP Probe, Asymmetric Path와 Rate Limiting을 살펴본다.