FTP란 무엇일까

FTP는 File Transfer Protocol의 약자로 말그대로 파일을 전송하는 통신 규약입니다. FTP 서버에 파일들을 업로드, 다운로드할 수 있도록 해주는 프로토콜이며, 이는 FTP 서버와 FTP 클라이언트 간에 통신에서 이루어집니다.

FTP는 Active 모드와 Passive 모드라는 2개의 모드가 존재하며 각각의 모드에서는 2개 또는 2개 이상의 포트가 연결을 맺고 데이터를 전송하는데 사용됩니다. 사용되는 포트는 연결을 제어하는 Command 포트가 있으며 데이터를 전송하는 DATA 포트가 있습니다.

FTP는 TCP 기반으로 만들어져 있으며 기본으로 동작 모드로 Active 모드를 사용하며 20번 또는 1024번 이후의 데이터(Data) 포트는 데이터를 전송하는데 사용하게 되고, 21번 포트는 접속시에 사용되는 명령(Command )포트입니다.

Active 모드
FTP Active 모드의 동작 방식을 그림으로 보면 아래와 같습니다. 참고로 아래 사용된 명령(Command) 포트와 데이터(Data) 포트는 서버의 설정에서 임의로 수정하여 사용할 수 있습니다.

• 1) 클라이언트는 서버의 21번 포트로 접속한 후에 자신이 사용할 두 번째 포트를 서버에 미리 알려줍니다.
• 2) 서버는 클라이언트의 요청에 응답합니다. (acks)
• 3) 서버의 20번 데이터 포트는 클라이언트가 알려준 두 번째 포트로의 접속을 시도합니다.
• 4) 클라이언트가 서버의 요청에 응답합니다. (acks)

위 과정에서 액티브 모드는 “클라이언트가 서버에 접속을 하는 것이 아닌 서버가 클라이언트에 접속을 하는 것”을 확인할 수 있습니다. 만일 FTP 클라이언트에 방화벽이 설치되어 있는 등 외부에서의 접속을 허용하지 않는 상황이라면 FTP 접속이 정상적으로 이루어지지 않을 것입니다. 접소기 되더라도 데이터 목록을 받아오지 못하게 되는 경우도 있고요.

Passive 모드

위에서 살펴본 Active 모드의 단점을 해결하기 위한 Passive 모드를 살펴봅시다. 역시나 아래 그림에서 사용된 커맨드 포트와 데이터 포트는 서버 설정에서 변경할 수 있습니다. 특히 Passive 모드에서는 데이터 포트 번호를 특별하게 지정하지 않는 경우 1024 ~ 65535번 중에서 사용 가능한 임의 포트를 사용하게 됩니다. 포트 번호를 지정할 때는 10001 ~ 10005번과 같이 범위를 지정할 수도 있습니다.

• 1) 클라이언트가 커맨드 포트로 접속을 시도합니다. (Passive 모드 연결)
• 2) 서버에서는 사용할 두 번째 포트를 클라이언트에게 알려줍니다.
• 3) 클라이언트는 다른 포트를 열어 서버가 알려준 포트로 접속을 시도합니다.
• 4) 서버가 클라이언트의 요청에 응답합니다. (acks)

Passive 모드에서는 앞선 Active 모드에서 사용했던 20번 포트를 사용하지 않고 1024번 이후의 임의의 포트를 데이터 채널 포트로 사용하게 됩니다.

연결 방식에 따른 주의사항

Active Mode의 경우는 클라이언트 측의 방화벽에 20번 포트가 차단되어 있다면, 데이터 채널 연결이 불가능해집니다. 연결은 되더라도 데이터 조회부터 실패되는 경우가 발생할 수 있습니다. 따라서 서버측은 20번 포트는 아웃바운드(OUTBOUND, 내 서버에서 외부서버로 보내는 요청) 허용, 클라이언트는 인바운드(INBOUND, 외부에서 내 서버로 들어오는 요청) 허용이 방화벽 설정에 필요합니다.

