ICMP
Internet Control Message Protocol · 인터넷 제어 메시지 프로토콜
는 IP 전달 과정의 오류나 상태를 알리는 인터넷 계층 제어 메시지다. 의 와 의 ICMPv6는 번호·필요 기능이 다르며 모든 메시지가 오류인 것은 아니다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- Echo 요청·응답으로 특정 크기의 패킷이 왕복하는지 관찰한다.
- TTL 만료·목적지 도달 불가를 원래 패킷의 일부와 함께 송신자에게 알린다.
- Fragmentation Needed 또는 정보로 경로 조정을 돕는다.
02어떤 순서로 동작하나
- TTL 1 전송
첫 probe를 TTL=1로 보낸다. 첫 라우터가 TTL을 소모해 폐기하고 를 보낼 수 있다.
- 첫 홉 기록
송신자는 오류 응답과 원래 probe를 연결해 응답 주소·왕복 시간을 기록한다. 응답이 없으면 제한 시간 후 미응답으로 표시한다.
- TTL을 늘려 반복
TTL을 2, 3으로 늘리면 더 먼 라우터에서 만료된다. 각 TTL의 probe와 응답을 별도로 대응시킨다.
- 목적지 응답 판정
선택한 probe 방식의 최종 응답을 받으면 목적지 도달을 판정한다. 중간 응답과 목적지의 응용 서비스 성공은 별도다.
03먼저 알아둘 용어와 구성요소
- Echo·처럼 메시지 대분류를 정한다.
- 같은 안에서 포트 부재·단편화 필요 등 세부 원인을 구분한다.
- 오류를 유발한 원래 IP 헤더와 데이터 일부로 실패한 흐름을 찾는 근거다.
- Echo 응답을 원래 탐색과 짝 짓는 식별자이며 포트가 아니다.
- 대상에게 응답을 요청하는 질의 메시지다. ping은 주로 이를 이용해 왕복 도달성을 관측한다.
- 에 대한 응답 메시지다. 응용 서비스의 정상 동작을 증명하지는 않는다.
- 전달 중 TTL 또는 Hop Limit 소진 등으로 생긴 시간 초과를 알리는 오류다.
- 패킷을 목적지로 전달할 수 없는 이유를 로 알리는 오류다.
- 다음 링크의 보다 커서 패킷을 전달할 수 없음을 알리는 ICMPv6 메시지다.
- 메시지의 종류와 구체적인 이유를 구분하는 필드 쌍이다.
- 패킷의 TTL 또는 Hop Limit을 단계적으로 늘리고 돌아오는 오류·응답으로 경유 지점을 추정하는 진단 방식이다.
실습: ping 0/5와 라우팅 테이블 함께 읽기
Echo 응답 부재를 호스트 다운으로 단정하지 않고 목적지 경로부터 검증한다.
실습 구성과 전제
- R1이 10.128.0.2로 Echo를 보내는 자료다. 화면에는 다른 10 대역의 Connected·Static 경로가 있다.
- 표 일부만으로 전체 기본 경로까지 확정하지 않는다. 재현에서는 목적지별 조회도 남긴다.
목적지 포함 여부 계산
- 10.128.0.2는 10.128.0.0/14에 속한다. 표의 10.192.0.0/14와 10.200.0.0/15는 같은 10으로 시작해도 목적지를 포함하지 않는다.
- 최장 일치는 실제 목적지를 포함하는 후보들끼리 비교한다.
textshow ip route 10.128.0.2 show ip route실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗- Connected와 Static 경로가 섞여 있다.
- 사진에 나열된 프리픽스에는 10.128.0.0/14가 보이지 않는다.
확인 기준목적지별 조회가 선택한 경로 또는 경로 없음 상태를 확인한다.
실패 출력의 관찰 사실 기록
- 100바이트 Echo 5개를 보내고 0/5로 끝났다. 점 표시는 시간 안에 응답을 얻지 못했다는 결과다.
- 이 결과만으로 목적지 도착·차단·반환 경로 중 무엇이 원인인지 확정할 수 없다. 먼저 로컬 을 확인한다.
textping 10.128.0.2실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗- do ping 10.128.0.2와 Sending 5, 100-byte ICMP Echos가 보인다.
- Success rate is 0 percent (0/5)로 끝난다.
확인 기준대상과 실패율을 기록하고 다른 대상의 성공으로 대신하지 않는다.
경로 수정 후 동일 조건으로 재시험
- 실습 기록은 목표 프리픽스를 등록한 뒤 ping 성공을 확인한다. 정확한 next hop은 연결 구성에서 선택하며 사진에 없는 주소를 만들어 넣지 않는다.
- 같은 목적지 경로·인터페이스·ping을 재조회한다. 다른 설정까지 동시에 바꾸면 성공 원인을 한 조치에 귀속하기 어렵다.
textshow ip route 10.128.0.2 show ip interface brief ping 10.128.0.2구성에 맞게 경로를 등록한 뒤 반복하는 검증
확인 기준새 경로와 왕복 Echo를 확인한다. 사진에 없는 성공 횟수는 결과로 꾸미지 않는다.
실습에서 확인한 동작 원리
- ping 실패는 원인이 아니라 결과다. 경로·주소 해석·차단·반환을 나누어 본다.
- 같은 목적지의 변경 전후를 비교해야 조치 효과를 설명할 수 있다.
동작·명령 참고 문서
실습: 정적 경로 한 줄과 실제 경로 추적 연결
Connected·Static·기본 경로를 구별하고 목적지 전달 및 반환 경로를 검증한다.
실습 구성과 전제
- R2 경로표는 10.0.5.0/24·10.0.8.0/24의 직접 연결과 여러 를 보여 준다.
- 사진은 별도 다중 라우터 연습이다. R2 표의 동일 경로를 찍은 것으로 합치지 않는다.
R2가 직접 아는 망과 배운 망 분리
- C 10.0.5.0은 직접 연결, S 10.0.2.0 [1/0] via 10.0.5.1은 정적 경로다. 대괄호의 1은 AD, 0은 이 의 metric 표시다.
- Gateway of last resort is not set이므로 더 구체적인 경로에 해당하지 않는 목적지를 기본 경로로 넘길 수 없다.
textshow ip route show ip route 10.0.2.1실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗- C 10.0.8.0·10.0.5.0과 S 10.0.2.0·10.0.6.0·10.0.7.0이 보인다.
- Gateway of last resort is not set이 명시된다.
확인 기준C를 수동 정적 등록으로 읽지 않고 S와 구분한다.
정적 경로와 next hop 도달성 검증
- 목적지 프리픽스가 10.0.2.0/24이면 next hop 10.0.5.1로 전달한다. 이 next hop은 직접 연결된 10.0.5.0/24로 해석된다.
- 설정이 있어도 인터페이스 상태·next hop 도달성·반환 경로가 틀리면 실제 응답은 없을 수 있다.
textip route 10.0.2.0 255.255.255.0 10.0.5.1 end show ip route 10.0.2.1 ping 10.0.5.1표에 보이는 경로를 재구성한 설정과 검증
확인 기준명령 저장 여부와 선택·실제 전달을 따로 확인한다.
별도 traceroute의 완료·무응답 해석
- VPCS의 trace는 TTL을 달리하며 중간 응답을 모은다. 마지막에는 목적지 10.44.0.2에서 3 3이 반환된다. probe 방식에서 목적지 포트 도달의 단서다.
- 7번째 줄의 별표는 그 probe에 시간 내 응답이 없다는 뜻이다. 뒤 목적지 응답이 있으므로 그 홉부터 무조건 완전히 단절되었다는 해석은 맞지 않는다.
textPC1> trace 10.44.0.2별도 경로 추적 화면과 같은 VPCS 명령
원본 크기로 보기 ↗- 7번째 홉에는 별표가 있고 뒤 10.44.0.2 응답이 있다.
- 마지막에 ICMP type:3, code:3, Destination port unreachable이 보인다.
확인 기준trace의 probe 방식과 코드를 확인한다. 반환 경로가 왕복 대칭이라는 보장은 없다.
실습에서 확인한 동작 원리
- 의 존재와 next hop 해석·실제 왕복은 다른 검증이다.
- 별표와 포트 도달 응답을 프로브 방식에 맞춰 읽는다.
up/up 뒤에도 ping이 실패한 기록을 단계별로 진단하기
인터페이스 활성화 전후의 실제 실패 기록을 읽고 링크 상태·직접 연결 경로··최종 성공 원인을 분리한다.
실습 구성과 전제
- R1 FastEthernet0/0은 10.5.128.2/22이고 연결 상대는 10.5.128.1/22이다. 같은 /22에 속하므로 정상 connected 경로가 있으면 기본 경로를 사용할 대상이 아니다.
- 구성도에는 내부 서버망 10.5.132.0/22와 R2 연결망 10.5.136.0/22도 있다. 이번 진단 범위는 R1에서 바로 연결된 10.5.128.1까지로 제한한다.
주소 계획에서 같은 망인지 계산한다
- /22의 마스크는 255.255.252.0이고 세 번째 옥텟의 블록 크기는 4다. 10.5.128.1과 .2는 10.5.128.0~10.5.131.255 범위에 함께 들어간다.
- 목적지가 직접 연결된 이웃이므로 R1은 올바른 인터페이스로 를 통해 상대 MAC을 알아낼 수 있어야 한다. 내부 다른 LAN과 문제를 처음부터 섞지 않는다.
원본 크기로 보기 ↗- R1의 f0/0에 10.5.128.2/22, 위쪽 연결 상대에 10.5.128.1/22가 표시된다.
- R1 e2/0의 10.5.132.1/22 서버망과 e2/1의 10.5.136.1/22 R2 연결망은 별도로 그려져 있다.
확인 기준출발지 인터페이스·목적지·마스크를 고정한다. 이름이나 이전·이후 주소를 바꾸어 가며 다른 시험을 같은 결과로 비교하지 않는다.
administratively down을 먼저 해결한다
- 실행 기록에서는 주소를 입력한 뒤 ping 0/5가 반복되고 show ip interface brief에 administratively down/down이 나온다. IP 설정은 인터페이스 활성화 명령을 대신하지 않는다.
- 해당 인터페이스에 no shutdown을 적용한 뒤 LINK와 LINEPROTO up 로그가 나타났다. 이 변경이 해결한 것은 관리적 비활성 상태다.
textshow ip interface brief configure terminal interface FastEthernet0/0 no shutdown end show ip interface brief ping 10.5.128.1실제 실패 기록의 핵심 명령을 사건 순서대로 정리했다.
확인 기준상태가 up/up으로 바뀌었는지 확인한 뒤 동일 출발지·목적지로 시험한다. no shutdown 입력 사실만으로 복구되었다고 적지 않는다.
up/up 뒤의 0/5를 별도 실패로 다룬다
- 기록에는 up/up 뒤에도 Success rate is 0 percent (0/5)가 나온다. 따라서 링크 활성화만으로 통신을 복구했다고 볼 수 없다.
- 이 시점에는 connected 경로, 응답, 상대 주소·마스크, 가상 연결과 필터를 확인해야 한다. 기본 경로를 추가하기 전에 10.5.128.1에 대한 조회가 직접 연결 경로를 선택하는지 본다.
textshow ip route 10.5.128.1 show arp show interfaces FastEthernet0/0 ping 10.5.128.1 source 10.5.128.2실패 시 추가하면 유용한 관찰 명령. 이 출력이 원 기록에 존재하는 것처럼 제시하지 않는다.
확인 기준다음 조회는 원인을 좁히기 위한 재구성이다. 해당 · 출력이 기록에 없으므로 특정 단계가 실제 원인이었다고 확정하지 않는다.
성공 기록은 보존하고 인과관계는 제한한다
- 뒤에는 5/5 성공과 RTT min/avg/max 16/56/84 ms가 남아 있다. 그러나 그 사이 상대 장비와 연결 상태가 모두 기록되지 않아 최종 해결 원인을 하나로 확정할 수 없다.
- 기본 경로를 넣은 직후에도 0/5가 한 번 더 기록되어 있다. 같은 망의 이웃 접근을 기본 경로 추가로 해결했다고 설명하면 실제 사건 순서와 원리를 모두 놓친다.
text관찰 순서 1. FastEthernet0/0: administratively down / down 2. no shutdown → LINK·LINEPROTO up 3. ping: 0/5 4. 기본 경로 추가 뒤에도 ping: 0/5 5. 이후 별도 시험: 5/5, RTT 16/56/84 ms원 실행 기록의 상태·결과를 요약했다. 3~5 사이의 모든 외부 변경이 기록된 것은 아니다.
확인 기준보고서에는 최초 상태, 변경, 바로 뒤의 실패, 나중 성공을 각각 기록한다. 최종 성공만 남기거나 미기록 원인을 채워 넣지 않는다.
실습에서 확인한 동작 원리
- up/up은 연결의 필요 조건이며 IP 이웃 도달 가능성과 같은 뜻이 아니다.
- 시간상 앞선 설정과 나중 성공을 연결하려면 같은 시험 조건과 추가 증거가 필요하다.
04예제로 따라가기
- 헤더 20바이트, Echo 헤더 8바이트, Echo 데이터 1472바이트를 DF=1로 보낸다고 하자. 전체 IP 크기는 1500바이트다. 출구 가 1400인 라우터는 이 패킷을 그대로 내보낼 수 없고 DF 때문에 단편화도 할 수 없다. 원래 패킷을 버리고 =3, =4 오류를 보낼 수 있다.
- 오류의 Next-Hop =1400을 읽고 인용된 원래 주소·식별자·프로토콜이 내 탐색 패킷과 맞는지 확인한다. 다른 흐름의 오류를 이번 탐색 결과로 섞지 않는다. 같은 · 헤더 조건이면 Echo 데이터 한계는 1400−20−8=1372바이트다. 1373바이트는 IP 길이 1401이므로 같은 경로·DF 조건에서 한계를 넘는다.
- 큰 패킷이 실패하고 작은 패킷이 성공해도 =4를 못 받았다면 는 후보일 뿐이다. 크기별 정책·수집 손실을 구분하고 경로 변화가 없는 조건에서 재현성을 본다.
05혼동하기 쉬운 점과 확인 기준
- TTL 만료를 보고한 라우터까지 원래 탐색이 도달했고 오류가 돌아왔다는 증거다. 그 라우터가 이후 모든 트래픽을 처리하지 못한다는 의미는 아니다.
- 대상 호스트 또는 정책 장비가 해당 포트를 사용할 수 없다고 응답한 상황과 연결된다. 응답 주체와 인용된 프로토콜을 확인하며 RST와 같은 패킷으로 취급하지 않는다.
- Echo 응답 정책과 실제 서비스 정책은 다를 수 있다. ping 실패만으로 443 서비스까지 단절됐다고 결론내리지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.