강좌
클라우드/리눅스에 관한 강좌입니다.
리눅스 분류

Path MTU 와 ICMP Filtering 과의 관계

작성자 정보

  • 웹관리자 작성
  • 작성일

컨텐츠 정보

본문

       Path MTU Discovery 와 ICMP 필터링에 대해 

                                   정리: 홍석범(antihong@tt.co.kr)


이 문서에서는 path MTU discovery 와 ICMP 필터링과의 상관 관계에 대해 알아보도록 한다.

먼저 관련된 용어의 정의부터 알아보도록 하자.

# MTU  
MTU 란 Maximum Transmission Unit 의 약자로서 하나의 프레임이나 
패킷이 한번에 전송이 될 때 이더넷등을 통과할 수 있는 데이터의 크기이다.
이 값은 아래와 같이 어떤 프로토콜인가에 따라 다르다.

  Hyperchannel            65535
  16Mbit/s token ring     17914
  Token Bus               8166
  Ethernet                1500
  X.25                    576


# Path MTU 
현재 두 호스트간 경로에서 가장 작은 MTU 값을 말한다.
이 값은 라우팅 경로가 매번 일정하지 않고 수시로 바뀌므로  
이 값도 라우팅 경로에 따라 수시로 변경될 수 있다.
그리고 같은 호스트 사이라 하더라도 두 호스트간의 트래픽 종류에
따라(즉 X.25인지 이더넷인지등에 따라) 값이 달라진다.

# Fragmentation

패킷이 너무 커서 하나의 단일한 단위로 이더넷등을 통과할 수 없을 경우
즉 패킷의 사이즈가 라우터의 MTU 값보다 큰 경우 라우터에서는 패킷을 
Fragmentation(조각화)하여 몇 개의 부분으로 나누어 수신자에게 패킷을 
포워딩하여 전달하게 되고 수신자는 이 조각을 모두 수신한 후 재조립하게 된다.
그러나 Fragmentation 을 하게 되면 다음과 같은 문제가 발생하게 된다.

 (1) 패킷의 한 조각이 drop 되면 나머지 모든 패킷을 재전송하여야 하며 
     결국 많은 오버헤드를 유발하게 된다.
 (2) 라우터에서 패킷을 조각화하는 과정에서 많은 오버헤드가 발생하게 된다.
 (3) 어떤 방화벽에서는 아예 조각화한 패킷을 drop 해 버린다.

# DF(Don't Fragment)
 패킷 발송시 패킷 헤더에 DF 비트를 설정할 경우 설사 라우터의 MTU 값이 작어 
 Fragment 를 하여야 할 지라도 조각화하지 말라는 설정이다.
 이 패킷을 받은 라우터에서는 이 패킷을  drop 하고 "can't fragment" 라는 
 ICMP 에러 메시지를 발송자에게 전송한다.

# Can't Fragment 에러
 이 에러는 라우터에서 MTU 보다 큰 패킷이 왔지만 DF 비트가 설정되어
 Fragment 를 할 수 없어 패킷의 발송자에게 발송하는 ICMP 에러 메시지이다.
 이 메시지는 "패킷의 사이즈를 MTU 보다 줄여서 다시 발송하라"
 는 의미가 있으며 이 패킷에는 MTU 값도 함께 명기된다.
 이 에러는 오직 DF 비트가 설정되어 있을 경우에만 발생하며
 DF 비트가 설정되어 있지 않으면 라우터는 단지 이 패킷을 조각화한후 
 다음 수신자 경로로 포워딩하게 된다.
 
# Path MTU Discovery(PMTU-D)
 앞에서 이야기한 것처럼 MTU 값은 다양하다는 것을 알았다.
 또한 Fragmentation 은 Performance의 관점에서 그리 좋지 않은 것이라는 것도 알았다.
 그렇다면 이에 대한 해결책은 무엇인가?
 바로 Path MTU Discovery 이다. 이는 분절화는 피하면서 가장큰 사이즈의 패킷을 발송하는 것이다.
 이는 원격지 시스템이 알려준 MTU 나 MSS(Maximum Segment Size) 값보다 약간 작은 최대 사이즈로
 설정하여 보내면 되는 것이다. 물론 이 패킷에는 DF 비트가 설정되어 있을 것이다.
 만약 패킷이 MTU 값보다 커서 패킷을 발송할 수 없으면 ICMP 에러 메시지를 전송하는데
 이 패킷에는 MTU 값이 지정되어 있어 이 메시지를 받은 송신자는 이 MTU로 재조합하여
 다시 발송하게 된다.

 
 ICMP 필터링과 PMTU-D 와의 관계

 만약 송신자쪽에서 라우터나 방화벽에서 inbound 되는 ICMP 패킷을 필터링한다면 어떻게 될까?
 이러한 경우 송신자쪽에서 DF 비트를 설정한 채 MTU 값을 초과하는 패킷을 발송하더라도 
 수신자쪽의 라우터에서 패킷이 너무 커서 전송할 수 없다는 "Can't Fragment" ICMP 에러 
 메시지를 받을 수 없게 되어 계속적으로 큰 사이즈의 패킷을 보내게 되고 수신자는 계속
 필터링하게 되어 네트워크의 성능이 크게 떨어지게 된다.
 따라서 MTU 보다 작은 데이터는 통과하게 되고 큰 데이터는 drop 되어 전달되지 
 않는 현상이 발생하게 된다.


 이러한 경우 몇가지 해결방안이 있다.

(1) 필터링 정책을 수정한다.
 이 문제는 ICMP 에 대한 충분한 이해없이 ICMP 를 필터링한데에 있다.
 ICMP 에서는 TCP 나 UDP처럼 포트라는 개념이 없는대신 
 "ICMP 메시지타입" 이라는 것이 있어 이를 기준으로 하여 필터링을 하거나 
 허용할 수 있는데 만약 inbound 되는 ICMP 를 차단하였다면 ICMP type 3번중 code 4번인 
 "Fragmentation Needed and Don't fragment" 를 허용하면 된다.
 (http://www.iana.org/assignments/icmp-parameters 를 참고하기 바란다.)
 만약 이 필터링이 자기 자신이 아닌 목적지 사이에 어딘가에 있다면
 이 패킷을 필터링한 네트워크 담당자에게 이 문제를 확인하여 해결해 줄것을 요청하여야 한다.

(2) MTU값을 줄인다.
 MTU 값을 줄여 발송하는 시스템이 Path MTU 일 경우 애초 패킷 발송시에
 가장 작은 MTU 값으로 발송하게 되므로 이 문제가 발생하지 않게 될 것이다. 
 그러나 이 방법은 꼭 필요하지 않으면 하지 않는 것이 좋다. 

(3) PMTU-D 를 하지 않는다.
 이도 한가지 방법이 될 수는 있지만 
 꼭 필요하지 않으면 하지 않는 것이 좋다.



Reference 
 http://www.ietf.org/rfc/rfc1191.txt?number=1191
 http://www.worldgate.com/~marcs/mtu/



  
 

 
 

 
 

 
 


 
 

    

   


 
 

관련자료

댓글 0
등록된 댓글이 없습니다.

공지사항


뉴스광장


  • 현재 회원수 :  60,037 명
  • 현재 강좌수 :  35,810 개
  • 현재 접속자 :  94 명