Passive Mode의 경우는 서버 측의 데이터 채널 포트가 막혀있는 경우 데이터 채널 연결이 불가능하게 됩니다. 그리고 앞서 소개한 것처럼 데이터 채널 포트의 범위를 지정할 수 있는데, 별도로 지정하지 않는 경우는 1024 ~ 65535번의 포트를 사용하게 됩니다. 따라서 INBOUND 모두 허용이 필요하게 되는데, 서버 측에서 데이터 채널 포트 범위를 지정하여 특정 범위의 포트만 허용해주면 모든 포트 허용의 문제를 어느 정도 해결할 수 있습니다.

시스코 라우터에서는 default로 enable 되어 있고,
소스 ip datagram에 header option의 조작을 허용하는 명령어라고 나와있고
no를 앞에 붙이면 반대의 경우라고 나와 있더구군요 그러면서 관련된 명령으로 ping을 예를 들고 있구요.

그래서 enable과 disable을 반복하면 소스 ping을 test해 보았는데 별다른 차이점은 확인을 못하였습니다.

ping명령어는 아시져..^===^ 근데 -r 옵션은 써보셨나여..?
ping -r (=이 옵션을 쓰시게 되면..자신이 원하는 게이트웨이를 거쳐서 routing이
될 수 있읍니다.)

즉, ping -r gateway1 gateway2 ....이런식으로 지정이 가능합니다.

(traceroute도 위와 같은 옵션이 있읍니다. 이부분도 참고 하시고여..)

저런 식으로 우리가 ping 명령어를 쓸수 있게 된것은 ip header 안에 source route option field 가 있기 때문입니다. 즉 위와 같이 ping -r 하시면
ip hearder 안의 옵션 필드에는 gateway1 gateway2 하고 기록이 되어서 ping패킷이 나가게 되어있읍니다.

source route option field가 있기 때문에 라우터는 ip header를 까보고 첫번째 gateway는 gateway1( xx.xx.xx.xx)라는 것을 알게 되고 gateway1에 도착해서는 거기서 다시 gateway2로 가라는 사실을 알수가 있읍니다..(즉 라우팅이 목적지에 의해서 결정되는 것이 아니라 소스가 지정해준 라우팅을 타고 나가서 source route option field라고 지칭하는 것 같습니다.)

그런데 라우터에서 no ip source route을 하시게 되면 이와같은 라우터의 특성을 무시하라는 명령어가 됩니다. 즉 자신이 ping -r 로서 gateway를 지정해 줘봤자..라우터에서는 ip header의 source route option field 값을 무시하므로 일반적인 라우팅을 타고 나가게 됩니다.. 반대의 경우라면 라우팅 테이블을 참조하기 전에 ip header의 source route option field 부터 적용이 되고요.

소스ping ( extended ping 이야기 하시는 거져..라우터에서 쓰는) 을 라우터에서 해봤자 ip source route과는 전혀 관계가 없겠져..no ip source route명령어를 확인해 보시고 싶으시면 라우터가 아닌 PC에서 ping -r 명령어나 traceroute명령어로 확인하시는 것이 빠릅니다.

그런데 이 ip source route명령어는 보안과 아주 밀접한 관련이 있다고 말 할 수 있읍니다. 함부로 enable 시키면 보안에 구멍이 날 수도 있겠져..
그래서 cisco에서는 12.0version(check해봐야 알겠는데여 ^^) 이상은
모두 no ip source route가 default 명령어 로 입력되어 있는 것으로 알고 있읍니다.

답변이 짧고 주저리 주저리 써서 이해가실런지 몰겠읍니다. 도움이 되었으면 좋겠읍니다.^^

IP header중에 source route option field에 대해서 자세히 아시고 싶으시면 TCP/IP illustrated vol1을 참조하시면 아주 설명이 잘 나와있읍니다.

>> Process Switching
(( 스위치는 맨 처음 이 방식으로 처리 ))
라우터가 각각의 패킷을 전송할 때마다 라우팅 테이블을 확인하고 넥스트 홉을 결정하여 패킷을 전송하는 방식을 Process Switching 이라고 합니다.
이 방식은 라우터의 CPU에 많은 부하가 걸리고 스위칭 속도도 느립니다. 또 패킷별로 로드 밸런싱(Load Balancing)이 이루어집니다. 즉 각각의 패킷별로 스위칭을 하기 때문에 목적지로 가는 경로가 2개 있을 경우에는 패킷별로 한번씩 한번씩 다른 경로로 전송합니다

Process Switching 방식으로 동작시키려면 해당 인터페이스에
"Router(config-if)#no ip route-cache" 명령을 입력하면 됩니다

