[ ICMP ] Ping 의 첫번째 패킷이 실패하는 경우, .!!!!, request time out

핑의 첫번째 패킷이 항상 실패하는 경우 | 첫번째 핑이 실패하는 이유

우리가 장비 설정 후 ping 통신을 통해 상대방의 장비와 연결 상태를 확인 하다보면

첫번째 ping 이 실패하는 경우가 있다. 그 이유에 대해서 설명하겠습니다.

Router#ping 10.0.0.100 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds: .!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 9/13/24 ms

PC>ping 172.16.0.100   Pinging 172.16.0.100 with 32 bytes of data:   Request timed out. Reply from 172.16.0.100: bytes=32 time=21ms TTL=125 Reply from 172.16.0.100: bytes=32 time=13ms TTL=125 Reply from 172.16.0.100: bytes=32 time=13ms TTL=125   Ping statistics for 172.16.0.100:     Packets: Sent = 4, Received = 3, Lost = 1 (25% loss), Approximate round trip times in milli-seconds:     Minimum = 13ms, Maximum = 21ms, Average = 15ms

 

1. ARP 캐시가 비어 있는 경우

- 송신 시스템의 ARP 캐시에 목적지 시스템을 나타내는 엔트리가 없다면, 목적지 장비의 하드웨어 주소를 파악하는데 걸리는 시간이 핑 클라이언트에 정의된 시간 제한을 초과 할 수 있다. 또 ICMP Echo Request 메시지의 크기가 로컬 시스템의 MTU보다 크면, 핑은 첫번째 조각을 자신의 Call-Back 큐로부터 삭제하여 첫번째 데이터그램의 두번째 이후 조각만을 전송할 수도 있다. 이런 경우 IP 패킷이 완전하지 않으므로 목적지 시스템은 그 패킷을 무시한다.

 

2. 라우팅 캐시가 피어 있는 경우

- 오늘날 인터넷은 수백만 개의 네트웍크로 구성되어 있으며, 라우터 대부분이 다른 모든 라우터를 추적할 수 없다. 실제로 대부분의 라우터는 항상 자신의 캐시에 몇 개의 라우팅 경로만을 지정한다. 이런 경우에 패킷이 최근에 전송된 적이 없는 네트웍크로 보내진다면, 라우터가 패킷을 따라야할 올바른 네트웍크 경로를 정하는 데에 다소 시간이 걸릴 수 있다. 따라서, ICMP Echo Request질의 메시지가 성공적으로 응답되기 이전에 핑 클라이언트의 제한 시간이 초과될 수도 있다. 이런 경우, 핑은 처음 몇 개의 메시지를 분실된 것으로 표시할 수도 있다.

 

3. DNS네임 캐시가 비어 있을 경우

- 핑의 인자로 호스트명을 사용한다면 DNS 탐색 작업으로 인하여 일부 메시지가 지연될 수 있으며, 처리 도중 큐에서 사라지거나 "시간 초과"로 잘못 보고될 수도 있다. 따라서 네트웍크를 조사할 때, 항상 IP주소를 사용하여 이름 변환작업이 시스템 검사에 방해되지 않도록 해야 한다.

 

# ICMP 트래픽을 차단하는  방화벽

- 웹 서버에 핑을 한다고 하자, Http를 사용하여 웹 서버에 접속할 수는 있어도 핑을 사용하면 아무런 응답도 얻지 못할 수 있다. 이런 경우 ICMP Echo Request메시지가 원격 네트웍크로 보내지지만 원격 네트웍크의 방화벽이 모든 ICMP 메시지를 차단하는 것일 수 있다. 이런 경우 ICMP 메시지는 방화벽에 의해 소멸되며 아무런 ICMP메시지도 응답되지 않는다.

원격 방화벽에서 Destination Unreachable에러 메시지를 전송한다면 문제의 원인을 쉽게 파악할 수 있다. 그러나 이런 메시지를 전송하는 것이 보안에 위배된다고 생각하여 방화벽에서 메시지를 전송하지 않도록 설정하는 경우가 많다. 이런 경우 송신 시스템은 아무런 메시지도 수신하지 못하게 된다.

 

# 설정이 잘못된 라우팅 테이블

- 송신 시스템의 데이터그램이 원격 목적지에 전송되고, 이에 응답하는 데이터그램이 다시 송신 시스템으로 전송된다. 하지만 잘못된 경로를 통해 송신 시스템의 네트웍크로 보내지는 경우도 있다. 이런 문제는 송신 시스템의 네트웍크가 잘못된 경로를 가리키는 경로로 통지되는 경우에 발생한다.

이런 문제는 새로운 또는 최근에 변경된 네트웍크에서 흔하게 찾아 볼 수 있다. 새로운 네트웍크에 이르는 경로를 정의하는 것을 잊어 버릴 수도 있다. 데이터그램이 돌아 올 때, 반드시 전송되었던 경로와 같은 경로로 되돌아 오는 것은 아니다.

 

# 많은 양의 Redirect 에러 메시지

- 일부 네트웍크는 많은 양의 ICMP Redirect 에러 메시지를 생성하는 것으로 알려져 있다.

일반적으로 이것은 호스트와 라우터의 서브넷 마스크가 잘못 설정된 경우 또는 호스트를 설정하기 위해 Router Discovery에 심하게 의존하는 경우 발생한다

1. Router Discovery

- 네트웍 장비는 Router Solicitation 질의 메시지에 응답한 라우터 가운데 가장 가중치가 높은 오직 하나의 라우터를 기본 라우터로 사용한다. 이런 모델에서 호스트는 특정 목적지 시스템을 위해 더 적합한 라우터를 통보 받지 않는 한 로컬이 아닌 모든 데이터그램을 전송하는 데 기본 라우터를 사용한다. 그러므로 네트웍크에 여러 개의 라우터가 있다면, 호스트가 여러 라우터와 그 라우터에서 지원하는 경로를 알게됨에 따라 여러개의 ICMP Redirect에러 메시지를 수신하게 된다.

만약 잘못된 라우터에 가장 높은 가중치 값을 부여했다면, 다른 라우터에 더 높은 우선 순위를 부여함으로써 네트웍크의 ICMP Redirect에러 메시지의 수를 줄일 수 있다. 또 다른 방법은 라우터를 집중시켜 하나의 라우터에서만 로컬 세그먼트를 취급하도록 하는 것이다. 이런 경우 모든 트래픽은 남겨진 한 라우터만을 통과하며, 로컬 세그먼트의 모든 ICMP Redirect 트래픽은 없어진다.

2. 잘못 설정된 서브네 마스크

- 네트워크에 잘못 설정된 서브네 마스크를 가진 호스트가 존재하면, ICMP Redirect에러 메시지가 대량으로 생성된다. 이런 로컬 네트웍크의 다른 시스템과 연결을 시도하는 경우 호스트는 목적지 시스템이 다른 네트웍크에 존재하는 것으로 오인하여 데이터그램을 로컬 라우터에 보내게 돈다. 그런 경우, 라우터는 송신 시스템에게 목적지 시스템이 로컬에 존재한다는 것을 Redirect에러 메지지를 통해 알린다.

이 문제를 해결하는 최선의 방법은 네트웍크 장비에 올바른 서브넷 마스크를 부여하여 장비들이 라우터를 거치지 않고 직접 통신 할 수 있게 하는 것이다.

[첫번째 핑이 실패하는 경우, Request timed out.]