——> no ip route-cache 는
         프로세스 스위칭으로 바꾸는 것으로
         옛날방식으로 바꾸는 것.
         그래서 옛날 스위치는 기본으로 있음
  
       지금은 기본으로 “ip-route-cache” 되있음


>> Fast Switching
라우터가 특정 목적지로 전송되는 패킷에 대하여 처음 한번은 Process Switching을 하고 두 번째부터는 처음 Process Switching 때 만든 캐쉬 정보를 이용하여 패킷을 전송하는 방식을 Fast Switching 이라고 합니다.
Default Switching 방식입니다. 이 방식은 목적지별로 로드 밸런싱(Load Balancing)이 이루어집니다

Fast Switching 방식으로 동작시키려면 해당 인터페이스에
"Router(config-if)#ip route-cache" 명령을 입력하면 됩니다


>> CEF(Cisco Express Forwarding) Switching
(( IOS 12.4 에서는 CEF 가 default ))
Fast Switching 방식을 다음과 같이 개선한 방식입니다. Fast Switching 방식은 처음 한번은 Process Switching을 해야 캐쉬가 생성되지만 CEF Switching 방식은 처음부터 라우팅 테이블을 캐쉬로 복사해 놓습니다. 캐쉬를 검색하는 속도도 더 빠릅니다. Fast Switching 방식은 목적지 주소와 그 목적지로 가는 경로를 기록하지만 CEF Switching 방식은 목적지 주소와 함께 출발지 주소, 목적지로 가는 경로가 기록됩니다. 이 방식은 출발지 -> 목적지별로 로드 밸런싱(Load Balancing)이 이루어집니다. 단, interface mode로 들어가서 ip load-sharing per-packet 명령을 넣어주면 패킷별로 로드 밸런싱 가능합니다. CEF Switching 방식으로 동작시키려면 전체 설정모드에서
"Router(config)#ip cef" 명령을 입력하면 됩니다.

1. no ip unreachables -> Cisco 장비의 경우 ICMP unreachable 메시지는 목적지 호스트가 네트워크 상에 존재하지 않을 경우, 네트워크 장비가 소스 호스트에 전송하는 메시로서 이를 악용하는 불법 사용자는 이 기능을 이용하여 네트워크 상에 실제로 동작하는 장비를 리스팅하고 스캔 범위를 결정하게 된다.

출처: https://wantyou7.tistory.com/16 [베롱쓰의 Level Up]



패킷이 Null interface로 보내어져 패킷이 filtering될 때마다 패킷의 source ip로 icmp unreachalbe이라는 에러메시지를 보내게 되는데, 필터링 하는 패킷이 많을 경우에는 Router에 과부하를 유발할 수 있기 때문에 icmp에러메시지를 응답하지 않도록 하는 것이 좋다

2. no ip redirects

-> ICMP redirects는 라우터가 로컬 서브넷의 호스트에게 목적지까지의 경로로서 자신이 아닌 다른 라우터를 사용하게끔 하는 기능으로, 호스트가 보유한 라우팅 테이블이 최적의 정보를 갖게 하는 것을 목적으로 한다. 악의적인 공격자들은 이런 기능을 이용하여 ICMP redirect를 전송하여 네트워크를 지나는 패킷의 방향을 바꿀 수 있다.


출처: https://wantyou7.tistory.com/16 [베롱쓰의 Level Up]

3. no ip proxy-arp

-> Cisco 라우터는 디폴트 라우터나 Gateway를 가지고 있지 않는 네트워크의 호스트들에게 ARP 서비스를 제공하는 역할을 한다. 이 경우에 호스트가 목적지 IP 주소에 대한 MAC 주소를 요청하면 Proxy ARP를 요청하여 라우터가 이에 응답하는 것을 이용하여 라우터와 네트워크에 관련된 정보를 획득할 수 있다.


출처: https://wantyou7.tistory.com/16 [베롱쓰의 Level Up]

\

Version 필드 (4bit)

: TCP/IP 제품은 IP v4를 사용한다.

Header Length 필드(4bit)

: IP 헤드의 길이를 32비트 단위로 나타낸다. 대부분의 IP 헤더의 길이는 20바이트 입니다. 필드 값은 거의 항상5다

(5 * 32 = 160bit or 20Byte)

Type-of-Service Flags

; 서비스의 우선 순위를 제공한다.

Total Packet Length 필드 (16bit)

; 전체 IP 패킷의 길이를 바이트 단위로 나타낸다.

Fragment identifier 필드 (16bit)

; 분열이 발생한 경우, 조각을 다시 결합하기 원래의 데이터를 식별하기 위해서 사용한다.

Fragmentation Flags 필드 (3bit)

; 처음 1bit는은 항상 0으로 설정, 나머지 2비트의 용도는 다음과 같다.

- May Fragment : IP 라우터에 의해 분열되는 여부를 나타낸다. 플래그 0 - 분열 가능 1 - 분열 방지

- More Fragments : 원래 데이터의 분열된 조각이 더 있는지 여부 판단. 

   플래그 0 - 마지막 조각, 기본값 1- 조각이 더 있음

Fragmentation Offset 필드 (13bit)

; 8바이트 오프셋으로 조각에 저장된 원래 데이터의 바이트 범위를 나타낸다.

Time-to-live 필드(8bit)

; 데이터을 전달할 수 없는 것으로 판단되어 소멸되기 이전에 데이터가 이동할 수 있는 단계의 수를 나타낸다.

Time-to-Live 필드는 1에서 255사이의 값을 지정하며 라우터들은 패킷을 전달 할 때마다 이 값을 하나씩 감소시킨다.

Protocol Identifier 필드(8bit)

;상위 계층 프로토콜

1 - ICMP, 2 - IGMP, 6 - TCP, 17 - UDP

Header Checksum 필드(16bit)

; IP 헤더의 체크섬을 저장, 라우터를 지나갈때 마다 재 계산을 하기 때문에 속도가 떨어진다.

Source IP Address 필드(32bit)

; 출발지 IP 주소

Destiantion IP Address 필드(32bit)

; 목적지 IP 주소

Options(선택적) 필드(가변적)

; Type-of-Service 플래그 처럼 특별한 처리 옵션을 추가로 정의 할 수 있다.

감사합니다.

DAI (Dynamic ARP Inspection)

DAI는 스위치 보안 기능으로 네트워크 내에 ARP 패킷의 정당성을 확인하여 통신하게 해주는 설정입니다.

MITM (Man in the Middle) 공격과 같이 MAC, IP의 ARP 패킷을 가로채 훔쳐보거나, 위조하여 공격하는

ARP Poisoning 등을 막기 위하여 사용하는 기능입니다.

DAI는 Untrust로 설정된 인터페이스에서 통신되는 패킷을 가로채 확인하여 옳지 않은 MAC-IP 패킷을 로그로 남기고 버린다. Trust된 인터페이스로 패킷이 들어오면 통과시킨다.

정확한 MAC-IP의 정당성을 확인하기 위해 DHCP Snooping에 의해 미리 생성된 데이터베이스를 활용한다. 

ACL을 설정하면 DHCP Snooping 보다 우선시 한다. ACL에 거부된 패킷은 DHCP Snooping 데이터베이스를 보지도 않고 거부한다.

유저 인터페이스들은 아래와 같이 설정하였습니다

SW1(config)#ip arp inspection vlan 10
SW1(config)#interface range ethernet 0/1 - 3 
SW1(config-if-range)#ip arp inspection limit rate 50

DHCP Server와 연결된 인터페이스는 아래와 같이 설정하였습니다.

SW1(config)#interface ethernet 0/0 
SW1(config-if)#ip arp inspection trust 

 

ip arp inspection vlan [Vlan ID] - DAI를 적용할 Vlan을 입력해주세요.

ip arp inspection limit rate [num] - 신뢰하지 않는 인터페이스에 초당 ARP 패킷 수를 조절한다. (넘으면 차단)

ip arp inspection trust - 스위치가 연결되어있거나 신뢰가능한 인터페이스에 설정해 주세요.

테스트로 Untrust 인터페이스에서 ARP 패킷을 전송해 보겠습니다.

*Jun 30 11:51:48.183: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Et0/2, vlan 10.([0050.7966.6804/192.168.10.200/ffff.ffff.ffff/192.168.10.200/13:51:47 EET Tue Jun 30 2020]) 

*Jun 30 11:51:49.186: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Et0/2, vlan 10.([0050.7966.6804/192.168.10.200/ffff.ffff.ffff/192.168.10.200/13:51:48 EET Tue Jun 30 2020]) 

*Jun 30 11:51:50.187: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Et0/2, vlan 10.([0050.7966.6804/192.168.10.200/ffff.ffff.ffff/192.168.10.200/13:51:49 EET Tue Jun 30 2020])

이와같이 패킷이 DENY 됩니다.

DAI 설정된 포트를 확인할 수 있습니다.

SW1#show ip arp inspection interfaces  

 Interface        Trust State     Rate (pps)    Burst Interval 
 ---------------  -----------     ----------    -------------- 
 Et0/0            Trusted                 50                 1 
 Et0/1            Untrusted                1                 1 
 Et0/2            Untrusted               50                 1 
 Et0/3            Untrusted               50                 1

 

DAI 설정된 정보를 볼 수 있습니다.

SW1#show ip arp inspection statistics  

 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops 
 ----      ---------        -------     ----------      --------- 
   10              5             21             21              0 

 Vlan   DHCP Permits    ACL Permits  Probe Permits   Source MAC Failures 
 ----   ------------    -----------  -------------   ------------------- 
   10              0              0              0                     0 

 Vlan   Dest MAC Failures   IP Validation Failures   Invalid Protocol Data 
 ----   -----------------   ----------------------   --------------------- 
   10                   0                        0                       0





감사합니다.

1. DPD (Dead Peer Detection)

   IKE Phase 2 (IPsec SA) 에서 Session lifetime 이 만료로 인해  session 이 끊긴다.
(* 1. lifetime 만료되기 전에 DPD 보내서 응답 올 경우 재협상하여 tunnel status 유지
그래서 보통 ike lifetime 은 8 hours
ipsec lifetime 은 1 hours 로 설정하여 phase 2 만료되기 전에 DPD 로 phase 1 (ike) 체크하여 최종 재협상 *)
   이러한 현상을 방지하기 위해  VPN내 연결을 끊김이 업게끔 하기위해 VPN구간내의 패킷 , 즉 Interesting packet 을 계속 발생시켜줘  
   야한다.
   ( 보통, 이러한 설정은 장비마다 있긴하지만 없을 경우 , 1. DPD 2. Tunnel monitor ) 등 설정을 통해 keepalive 패킷을 보내서 활성화.
   시키도록 한다.

**** DPD 정의 ****

Dead Peer Detection(DPD)은 RFC 3706에 문서화된 기능을 말하며, 이는 Dead Internet Key Exchange(IKE/Phase1) 피어를 감지하는 방법입니다. 터널 모니터링은 Palo Alto Networks 독점 기능으로 터널에서 구성된 대상으로 PING을 전송하여 문제의 IPSec 터널을 통해 트래픽이 성공적으로 전달되고 있는지 확인합니다. 터널 모니터링은 "모니터 프로필"과 함께 사용하여 터널 인터페이스를 중단하여 트래픽이 보조 경로를 통해 라우팅될 수 있도록 라우팅을 업데이트할 수 있습니다. 터널 모니터링에는 DPD가 필요하지 않습니다. Dead Peer Detection은 터널의 양쪽에서 활성화되거나 비활성화되어야 합니다. 한쪽은 DPD를 활성화하고 한쪽은 비활성화하면 VPN 안정성 문제가 발생할 수 있습니다.

2. [DPD 와 Keepalive 의 차이]
    1. DPD 는 데이터를 보내고 있는 동안에는 체크를 하지않는다.
    2. keepalive 는 데이터를 보내는 동안에도 체크를 주기적으로 한다

1. NAT Traversal 이란?
      Ipsec vpn 연결 및 맺기위한 과정의 IKE Phase 1 , 2 를 맺는 과정 중

      [IKE Main mode - Phase 1] 에서
        - 1,2 단계에서 NAT enable 여부를 체크한다.
       - 3,4 단계에서 NAT 가 됬는지 안됬는지 체크한다.
       - 5,6 단계에서 UDP 4500 이라는 정보를 추가로 붙여서 (NAT , PAT 가 됬건 상관업이 서로간의 문제업이 통신할수 있게끔 만

          들어지게 된것 )

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

우리가 장비 설정 후 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.]