태그: Network

Endian과 네트워크를 통한 바이너리 전송

 

네트워크 프로토콜을 구현하다 보니 Endian을 신경써야만 하는 상황이 되었다. 클라이언트에서 서버로 직렬화된 바이너리 데이터를 전송하면, 서버에서 데이터를 파싱하여 올바른 값을 추출해야 하는 상황.

처음 떠올린 생각은 직렬화를 수행하기 전에 먼저 Endian을 변환하고 직렬화를 한 뒤 서버에서 역순으로 푸는 것이었다. 그런데 4바이트보다 큰 데이터는? htonl()로는 변환이 불가능한 상황. 물론 비트 시프트를 응용해서 수동으로 구현할 수는 있지만 매번 다른 크기의 데이터마다 변환 함수를 작성하는 것은 그다지 좋은 방법이 아닌 듯 했다.

그러다 문득 IPv6는 어떻게 주소를 처리하는지 궁금해졌다. 128비트가 아닌가. 한번에 변환하기는 힘든 크기의 데이터를 어떻게 효율적으로 변환하고 있을까?

나와 같은 생각을 한 사람이 또 있었던 모양이다. (https://stackoverflow.com/questions/14301973/is-network-byte-order-pointless-under-ipv6)

 

IPv6는 공용체를 사용하여 16개의 8비트 배열, 8개의 16비트 배열, 4개의 32비트 배열을 가지고 있었다. 여기서 중요한 것은 네트워크로 주소를 전송할 때 취하는 방법이다.
2바이트를 기준으로 하자면, 그냥 htons()를 8번 수행한다. 그리고 클라이언트에서 ntohs()를 8번 한다. 끝.

참 허무한 결론이 아닐 수 없다.

엔디안에 맞춰 바이너리 전송을 할 때는 일단 직렬화한 뒤 2/4Byte에 맞춰 패딩을 붙이고, htons/l 루프를 돌린다. 그리고 수신자가 거꾸로 반복하면 끝이다.

Network Study – 4주차 : TCP/IP

 

지난 주에는 패킷 교환망에서 패킷의 경로를 결정하는 방법인 라우팅 프로토콜에 대해 알아보았다.
그리고, 이번 주에는 TCP/IP 네트워크에서 핵심적인 역할을 하는 TCP와 IP에 대해 알아보자

1. IP(Internet Protocol)의 역사

IP는 본래, TCP/IP Protocol Suite에 속한 하나의 프로토콜이다. 이것은 IAB(Internet Architecture Board)에 의해 관리되는 IANA(Internet Assigned Number Authority), IRTF(Internet Research Task Force), IETF(Internet Engineering Task Force)에서 관리된다.
이들 중 하나인 IETF에서 TCP/IP 표준인 RFC(Request for Comments)를 배포한다. 단, 모든 RFC가 표준인 것은 아니다. IAB의 검토를 거친 RFC만이 인터넷 스텐다드로써 등재되고, 전체 네트워크에서 지켜야 할 표준으로 지정된다.
그러므로, 대부분의 RFC들은 실험적인 적용이나 단순 권고를 담고 있다.

TCP/IP에 대해 다루기 전에 먼저 TCP/IP의 역사를 알아보자.

– 1970년, ARPANET 호스트들이 TCP의 전신인 NCP(Network Control Protocol)을 사용하여 운영되기 시작한다.
– 1972년, Telnet 프로토콜이 만들어진다. Telnet은 서로 다른 시스템 터미널을 에뮬레이션 하기 위해 사용되었다. 1970년대 초, 이 시스템들은 서로 다른 종류의 메인프레임들로 이루어져 있었다.
– 1973년, FTP(File Transfer Protocol)이 사용된다. FTP는 서로 다른 시스템 사이에서 파일을 전송하기 위해 사용되었다.
– 1974년, TCP(Transmission Control Protocol)이 구체화된다. TCP는 NCP를 대체하였으며, 더 개선된 신뢰성 있는 통신을 제공하였다.
– 1981년, IP(Internet Protocol)이 구체화된다. IP는 단대단 전송에서 어드레싱과 라우팅을 제공하였다.
– 1982년, DCA(Defense Communications Agency)와 ARPA는 TCP와 IP를 합쳐 TCP/IP Protocol Suite를 만든다.
– 1983년, ARPANET이 NCP에서 TCP/IP로 이전한다.
– 1984년, DNS(Domain Name System)가 제안된다. DNS는 도메인 이름을 IP 주소로 바꾸어 주었다.
– 1995년, ISP(Internet Service Provider)들이 인터넷을 개인과 기업들에게 제공하기 시작한다.
– 1996년, HTTP(Hypertext Transfer Protocol)이 제안된다. WWW(World Wide Web)이 HTTP를 사용한다.
– 1996년, 최초의 IPv6 표준이 발표된다.

이상이 간략하게 살펴본 TCP/IP의 역사이다. 본래 TCP/IP는 TCP와 하나였으며, 네트워크 계층이 구체화되면서 TCP와 IP로 분리되게 되었다.
2017년 현재 IP에서 이슈가 되는 부분은 IPv6로의 전환과 4 to 6, 6 to 4의 터널링이며, 추후 IPv6를 다룰 때 더 자세히 알아보도록 하겠다.

2. TCP/IP Protocol Suite

IP를 다루다 보면 필연적으로 상위 계층의 프로토콜들이 따라온다. IP만으로는 인터넷을 운영하는 것이 불가능하기 때문이다.
이 중 특히 ARP와 ICMP에 대한 의존도가 특히 높다고 할 수 있으리라. 이 프로토콜들에 대해 이야기하기 전에, 먼저 TCP/IP Protocol Suite를 훑어보자.

TCP/IP Protocol Suite는 다음과 같은 구조로 이루어져 있다.

이를  OSI Layer와 비교해보면 L1~2가 Network Layer로, L3가 Internet Layer로, L4가 Transport Layer로. 그리고 L5~7이 Application Layer와 대응되는 것을 알 수 있다.
이렇듯, TCP/IP Protocol Suite는 ISO에서 제정한 OSI 7계층과는 다른 구조를 가지고 있음을 알 수 있다.
이것은 OSI Layer가 프로토콜에 대한 표준안을 제시하는 것이 아닌, 프로토콜의 발전을 위하여 각 계층에서 수행하는 일들을 체계적으로 나눠 놓은 것에 불과하기 때문이며, 실제로 프로토콜을 설계할 때는 더 세부적으로 구분된 OSI 7계층을 참조하여 개발이 이루어지고 있다.

또한, 특기할 점으로는 IP(v4)와 같은 Internet Layer에 속한 ARP와 IGMP, ICMP가 있는데, 목적지까지의 전달이라는 핵심 목표를 수행하는 것은 IP이지만, IP가 좀 더 효율적으로 동작하도록 도와주는 프로토콜들이 이들 프로토콜이 되겠다. 특히 ARP는 2계층과의 연동을 담당하는 프로토콜로써, ARP 없이 IP 단독으로는 사실상 데이터 전송이 불가능하다.

IGMP를 제외한 각 프로토콜에 대해서는 이미 별도의 문서로 다루었기에, 이 글에서는 간단하게 프로토콜의 역할 정도만 소개하고 넘어가고자 한다.

2-1. ARP(Address Resolution Protocol)

ARP는 IP 네트워크에서 IP주소를 물리적 주소(PHY Address)로 대응시키기 위해 사용하는 프로토콜이다.
L3 프로토콜 주소인 IP 주소를 이용해 최종 목적지까지 라우팅 되어 온 패킷은 하부 시스템에 전달되기 위하여 L2 프로토콜 주소(e.g. MAC Address)를 필요로 하게 된다. 이 때 사용되는 프로토콜이 바로 ARP이다.

ARP의 상세 동작과 RARP, gARP 등을 알고 싶다면, CCNA Study – ARP Protocol을 참조하자.

2-2. ICMP(Internet Control Message Protocol)

ICMP는 오류 보고와 흐름 제어 기능이 없는 IP를 보조하기 위하여 만들어진 프로토콜이다.
현대 인터넷에서는 오류 보고와 흐름 제어의 역할이 L4로 넘어갔기에 이 일은 TCP가 수행하지만, 실제로 TCP에서 흐름 제어 기능을 수행할 때, TCP는 ICMP를 이용하여 오류 제어와 흐름 제어를 수행한다.
이렇듯, ICMP는 현대 인터넷이 트래픽 폭증으로 인하여 다운되지 않고 운영될 수 있게 하는 역할의 한 축을 담당하고 있다.

ICMP의 상세 동작은 CCNA Study – ICMP를 참조하자.

2-3. IGMP(Internet Group Management Protocol)

IGMP는 IP 네트워크에서 라우터가 멀티캐스트 그룹을 판단할 때 사용하는 프로토콜이다.
IGMP의 동작을 다루기 위해선 먼저 멀티캐스트에 대해 알아볼 필요가 있다. 멀티캐스트란 Unicast/Broadcast로 구성되어 있던 IP 네트워크에서 일대 다수(One to many) 혹은 다수 대 다수(Many to many) 통신을 지원하기 위해서 개발되었다.
멀티캐스트를 지원하기 위하여 IP 대역의 일부(클래스 D/224.0.0.0 ~ 239.255.255.255)를 멀티캐스트 대역으로 할당하였으며, 특히 이 중에서 224.0.0.0/24 대역은 로컬 멀티캐스트 대역으로 지정되어 있다.

IGMP는 최초 RFC 1112를 통해 표준화되었으며, IGMPv3가 Proposed Standard로써 제안되었다.
여기서는 Internet Standard인 RFC 1112를 기반으로 IGMP의 동작을 알아본다.

IPv4 Protocol Suite은 이 정도로 해두고, IPv4의 핵심 역할인 고유 주소 할당과 경로 결정은 라우팅을 다루면서 충분히 설명하였다고 생각한다.
그렇기에 이 글에서는 이전에 미처 다루지 못하였던 IPv4 패킷의 구조 정도만을 짚고 넘어가고자 한다.

(1) Version : IPv4를 나타내기에 4의 값을 가진다.
(2) Header Length : 헤더의 크기를 워드(4Byte)단위로 나타낸다.
(3) ToS or DiffServ : 본래 IP 패킷의 응용에 따라 적절한 경로를 선택하기 위해 도입되었던 ToS 필드는 그 저조한 사용률 덕에 DiffServ 필드로 대체되었다. ‘최저 비용’, ‘처리량 최대’, ‘지연 최소’ 등의 상당히 모호하고 변동성이 심한 플래그를 담고 있던 ToS와는 달리, DiffServ는 ‘패킷의 클래스별 QoS’라는 정량화된 목표를 나타낸다. 이 클래스는 ECN 2비트를 제외하고 6비트를 사용, 최대 64개로 분류될 수 있으며, 네트워크 서비스 주체가 커스터마이징 할 수 있다.
(4) Total Length : 전체 패킷의 길이를 1바이트 단위로 나타낸다.
(5) Identifier : IP 패킷에 할당되는 고유 값. 패킷이 생성될 때 설정되며, 단편화된 패킷의 경우 같은 값을 갖는다. 이것은 루핑 때문에 발생한 패킷을 IP레벨에서 네트워크로부터 제거할 수 있다는 것을 의미한다. TCP의 Sequence Number와 유사.
(6) Flags : Fragment Flags. 첫 비트는 0, 두번째 비트는 DF(Don’t Fragment) 플래그로 1로 세트될 시 단편화 불가. 세번째 비트는 More Fragment로 단편화된 패킷이 뒤에 더 있을 경우 1로 세트된다.
(7) Fragment Offset : 해당 패킷이 단편화된 데이터그램에서 어느 부분에 해당하는지 알려주는 값이다.
(8) Time to Live(TTL) : 한 홉(Hop)을 건널 때마다 1씩 감소하여, 0이 되면 폐기된다. TTL 만료로 패킷을 폐기한 라우터는 해당 패킷의 발신지를 향하여 ICMP 11 – Time Exceeded를 전송한다.
(9) Protocol : IP 상위의 프로토콜을 알려주는 SAP.
(10) Header Checksum : 헤더 전체를 대상으로 CRC-16을 수행한다.
(11) Source Address : 출발지 IP 주소
(12) Destination Address : 목적지 IP 주소
(13) Options : IPv4에서 실험용으로 사용되었던 옵션들이 다수 존재. IANA에 등록되지 않은 옵션도 직접 정의하여 사용할 수 있으나, 실제 네트워크에서는 거의 사용되지 않는다.
(14) Padding : 패킷이 32Bit(4Byte)의 배수로 만들어지지 않을 경우, 효율적인 데이터 처리를 위하여 4바이트 배수로 맞추기 위한 필드. 더미값이 들어간다.

3. IPv6 (Internet Protocol Version 6)

지난 30여년간 IPv4가 보여주었던 여러 한계점들과 문제를 해결하기 위한 대안으로써 1998년, IPv6(RFC2460)가 제안되었다.
IPv6는 IPv4의 고갈된 주소 공간을 훨씬 큰 크기로 확장하고, 주소의 파편화로 복잡화된 라우팅 테이블을 최적화 하는 것, 프로토콜 헤더의 간략화, 추후 인터넷의 변화를 유연하게 수용할 수 있는 옵션과 확장들의 개선,  우선순위에 따른 흐름 제어와 QoS등을 목표로 하여 디자인되었다.

또한 흔히들 IPv4 대비 강화된 보안성을 추가적인 장점으로 들고 있지만, 아직 IPv6와 인접 프로토콜들은 표준화가 진행중이기 때문에 오히려 IPv4 시스템에서 발생하지 않는 보안 취약점이 추가로 발견될 수 있다는 점을 염두에 두어야 할 것이다.

IPv6에서 극명히 드러나는 IPv4와의 차이점은 바로 헤더이다. IPv6는 IPv4헤더를 간략화하고, 공통 헤더와 옵션 헤더를 나누어 전체 헤더 크기를 감소시키며 확장성을 확보하였다.

(1) IPv6 Basic Header

IPv6의 가장 기본이 되는 헤더이다. IPv4의 그것과 비교하여 확연히 간략화된 모습을 확인할 수 있다.

(1) Version : IPv6이기에 6의 값을 갖는다.
(2) Traffic Class : IPv4의 ToS와 유사한 역할. 아직 표준이 확정되지 않았기에 명확한 정의는 이루어지지 않음.
(3) Flow Label : IP 프로토콜은 비연결적인 프로토콜로 설계되었으나, IPv4의 사례에서 주로 연결 지향적 프로토콜로 사용하는 경향을 확인할 수 있었다. IPv4에 대하여 연결 지향적인 프로토콜 기능을 제공해주는 기술로 MPLS가 제안되었으며, IPv6에서는 MPLS가 담당하던 부분이 IP 프로토콜에 포함되었다. Flow Label은 같은 특성을 가지는 패킷의 ‘흐름’을 나타낼 수 있으며, 이를 통해 응용별 서비스를 제공할 수 있다. 이를테면 실시간 비디오 응용의 경우 처리에 필요한 자원을 미리 예약해둘 수 있으며, 이를 위해 RTP(Real Time Protocol)과 RSVP(Resource Preservation Protocol)이 사용된다.
(4) Payload Length : 헤더를 제외한 나머지의 크기를 바이트 단위로 나타낸다. 확장 헤더는 페이로드의 일부로 간주된다.
(5) Hop Limit : IPv4의 TTL과 동일.
(6) Next Header : IPv6 공통 헤더의 다음에 위치할 헤더의 종류를 나타내는 8bit 선택자. 상위 레벨 프로토콜이나 IPv6 Extension Header를 나타낼  수 있다.
(7) Source Address : 출발지 주소
(8) Destination Address : 목적지 주소

IPv4와 비교하면 다음과 같은 차이가 있다.

– 헤더 길이 필드의 제거 : 헤더의 길이가 고정되어 있기 때문에 제거되었다.
– 서비스 유형 필드의 제거 : ToS/DiffServ는 Flow Label로 대체되었다.
– Total Length 필드의 제거 : Payload Length 필드로 대체된다.
– 단편화 관련 필드의 제거 : 단편화 확장 헤더에서 제공된다.
– 프로토콜 필드의 제거 : Next Header 필드로 대체되었다.
– 옵션 필드의 제거 : 확장 헤더를 통하여 제공된다.
– 헤더 Checksum 제거 : 상위 계층에서 제공되기에 삭제되었다.

(2) IPv6 Extension Header

IPv6에서는 헤더 부분이 네트워크에서 차지하는 대역폭을 줄이고, 확장성을 도모하기 위하여 Extension Header(이하 확장 헤더)를 도입하였다. IPv4와는 달리 용도와 페이로드의 종류에 따라 확장 헤더를 사용할 수 있으며, 각각의 확장 헤더는 독립적이고, 동시에 중첩 가능하다.

RFC2460에서 정의된 확장 헤더는 다음과 같다.

– Hop by Hop Options
– Routing (Type 0)
– Fragment
– Destination Options
– Authentication (RFC2402)
– Encrypted Security Payload

확장 헤더는 IPv6의 표준화가 진행됨에 따라 더 늘어날 수 있으며, 임의의 확장 헤더를 정의하는 것 또한 허용된다.

(2-1) Hop-By-Hop Option Header

이 옵션 헤더는 발신자가 데이터그램이 통과하는 모든 라우터에 정보를 전달할 필요가 있을 경우 사용한다.
현재는 3가지 옵션(Pad1, PadN, Jumbo Payload)가 정의되어 있으며, 각 옵션에 대한 자세한 설명은 다음 절에서 다루겠다.

– Pad1 Option : Pad1 옵션은 어떤 옵션이 특정한 위치에서 시작될 필요가 있을 때 사용된다. 만약 지정 위치에서 1바이트가 부족하다면, 정렬(Alignment)을 위해 Pad1이 추가된다. Pad1은 1바이트의 크기를 가지며,  값은 0이다.
– PadN Option : 특정 옵션이 N Byte가 모자라다면 PadN이 사용된다. PadN의 첫번째 바이트(옵션 코드)는 1, 두번째 바이트(옵션 길이)는 패딩의 크기, 나머지 바이트들은 옵션 길이만큼의 크기를 가지며 0의 값을 갖는다.
– Jumbo Payload Option : IPv6에서는 데이터그램의 최대 크기가 65,535바이트로 증가하였다. 하지만 어떠한 이유로 이것보다 더 큰 페이로드가 요구된다면 점보 페이로드 옵션을 사용할 수 있다. 점보 페이로드 옵션은 ‘정렬 제한’을 갖는다. 즉, 옵션 헤더의 시작으로부터 (4n+2)바이트의 위치에서 시작해야 한다.

(2-2) Source Routing

IPv6의 Source Routing 옵션은 IPv4의 느슨한 라우팅 옵션과 엄격한 라우팅 옵션을 결합한 것이다.
Address Left 필드는 목적지까지 도달하기 위한 홉 수를 나타내며, Strict/Loose Mask를 통하여 느슨한/엄격한 라우팅 옵션을 선택한다.

IPv4의 그것과 마찬가지로, 엄격한 라우팅 옵션은 이 패킷이 반드시 정해진 순서의 라우터를 통과하여 전송되야 함을 의미하고, 느슨한 라우팅 옵션의 경우에는 각 라우터 사이에 다른 라우터들이 들어갈 수 있다.

(2-3) Fragment

IPv6에서는 IPv4헤더에 포함되어 있던 단편화 옵션이 별도의 확장 헤더로 분리되었다. 단, IPv6에서는 오로지 발신자만이 단편화를 수행할 수 있기에 반드시 최대 MTU 값을 찾아내는 일이 선행되어야 한다. 이것은 MTU 탐색 기법(Path MTU Discovery Technique)을 통해 이루어지며, 다음과 같은 순서로 수행된다.

IPv6에서의 MTU 탐색 기법은 RFC 1981으로 표준화 작업이 진행중이다.

1. 발신지 호스트는 큰 사이즈의 데이터그램을 전송한다
2. 라우팅 경로 상에 있는 장비가 자신의 MTU 값보다 더 큰 데이터그램을 수신하면 Packet too big 메시지를 발신지로 돌려보낸다.
3. 발신지 호스트는 Packet too big 메시지에 들어 있는 MTU 값으로 재전송을 수행한다.

이렇게 보면 참 단순한 방법이지만, 여기에는 몇가지 문제가 있다.
먼저, 1회의 Packet too big  메시지만으로 Path MTU를 결정할 수 없다. 최초로 에러를 발생시킨 라우터의 다음 홉에 있는 라우터가 가진 MTU 값이 더 작을 수도 있다.
그리고 Path MTU값이 하나의 값으로 고정되게 된다면, 토폴로지 변동에 따라서 증가할 수 있는 MTU 값을 효율적으로 사용하지 못한다.

첫번째 문제는 ICMP Error 메시지가 도착하지 않을 때까지 MTU를 감소시키는 것으로 대응할 수 있다. 하지만 두번째 문제의 경우는 좀 더 복잡하다.

RFC 1981은 호스트는 Path MTU값을 좀 더 높게 ‘추정할 수 있다’고 명시한다. 하지만 이것 또한 전송하려는 데이터의 크기가 PMTU보다 커서 MTU를 확장할 필요가 있을 경우에 한한다. 그리고 이러한 시도는 Packet too big 메시지를 수신한 뒤 5분 이내에는 이루어질 수 없다.

이것을 통해 알 수 있는 것은 현재 IPv6의 표준화에 참여하고 있는 사람들은 Path MTU를 최적화하는 것 보다, 이로 인해서 발생할 수 있는 회선의 부하를 좀 더 중시한다는 점이다.
그리고 당연하지만 Path MTU 값은 IPv6의 최소 패킷 길이보다 작을 수 없다.

또 하나 쟁점이 되는 부분은 ‘어느 레이어에서 PMTU 탐색을 진행할까?’ 라는 것이다.
PMTU 탐색을 전송 레이어에서 수행하는 것은 내부 구현적 측면에서 유리하지만, 전송 프로토콜마다 알고리즘을  새로 구현해야 하며 이것은 다른 프로토콜간의 MTU 공유를 방해한다.
이러한 이유로 IP 계층에서 PMTU Discovery를 구현하게 되었고, ‘IP 레이어에서 PMTU 정보를 저장하고, ICMP가 Packet too big 메시지를 처리하는’ 식으로 구현이 이뤄졌다.

(2-4) Destination Option

기본적으로 Hop-by-Hop Option과 동일하며, 발신자가 오직 목적지 호스트에게만 정보를 전달하고 싶을 때 사용한다. 현재까지는 Pad1과 PadN만이 정의되어 있다.

(2-5) Authentication

인증 확장 헤더는 두 가지의 목적을 갖는다. 메시지 송신자를 검증하는 것과, 데이터의 무결성을 검증하는 것이다.
Security Parameter Index에서 인증 방법을 전달하며, Authentication Data가 따라온다.

(2-6) Encrypted Security Payload

IPv6에서 제공하는 도청 방지 및 비밀 보장을 위한 확장이다. 터널 모드와 전송 모드로 구현되며, 대표적인 응용으로는 IPSec이 있다.

 

(3) IPv6의 주소 공간과 할당

IPv6가 만들어진 가장 큰 이유인 IPv4의 주소 고갈 문제, 이것을 해결하기 위하여 IPv6는 주소 공간의 크기를 128비트로 확장하였다.
IPv4 대비 4배의 길이를 가지는 이 주소값은 IPv4와는 다른 구분 방법, 분배 방법 및 읽는 방법이 필요하였다.

먼저, IPv6은 IPv4와 같은 점 10진법 표기법으로 나타낼 수 있다. 하지만 이것은 IPv4 대비 4배의 길이를 가지게 되므로, 잘 쓰이지 않는다.
두번째 방법이 흔히 사용되는 16진수 콜론 표기법으로, 10진법 표기 대비 길이를 절반으로 줄일 수 있었다.
이것만으로는 가독성이 떨어졌으므로, 이 16진수 표기를 축약하는 방법이 또 제공되는데, 하나의 콜론에서 앞에 위치하는 0들을 하나의 0으로 표현하는 방법과 0으로 이루어진 콜론의 연속을 제거하고 ::으로 표기하는 방법(Zero Compression)이 있다. 특히 제로 압축은 하나의 IPv6 주소에서 두 번 이상 사용시 정확한 해석이 불가능하기에 한번만 사용될 수 있음에 주의해야 할 것이다.

IPv6은 주소 공간의 구분을 위한 CIDR를 지원하며, IPv4와 같은 해석 방법을 갖는다.

IPv6 주소 공간은 현재 Global Unicast, Unique Local Unicast, Link-Scoped Unicast, Multicast 주소와 특수 목적용 주소가 할당되어 있으며, 7/8가량의 공간이 미래 사용을 위해 예약된 채로 남아있다.
이들 주소 중에서 특히 자주 사용되는 Global Unicast, Unique Local Unicast, Multicast의 주소 영역은 다음과 같다.

– Global Unicast : 2000::/3
– Unique Local Unicast : FC00::/7
– Multicast : FF00::/8

 

(4) ICMPv6

 

(5) RTP/RSVP

 

(6) MLD

Network Study – 3주차 : Layer2 보충(VLAN, STP)

Layer2, 이더넷 스위칭을 다루면서 L2에서 사용하는 VLAN과 STP를 다루지 않았기에 다시금 보충하게 되었다.

VLAN에는 802.1Q, Cisco ISL(Inter-Switch Link), 802.1aq SPB(Shortest Path Bridging)이 있고, STP는 802.1D STP(Spanning Tree Protocol), 802.1w RSTP(Rapid Spaning Protocol), 802.1s MSTP(Multiple Spanning Tree Protocol) 그리고 SPB를 다룬다.

1. VLAN 개요

VLAN이란, L2단에서 하나의 물리적인 LAN을 여러 개의 가상의 LAN으로 나누는 기술을 말한다. 물리 망은 공유하지만, 부서에 따라 다른 네트워크 정책을 적용해야 할 경우나, 단순히 트래픽을 서로 격리할 필요가 있을 경우 사용된다. VLAN을 적용하면 일반적으로 보안이 강화된다.
VLAN의 동작은 VLAN Tagging을 통하여 이루어진다. VLAN이 설정된 포트로 프레임이 들어오면, 해당 프레임에 VLAN Tag를 붙인다. 그리고 목적지 포트가 같은 VLAN에 속하지 않으면 그 프레임을 폐기한다. 정상적으로 전달되는 경우 출력 포트를 나갈 때 VLAN Tag를 제거하여 호스트들이 패킷을 수신하게 한다. 이렇듯 VLAN은 종단간 통신에 있어 투명한 기술이다.
그리고 Trunk Port와 같이 다중 VLAN이 적용된 포트의 경우는 Tag를 붙인 채로 프레임을 보낸다. 덧붙여, Default 또는 Native VLAN이라 불리는 VLAN 1(설정으로 변경 가능)에 속한 프레임은 VLAN Tagging을 하지 않으며, Trunk Port로부터 태깅이 되지 않은 프레임이 넘어오면 Native VLAN으로 취급된다.

이러한 Port-Based VLAN이 전형적인 VLAN 적용 방식이며, 다른 방식으로는 Protocol-Based VLAN(802.1v)이 있다.

1-1. IEEE 802.1Q 상세 동작

IEEE 표준인 802.1Q의 동작에 대해 알아본다. 802.1Q는 표준 프로토콜이기에 가장 많이 사용되는 VLAN 프로토콜이라 할 수 있다.
단, 이더넷에서만 이용할 수 있다는 제약을 가진다. 몇몇 벤더는 비표준 기술로써 ATM 등에 대한 802.1Q을 지원한다.

802.1Q는 다음과 같이 프레임에 VLAN 태그를 삽입한다. Source MAC Address 뒤에 802.1Q 헤더가 오며, 첫 두 바이트 값은 0x8100이다. 이는 Ether-Type 필드와 겹쳐서, 802.1Q 프레임과 일반 프레임을 구분할 수 있도록 한다. 그리고 다음 3비트가 Priority 필드, 다음 1비트는DEI(Drop Eligible Indicator)로 혼잡 상황 발생시 이 프레임이 폐기될 수 있는지의 여부를 결정한다. 이전에는 이 값이 Ethernet-Token Ring 연동을 위한 CFI 값이었다.
그 뒤의 12비트가 VLAN ID 값으로 2^12 = 4096개의 VLAN ID 중에서 예약된 0과 4096을 제외한 1~4095, 최대 4094개의 VLAN ID를 사용할 수 있다.
특히, VLAN ID 0은 VLAN이 설정되지 않은 프레임을 의미하는데, 이  경우에는 Priority 옵션만을 사용하게 된다.

802.1Q는 지금도 계속 갱신되고 있으며, 최신 버젼의 802.1Q 지원은 벤더와 소프트웨어 버젼마다 다르다. 많은 Draft 중에서 802.1Q-2014 Draft Standard는 802.1aq와 병합되었다.

1-2. Cisco ISL 상세 동작

802.1Q와는 달리, ISL은 프레임을 캡슐화(Encapsulation) 한다. 때문에 프레임의 앞에 ISL Header가 추가되며, 끝에 FCS가 추가된다.

ISL 프레임의 구조는 다음과 같다.

(1) Destination Address (40Bit) : 특이하게도 48비트가 아닌 40Bit의 MAC을 사용한다. 이 주소는 멀티캐스트 주소로써, “01-00-0C-00-00” 또는 “03-00-0c-00-00″이다. 이 주소값은 패킷이 ISL 포맷임을 알린다.
(Q: 어째서 일반적인 L2 Address Type이 아닌가? Multicast Address가 맞긴 한가?)
(2) Type : ISL 프레임이 담고 있는 프레임의 포맷을 알린다. 0 : Ethernet, 1 : Token Ring, 2: FDDI, 3: ATM
(3) User : Type 필드의 확장으로, Priority를 나타낸다. 기본값은 0, 최대값은 3이다.
(4) Source Address : Source MAC Address이다.
(5) Length : ISL 프레임에서 DA, Type, User, SA, Len, FCS를 제외한 길이를 바이트 단위로 나타낸다. 따라서 총 길이 –  20Byte가 Length 값이 된다.
(6) SNAP (24Bit) : SNAP 값이다. 0xAAAA03을 가진다.
(7) High Bits of Source Address : OUI 값을 나타낸다. Cisco가 소유하고 있는 OUI 중 “00-00-0C”를 사용한다.
(8) Destination VLAN ID : VLAN ID값을 나타낸다. 최대 4096개의 VLAN을 지원한다. 이 중 0과 4096은 예약되어 있기에 사용 가능한 VLAN은 1-4095이다.
(9) BPDU and CDP Indicator : BPDU나 CDP 패킷을 캡슐화하였을 경우 세트된다.
(10) Index : 스위치의 Egress Port 번호를 나타낸다. 진단용으로만 사용되며, 수신한 측에서는 이 값을 무시한다.
(11) Reserved : Token-Ring, FDDI 프레임을 위해 예약된 값이다.
(12) Encapsulated Frame : 캡슐화된 원본 L2 프레임이다.
(13) FCS : 전체 ISL 프레임의 32Bit CRC 값이다.

ISL이 개발된 이후 802.1Q가 개발되었고, 현재는 ISL을 거의 사용하지 않는다. Ethernet에 맞춰 개발된 802.1q와 달리 더 다양한 네트워크를 지원한다는 장점이 있다.

 

2. STP 개요

STP(Spanning Tree Protocol)은 스위치 패킷의 루프를 방지하기 위하여 고안된 프로토콜이다. 토폴로지 구성에 있어, 스위치간 중복 링크가 활성화된 경우 브로드캐스트 패킷이 복사되어서 링크를 떠돌게 되는 브로드캐스트 스톰(Broadcast Storm)이 발생할 수 있다. 이러한 상태를 ‘루프가 발생했다’고 하며, 브로드캐스트 프레임, 혹은 다른 프레임이 스위치 링크를 무한히 떠돌아다니는 상황을 방지하고, 링크가 다운되었을 경우의 리던던시(Redundancy)를 제공하기 위해 STP가 사용된다.
한 가지 흥미로운 점은 Ethernet Frame에는 이러한 상황을 방지하기 위한 TTL 필드가 존재하지 않는다는 것인데, Ethernet을 만들 당시에는 이러한 문제를 미처 생각하지 못했던 것이 아닐까?
STP가 동작하는 방식은 매우 간단하다. Root Bridge를 선정하고, Root Bridge로 갈 수 있는 최단 경로의 포트를 선정한 뒤 다른 링크는 전부 블록시켜 버린다. 이를 통하여 모든 브리지(스위치)간의 통신이 가능해지며, 링크가 단절되었을 경우 자동으로 재연산을 수행하여 대체 경로를 찾는다.

STP의 문제점은 수렴 시간(Convergence Time)이 길어 링크 절체 시간이 길다는 것과, 대체 경로를 사용한 로드 밸런싱이 불가능하다는 것이 있다. 전자는 RSTP의 등장으로 어느 정도 해소되었지만, STP 알고리즘의 특성 상 대체 경로를 형성하는 것이 불가능하기에 현대 데이터센터에서 STP를 사용하는 것은 상당히 낭비가 큰 일이다. STP/RSTP를 대체하기 위한 프로토콜로는 SPB, TRILL 등이 있다. 물론 SDN을 통한 경로 관리도 대안이 될 수 있으리라.

2-1. STP 상세 동작

RSTP를 다루기에 앞서, STP의 동작을 먼저 다루도록 하겠다. STP에서 사용되는 용어들은 다음과 같다.

– Root Bridge : STP의 중심이 되는 브리지. 주로 Bridge ID값이 높은 장비가 선출된다.
– Root Port : Root Bridge로 가는 최단 경로에 위치한 포트
– Designated Port : Designated Bridge에 속한 포트 중 해당 LAN Segment의 Minimum Path Cost를 갖는 포트.
– Designated Bridge : LAN Segment에 연결되어 있는 브리지 중 Root 브리지로 가는 Path Cost 값이 가장 작은 경로를 가진 Bridge. 각 LAN 세그먼트마다 하나씩 선출된다. 이 때 주의해야 할 점은, 여기서의 LAN 세그먼트는 물리적인 세그먼트라는 것이다.
– BPDU(Bridge Protocol Data Unit) : STP에서 토폴로지 정보를 교환하기 위한 프레임을 말한다. 여러 종류의 BPDU들이 존재한다.

STP는 다음과 같은 순서로 동작한다.

1. 루트 브리지(Root Bridge) 선출
2. 루트 포트(Root Port) 선출
3. Designated Bridge 선출 (각 LAN Segment마다)
4. Designated Port 결정
5. Port State 천이 (Blocking – Listening – Leaning – Forwarding)

이제 이 과정을 좀 더 자세히 다뤄 보자. 하지만 상세 동작을 다루기 위해서는 BPDU에 대한 이해가 필요하기에 BPDU의 구조를 먼저 다루도록 하겠다.

BPDU 프레임의 구조는 다음과 같다.

(1) Configuration BPDU

(1) Protocol ID : 0x0000(STP)
(2) Protocol Version : 0x00 (IEEE 802.1D)
(3) BPDU Type : 0x00, Configuration BPDU
(4) Flags : 첫번째 비트가 TC, 마지막 비트가 TC Ack 플래그이다.
(5) Root Identifier (64Bit) : BPDU를 만든 브리지가 Root Bridge로 여기는 브리지의 ID.
(6) Root Path Cost (32Bit) : BPDU를 만든 브리지로부터 루트 브리지까지의 총 Path Cost값.
(7) Bridge Identifer (64Bit) : BPDU를 만든 브리지의 Bridge ID
(8) Port Identifier : BDPU를 전송한 포트의 Port ID
(9) Message Age (16Bit) : 루트 브리지에서 BPDU를 전송할 때 0으로 세트된다. 그리고 브리지를 타고 내려갈 때마다 1씩 증가하며, 각 브리지는 (자신의 Max Age – Messeage Age)만큼 BPDU를 보관한다. Timer가 Max Age를 넘어서면 BPDU는 만료된다.
(Q: 만약 Timer가 짧고, 많은 브리지를 거쳐야 한다면 BPDU가 도달 불가능한 브리지도 생길 것인가?)
(10) Max Age : Root Bridge의 Max Age 값.
(11) Hello Time (16Bit) : Root Bridge가 Hello를 보내는 주기.
(12) Forwarding Delay : Root Bridge에 설정된 Bridge Forwarding Delay 값.

여기서 주의할 점은 STP 타이머 값들은 모두 루트 브리지의 설정을 사용한다는 것이다. 루트 브리지의 타이머 설정은 Configuration BPDU를 통해 전체 브리지들로 전파된다.

(2) TCN(Topology Change Notification) BPDU

 

이제 BPDU에 대해 알아보았으니, BPDU의 정보를 기반으로 STP가 트리를 구성하는 과정을 살펴보자.

2-1.1. Root Bridge 선출
스위치의 초기화가 완료되면, 스위치는 자신이 Root Bridge라고 생각한다. 때문에 모든 포트를 Designated Port로 간주, Configuration BPDU를 내보낸다.
스위치들은 Configuration BPDU 내의 Root Identifier와 자신이 알고 있는 Root Identifier를 비교, 더 값이 높은 쪽을 루트 브리지로 선정한다.

2-1.2. Root Port 선출
루트 브리지의 선출이 완료된 뒤, 각 브리지들은 루트 브리지의 BPDU를 수신한 포트들 중에서 Root Path Cost가 가장 작은 포트를 Root Port로 지정한다.
만약 코스트가 같은 포트가 둘 이상이면 Designated Bridge ID가 작은 포트를, 그것도 같으면 Designated Port ID를, 마지막으로 자신의 Port ID를 비교해서 낮은 쪽을 Root Port로 지정한다.

2.1.3. Designated Bridge 선출
LAN Segment에서 Root Path Cost값이 가장 작은 브릿지가 Designated Bridge가 된다. 이 때 같은 LAN Segment에 존재하는 브리지들을 파악하기 위하여 BPDU의 Bridge ID와 Port ID를 사용한다.
스위치 환경에서는 스위치 하나에 연결된 장비들이 하나의 LAN Segment가 되므로, 하나의 LAN Segment에 여러 스위치들이 존재할 수 없다. 때문에 Root에 더 가까운 스위치가 Designated Bridge가 될 것이다.

2.1.4. Designated Port 선정
LAN Segment에서 Designated Bridge와 연결된 포트가 Designated Port가 된다.

2.1.5. Forwarding State로 천이
Designated Port와 Root Port가 Forwarding 상태로 천이되며, 프레임과 BPDU를 전송한다.

2.1.6. STP Port Status

앞서 STP가 루프를 방지하기 위해서 일부 포트를 활성화하고, 일부 포트는 차단(Blocking)한다고 설명하였다. STP의 포트 상태에 대해 좀 더 자세히 알아보자.

(1) Disabled : 관리자에 의하여 사용이 중단되었거나, 물리적으로 링크가 Down된 상태
(2) Blocking : STP 연산 결과 Designated, Root 포트가 아니어서 프레임 전달 기능이 비활성화된 상태
(3) Forwarding : 프레임 전달 및 MAC Address Learning을 수행하는 상태.
(4) Listening : Blocking에서 Forwarding으로 천이하는 과정에서 생길 수 있는 루프를 방지하기 위해, 프레임 전달 및 MAC Learning을 수행하지 않고 대기하는 상태. Forwarding Delay 값의 영향을 받는다.
(5) Learning : Listening에서 천이되는 상태로, 프레임 전달은 수행하지 않고 MAC Address Learning만 수행하는 단계. 마찬가지로 Forwarding Delay 값의 영향을 받음.

여기서 주의해야 할 부분은 Blocking된 포트라 하더라도 BPDU 송신을 하지 않을 뿐, BPDU 수신은 이루어진다는 것이다.
그리고 Listening – Learning – Forwarding으로 천이되는 동안 Forwarding Delay동안 대기(기본값 20초)하여, 토폴로지 변동 시 절체 시간이 약 50초에 이른다는 것을 확인할 수 있다.

이상으로 STP의 상세 동작을 알아보았다.
추후 STP에서 문제가 되는 부분인 긴 절체시간을 해결하기 위하여 802.1w RSTP(Rapid Spanning Tree Protocol)가 제안된다.

2-2 RSTP 상세 동작

2-3. MSTP 상세 동작

2-4. 결론

 

3. SPB 상세 동작

VXLAN(Virtual eXtensible Local Area Network) – 1

최근 데이터센터에서 멀티 테넌트 환경을 지원하기 위해 각광받고 있는 VXLAN을 RFC를 바탕으로 이해해 보자.

RFC7348에서는 VXLAN을 ‘가상화된 L2 네트워크를 오버레이로 L3네트워크 상에서 구현하는 프레임워크’라 정의하고 있다. 그리고 RFC7348은 Informational 카테고리에 등록되어 있다.

 

1. 개요

IDC에서 서버 가상화가 확산되고, 하나의 서버가 많은 VM들을 가지게 되면서 Ethernet Switch가 가지는 MAC Address Table도 급격히 커지게 되었다. 또한 Extended VLAN의 최대 갯수가 4096개인 것에 비해 멀티 테넌트 환경에서 수천개, 혹은 그 이상의 VLAN을 요구하게 됨에 따라, 잠재적으로 중복된 VLAN ID가 발생할 가능성이 생겼다. 그리고 가상화된 L2 네트워크를 전체 데이터센터에 적용하게 되면, 기존에 사용되던 STP 같은 루프 방지 알고리즘은 많은 비활성화 된 링크를 만들어낸다. 이런 상황을 피하기 위해서 Equal-Cost Multipath(ECMP)를 도입한다 하더라도, VM간 통신에는 여전히 기존의 L2 모델을 남겨둘 수 밖에 없다.

이러한 문제점들을 해결하기 위하여 오버레이 네트워크가 제안되었다. 오버레이 네트워크란, 각각의 VM들이 만들어내는 MAC 트래픽을 논리적인 ‘터널’을 통해 캡슐화하여 전달하는 것을 의미한다. 그리고 VXLAN은 오버레이 네트워크를 실현하기 위한 프레임워크이다.

 

2. 가상화 환경에서의 제약 사항

2-1. STP(Spanning Tree Protocol)과 VLAN 범위의 제약

현재, L2 네트워크는 루프 회피를 위하여 IEEE 802.1D STP를 사용하고 있다. STP는 중복되는 링크를 블록하는 것으로 루프 방지를 구현한다. 때문에 데이터센터는 실제로 사용할 수 있는 것보다 더 많은 물리적 링크를 가져야 하고, 다중 경로를 통해 얻을 수 있는 복원성도 사라진다. 이를 해결하기 위한 최근의 시도로 TRILL(RFC6325)과 SPB(802.7ag)가 있지만, 멀티패스틑 구현할 수 있도록 도와주거나, STP의 문제들 중 일부를 덮어둘(surmount) 뿐이다. STP의 제약은 서버와 랙을 하나의 Layer 3 네트워크로 구성하는 것으로 해결될 수 있다. 하지만 이것 또한 VM 사이의 통신을 위한 L2 모델과 호환되지 않는다.

L2 데이터 센터의 특징은 Broadcast isolation을 위해 VLAN을 사용한다는 점이다. 12bit의 VLAN ID는 최대 4096개의 VLAN을 제공할 수 있으며, 기존의 데이터센터들에서는 4096개보다 더 적은 VLAN을 사용했기에 문제가 없었다. 하지만 서버 가상화의 도입으로 고객들에게 독립된 환경(Tenant)를 제공하는 것이 중요해졌고, 한 서버에 수많은 VM들이 올라감에 따라 VLAN ID는 급속도로 고갈되었다.

 

2-2. 멀티 테넌트 환경

클라우드 컴퓨팅은 om-demand한 동적 프로비저닝을 요구한다. 대부분의 클라우드 컴퓨팅은 Private Cloud이며, 서비스 제공자는 하나의 물리적 인프라 위에서 각 고객들에게 독립된 환경을 제공해주어야 한다. 테넌트를 이용한 네트워크 트래픽 분리는 L2, L3네트워크에서 적용될 수 있다. L2 네트워크에서는 이것을 위해 VLAN이 자주 사용된다. 클라우드 서비스 제공자는 많은 수의 테넌트를 제공해야 하며, 각 테넌트당 하나의 VLAN ID가 할당되어야 하는 환경에서 4096개의 VLAN ID 제한은 적합하지 않다. 게다가 하나의 테넌트가 여러개의 VLAN을 요구할 수도 있는데(Ex. 부서간 네트워크 분리) 이는 상황을 더욱 악화시킨다. 관련된 다른 문제로 cross-pod 확장이 있다. pod이란 연관된 네트워크와 스토리지로 구성된 하나 또는 그 이상의 랙을 말한다. 테넌트는 그것이 더 많은 서버와 VM을 필요로 할 때 다른 Pod으로 확장될 수 있어야 한다. 특히, 인접 Pod의 자원 활용율이 낮다면 더욱 그렇다. 이러한 환경에서는 “확장된” L2 환경이 필요하다.

L3 네트워크 또한 멀티테넌시 환경에 대한 포괄적인 해결책은 아니다. 두 테넌트가 자신들의 네트워크에서 동일한 L3 주소를 사용할 수 있으려면, 클라우드 서비스 제공자가 고립된 네트워크 환경을 제공해 주어야 한다.

 

2-3. ToR Switch의 부적절한 테이블 크기

지금의 가상화된 환경에서는 ToR(Top of Rack)스위치의 MAC Address Table의 크기가 증가되어야 한다. 서버의 링크당 하나의 MAC Address를 학습해야 했던 이전과는 달리, 스위치는 이제 VM에 붙은 링크 수만큼의 MAC Address를 학습해야 한다. 데이터센터는 여러대의 랙으로 이루어져 있고, 다른 랙에 있는 VM과 통신하기 위하여 MAC을 학습해야 한다. 때문에 가상화되지 않은 환경에 비해 큰 테이블 크기를 요구한다.

스위치는 테이블이 다 찼을 시, 학습을 중단하고 학습되지 않은 패킷들을 모든 포트로 플러딩한다.

 

3. VXLAN

VXLAN은 L3 네트워크 위에 가상의 L2 네트워크를 오버레이하는 기술이다. 오버레이된 네트워크들을 VXLAN segment라고 하며 각각의 segment에 포함된 VM끼리만 통신이 가능하다. 각 VXLAN segment는 24비트의 식별자(VXLAN Network Identifier)를 가지며, 최대 1600만개 이상의 VXLAN 세그먼트가 만들어질 수 있다. VXLAN Netrowk Identifier(이하 VNI)는 내부의 캡슐화된 이더넷 프레임이 어떤 VM으로부터 나왔는지 특정하며, 때문에 세그먼트들 사이의 MAC을 오버래핑 하더라도, 트래픽이 세그먼트들을 ‘통과하는’일은 일어나지 않는다. 이러한 캡슐화 때문에 VXLAN은 L3 네트워크에서 L2 네트워크를 구성하는 터널링 기술로 불리기도 한다. 이 터널이 stateless 하기 때문에 각각의 프레임들은 일정한 규칙에 따라 캡슐화될 필요가 있다.

이 터널의 종단(VXLAN Tunnel End Point, 혹은 VTEP)은 VM을 서비스하고 있는 서버나 하이퍼바이저에 위치한다. 여기서, 물리적인 네트워크 장비나 서버 또한 사용될 수 있음을 기억하자.

그럼 이제 VXLAN이 터널을 어떻게 구성하는지 알아보자.

 

1. VXLAN이 적용된 VM은 VXLAN을 인지하지 못한다. 이 VM은 다른 VM과 통신하기 위하여 일반적인 MAC 프레임을 전송한다.

2. 물리 호스트 위의 VTEP는 프레임을 수신하고, 해당 VM이 속한 VNI를 찾는다. 그리고 목적지 MAC이 같은 세그먼트에 속하는 VM이라면, 원격 VTEP의 MAC을 매핑한다. 이 시점에서의 패킷 구조는 IP-MAC 헤더-원본 L2 프레임이다.

3. L3 네트워크를 타고 전송된 프레임이 원격 VTEP에 도착한다. 원격 VTEP는 VNI를 검증하고 목적지 VM이 해당 VNI에 속해있는지 확인한 뒤, 프레임의 캡슐화를 풀고, VM에 전달한다.

 

RFC7348은 VTEP의 구현과 프레임을 최종적으로 전달할 때의 구현에 대해선 정의하고 있지 않다. 따라서 이러한 부분에서 벤더간 호환성 문제가 발생할 수 있을 것으로 보인다.

CCNA Study – DHCP

 

DHCP (Dynamic Host Configuration Protocol)는 호스트의 네트워크 설정을 쉽게 하기 위하여 개발된 프로토콜이다.

이에 앞서 RARP라는 자동 IPv4 할당 프로토콜이 있었지만, RARP는 오로지 IP만을 정적(Static)으로 할당받을 수 있었기에 디폴트 게이트웨이, 서브넷 마스크, DNS 서버 주소 등의 통신에 필요한 추가적인 정보를 제공받을 수 있는 새로운 방법이 필요했고, IETF는 RFC 951에서 BOOTP를 정의하여 이 문제를 해결하였다.

그러나 BOOTP는 여전히 IP를 Static하게만 할당할 수 있었고, 유연성 부족과 확장 옵션의 비표준화 등의 문제로 인해 BOOTP를 개량한 DHCP가 RFC 2131에서 새로 정의되었다.

 

그럼, 일반적인 환경에서의 DHCP 동작 알고리즘을 살펴보자.

 

1. 클라이언트는 부팅이 완료된 뒤 UDP 68번 포트로 DHCP DISCOVER 메시지를 보낸다.

2. DHCP 서버는 DISCOVER 메시지를 수신한 뒤 해당 클라이언트에게 DHCP OFFER 메시지를 전송, 자신이 IP를 제공할 수 있음을 알린다.

3. DHCP 클라이언트는 자신이 수신한 OFFER 중 하나를 선택(DHCP 서버가 다수일 경우), DHCP REQUEST 메시지를 브로드캐스팅한다. 이는 자신이 선택한 IP 주소를 알리고, 선택받지 못한 다른 서버들이 IP 주소를 재사용할 수 있게 하기 위함이다.

4. DHCP 서버가 DHCP 클라이언트에게 DHCP ACK 메시지를 전송함으로써 IP 할당이 완료된다.

5. 클라이언트는 자신이 할당받은 IP로 ARP Probe를 전송함으로써 충돌 확인을 한다. 만약 ARP Reply가 돌아오지 않으면 이 IP를 사용하게 된다.

 

앞서 말했듯이 DHCP는 이전에 사용하던 RARP/BOOTP의 부족한 부분을 보완하여 만들어졌다. 또한 여러 상황들에 유연하게 대응할 수 있도록 확장성 있는 구조를 가지는데, 상세 동작을 다루기 위해서는 먼저 DHCP 패킷의 구조를 이해할 필요가 있다.

 

DHCP 패킷은 다음과 같이 구성되어 있다.

 

1. Opcode (1Byte): DHCP 메시지의 타입을 나타낸다. 1은 BOOTREQUEST(요청), 2는 BOOTREPLY(응답)라 한다.

2. Hardware Type (1Byte): L2 Protocol의 유형을 나타낸다. ARP의 그것과 동일하다.

3. Hardware Length (1Byte): 하드웨어 주소 길이를 바이트 단위로 나타낸다.

4. Hop Count (1Byte): DHCP Relay가 사용될 경우 패킷이 중계된 횟수를 나타낸다. 기본값은 0이며, 경유한 Relay Agent마다 1씩 증가한다.

5. Transaction ID (4Byte): 클라이언트가 선택하는 랜덤한 32비트짜리 수이다. DISCOVER와 OFFER를 짝짓는데 사용한다.

6. Number of Seconds (2Byte): 임대 획득/갱신 이후 경과한 시간을 나타낸다.

7. Broadcast Flags (2Byte): 첫번째 비트가 0이면 응답 메시지를 유니캐스트로, 1이면 브로드캐스트로 전송한다.

8. Client IP Address (4Byte): 클라이언트의 IP 주소를 나타낸다. 최초 요청시에는 IP가 할당되지 않았으므로 0.0.0.0이 들어간다.

9. Your IP Address (4Byte): 클라이언트에게 할당되는 IP 주소로, 서버의 응답 메시지에 포함된다.

10. Client H/W Address (16Byte): 할당을 요청한 클라이언트의 하드웨어 주소가 들어간다.

11. Server Name String (64Byte): 서버 호스트 이름. 널 문자로 끝난다.

12. Options (가변 길이): DHCP 옵션들을 나타낸다. 최초 4바이트가 0x63, 0x82, 0x53, 0x63으로 되어 있다. 이 ‘Magic Cookie’는 RFC 1497 (BOOTP Extension)에서 정의된 것으로, BOOTP와의 호환성을 유지하기 위해 사용된다.

 

이를 그림으로 나타내면 다음과 같다.

 

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

BOOTP 프로토콜과 비교해 보면, 마지막 Option Field만이 약간 달라진 것을 알 수 있다.

DHCP Option Field의 구조는 다음과 같으며, DHCP는 이 Option Field를 이용하여 BOOTP와는 다른 확장 기능들을 구현한다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

그러면 이제 DHCP Option들에 대해 알아보자.

실제 사용할 수 있는 DHCP Option은 굉장히 많으나, 이 중 RFC 2132에서 정의된 것은 다음과 같다.

DHCP Option
All Rights Reserved IANA

 

전체 옵션 리스트는 다음 파일을 참조하라.

 options.xlsx

 

이 글에서는 IP  할당 및 임대 갱신에 사용되는 Option 50, 51, 53, 54, 61과 네트워크 통신을 위한 추가 정보를 제공하는 Option 1, 3, 5, 6, 15에 대해 서술한다.

 

Option 1 (Subnet Mask): 해당 클라이언트의 Subnet Mask를 지정한다.

Option 3 (Router): 해당 클라이언트의 Default Gateway를 지정한다.

Option 5 (Name Server): 클라이언트가 사용할, IEN 116에 정의된 네임서버의 주소를 지정한다.

Option 6 (Domain Server): 클라이언트가 사용할 DNS 주소를 지정한다.

Option 15 (Domain Name): 클라이언트의 도메인 이름을 지정한다.

Option 50 (Address Request): DHCP 서버가 클라이언트에게 할당할 IP Address를 지정한다.

Option 51 (Address Time): 할당해줄 IP Address의 임대 만료 시간을 지정한다.

Option 53 (DHCP Msg Type): DHCP 메시지의 타입을 지정한다. 아래의 표를 참조하라.

dhcp_msg

Option 54 (DHCP Server ID): DHCP 메시지를 전송한 서버의 IP 주소를 알린다.

Option 61 (DHCP Client ID): 클라이언트를 식별할 수 있는 식별자가 들어간다. 이 식별자로는 클라이언트의 MAC Address, FQDN 등이 사용될 수 있다.

 

부록

A. DHCP Relay Agent

DHCP의 설정 과정에서 브로드캐스팅이 사용되기 때문에 DHCP의 동작 범위는 기본적으로 하나의 서브넷으로 한정된다. 그러나 대규모 네트워크에서 이러한 구성은 다수의 DHCP 서버를 필요로 하고, 높은 비용을 발생시키며, 관리를 어렵게 만든다.

이에 따라 제안된 것이 바로 DHCP Relay Agent이다.

DHCP Relay Agent는 DHCP 서버와 클라이언트 간의 메시지 전달을 중계하여 DHCP 메시지가 서브넷을 넘어서 이동할 수 있도록 한다.

 

다음으로 DHCP Relay Agent가 어떻게 동작하는지 알아보자.

1. 클라이언트가 DHCP Discover 메시지를 브로드캐스팅한다.

2. Relay Agent는 Discover 메시지를 수신, DHCP 서버로 유니캐스팅한다. 이 때 Giaddr(Gateway Address)에 0.0.0.0 대신 자신의 IP를 기록하여 이 메시지가 Relay Agent로부터 온 것임을 서버에게 알린다.

3. DHCP 서버는 Giaddr 필드의 주소에 맞는 IP 풀을 선택, IP를 할당하고 Relay Agent의 주소로 DHCP Offer 메시지를 보낸다.

4. Relay Agent는 DHCP Offer를 클라이언트에게 중계한다. 이 때 Discover 메시지 안의 Broadcast Flag가 0이면 유니캐스트로, 1이면 브로드캐스트로 전송한다.

 

이것으로 Relay Agent의 기본적인 동작을 알아보았다.

그런데 메시지가 Relay Agent를 지날 때 Giaddr 필드에 Relay 자신의 IP를 기록한다면, 다수의 Relay를 거쳐서 서버로 요청이 전송되는 경우에는 서버가 클라이언트의 IP 대역을 잃어버리게 된다(Giaddr 주소에 근거하여 판단하므로) 따라서 여러 릴레이를 거치는 구성은 불가능한데, 어째서 Hop Count가 존재할까?

나는 이것이 DHCP 패킷이 루핑 등의 이유로 네트워크를 계속 떠돌아다니는 것을 막기 위해서 사용된다고 결론지었다. 실제로 여러 네트워크 회사의 DHCP 서버 설정에 max-hop-count가 존재하기도 하고.

만약 다른 이유가 있거나, 다수의 릴레이를 거치는 구성이 가능하다면 의견을 남겨 주길 바란다.

 

B. APIPA

DHCP 클라이언트가 DHCP를 통한 IP 할당에 실패하는 경우, 클라이언트는 네트워크와의 연결을 위해 APIPA(Automatic Private IP Addressing)을 사용해 169.254.0.0/16의 주소 중 하나를 임의로 할당한다.

APIPA는 RFC3927에서 정의되었고, BOOTP와 마찬가지로 네트워크 구성에 필요한 여러 정보를 얻을 수 없기 때문에 소규모 사설 네트워크에서의 통신에서만 사용될 수 있다.

CCNA Study – ARP Protocol

 


 

목차

1. Introduction

2. ARP 동작 예시

3. ARP의 변형

3-1. Reverse ARP (RARP)

3-2. Inverse ARP (InARP)

3-3. DHCP ARP

3-4. Gratuitous ARP (gARP)

3-5. ARP Probe

3-5.1. ARP Probe의 동작

3-6. UnARP


 

1. Introduction

Ethernet에서 물리 계층 주소(MAC)을 얻어낼 때 사용하는 프로토콜인 ARP에 대해 RFC를 참조하여 알아본다.

ARP는 1982년, RFC 826에 처음으로 정의되었다. 여기서 ARP의 목적은 ‘프로토콜 주소를 로컬 네트워크 주소로 변환하는 방법을 제공하는 것’이라고 밝히고 있다. 즉, 기본적으로 Ethernet을 위해 개발된 프로토콜이긴 하지만, 경우에 따라서 다른 프로토콜 위에서 동작할 수 있으며, 실제로 X.25, HDLC, FDDI, 802.11, ATM 등에서도 ARP를 사용하고 있다. ARP는  STD 37이라는 이름의 인터넷 프로토콜로 승인되었고, RFC 1122에서의 ‘잘못된 ARP Entry에 대한 처리’에 대한 모호함을 보완하였다. (The ARP specification [LINK:2] suggests but does not require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses.)[1]

그러면 다시 RFC 826으로 돌아가 ARP가 어떻게 동작하는지 알아보자.
RFC 826에서는 ARP 헤더를 다음과 같이 정의하고 있다.

1. Hardware Address (16bit) – 로컬 네트워크에서 사용하는 하드웨어 타입을 규정한다.

2. Protocol Address (16bit) – 하드웨어 타입 필드를 보완하며, 3계층 프로토콜의 종류를 규정한다. Ethernet의 경우 Ether-type 필드의 값과 동일하다.

3. Hardware Address Length (8bit) – 뒤에 올 하드웨어 주소의 길이를 바이트 단위로 지정한다. 예를 들어 Ethernet은 48bit이므로 6의 값을 갖는다.

4. Protocol Address Length (8bit) – 이 메시지에 포함된 3계층 프로토콜의 주소 길이를 바이트 단위로 지정한다. 예를 들어 IPv4는 4의 값을 갖는다.

5. Opcode (16bit) – 이 ARP 패킷의 목적을 밝힌다. Opcode의 값은 좀 더 뒤에서 다루겠다.

6. Sender Hardware Address (n Byte) – 앞서 말한 길이의 송신자 하드웨어 주소가 온다.

7. Sender Protocol Address – (m Byte) – 앞서 말한 길이의 송신자 프로토콜 주소가 온다.

8. Target Hardware Address – (n Byte) – 앞서 말한 길이의 수신자 하드웨어 주소가 온다. 당연히 ‘알고 있을 경우’에 한하여 기록된다.

9. Target Protocol Address (m Byte) – 앞서 말한 길이의 수신자 프로토콜 주소가 온다.

이것을 그림으로 나타내면 다음과 같다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

2. ARP 동작 예시

Host A가 Host B에게 ARP Request를 보내는 시나리오를 이용하여 일반적인 ARP의 동작을 알아본다.

1. Host A는 이더넷 프레임에 사용할 목적지 MAC 주소를 결정하기 위해 자신의 ARP 캐시 테이블을 확인한다.

2. 캐시 테이블에 MAC 주소가 없다면 Host B의 MAC을 얻기 위해 ARP Request를 Dst-MAC-Addr을 FF:FF:FF:FF:FF:FF로 설정하여 브로드캐스팅한다.

3-1. 동일한 네트워크 세그먼트 상의 시스템들은 모두 이 ARP 패킷을 수신하고, 자신의 Protocol Address와 패킷의 TPA를 비교, 같지 않으면 폐기한다.

3-2. 만약 패킷의 TPA와 자신의 Protocol Address가 일치한다면, 자신의 Protocol Address를 기록한 ARP Reply 패킷을 Request를 보낸 시스템에 유니캐스트로 전송한다.

4. ARP Reply를 수신한 Host A는 자신의 ARP 캐시 테이블에 그 정보를 기록한다.

5. ARP Request에는 응답 만료 시간(Timeout)이 존재하지 않기 때문에, 응답을 수신하지 못하더라도 상관없다. 물론 이 경우에는 호스트와의 통신이 이루어지지 않는다.

 

 

3. ARP의 변형

Ethernet이 확산되고, 증가하는 여러 요구들에 대응하기 위해 ARP의 변형들이 사용되게 되었다.

대표적으로 Reverse ARP, Inverse ARP, Gratuitous ARP 등이 존재하는데, 이것들을 다루기 전에 먼저 ARP Packet의 Operation Code를 살펴볼 필요가 있다.

 

from IANA Reference
from IANA Reference [2]

여기서 Opcode 1, 2번은 일반적인 ARP 요청과, 변형 ARP 중 gARP, DHCP ARP, ARP Probe 등에 사용되는 Request/Reply이고, 이 글에서는 이에 더하여 Reverse ARP(3,4번) Inverse ARP(8, 9번)을 다루겠다.

 

 

3-1. Reverse ARP (RARP)

IPv4를 사용하는 장비가 자신의 하드웨어 주소는 알고 있지만, 자신에게 할당된 IPv4 주소는 모를 때 사용한다.

과거에 저장 매체가 없는 단말들(터미널)이 라우팅이 필요하지 않은 LAN 통신을 위해 주로 사용했지만, 디폴트 게이트웨이, DNS 서버 주소, 서브넷 마스크 등을 알 수 없기 때문에 지금은 DHCP와 BOOTP로 대체되었다.

 

Reverse ARP의 동작 과정은 다음과 같다.

1. 부팅된 터미널 장비가 Sender MAC-Addr와 Target MAC-Addr을 자신의 하드웨어 주소로 채운 RARP Request 패킷을 브로드캐스팅한다. 이 때 Sender IP-Addr과 Target IP-Addr은 전부 0.0.0.0이다.

2. RARP 서버가 이것을 수신하고, Target Protocol Address를 터미널 장비에 할당된 IP로 넣은 RARP Reply 패킷을 L2 Unicast 한다.

3. 터미널이 RARP Reply를 수신하고, 자신의 IP를 설정한다. Calssful Network를 기반으로 한 LAN 통신만이 가능하다.

RARP에 대한 자세한 설명은 RFC 903[3]에 기술되어 있다.

 

 

3-2. Inverse ARP (InARP)

Inverse ARP는 Frame-Relay와 ATM과 같이 여러 물리 계층 장비가 연결되어 WAN 네트워크를 구성하고 있지만, 하나의 논리적인 회선을 구성하여 통신을 하는 네트워크에서 쓰인다.

Frame Relay 망에서 Inverse ARP는 네트워크 장비가 자신과 연결된 VC 단말의 정보를 얻는 데 사용되며, 이를 위해서는 당연히 L2 설정이 제대로 되어 있어야 한다.

L2 통신에 필요한 DLCI를 동적으로 할당하고, 링크의 상태를 확인하는 프로토콜로 LMI가 있는데, 이것은 추후 Frame Relay를 살펴볼 때 알아볼 것이다.

 

그럼 간단한 Frame Relay 망을 예시로 InARP가 어떻게 동작하는지 알아보자.

 

InARP

 

1. Router A는 자신에게 할당된 DLCI 10, 20이 어디에 연결되어 있는지를 알고 싶어한다.

2. Router A는 SHA를 DLCI 10, SPA를 ipA로 하여 InARP Request를 전송한다.

3. Router A의 InARP Request를 수신한 Router B는 자신의 InARP 캐시에 Router A의 DLCI와 IP를 기록하고, SHA에 DLCI 40, SPA에 ipB를 기록한 InARP Reply를 전송한다.

4. Router B의 InARP Reply를 수신한 Router A는  자신의 InARP 캐시에 RouterB의 DLCI와 IP를 기록한다.

5. 이제 L3 통신을 위한 모든 정보가 갖추어졌으므로 통신이 이루어질 수 있다.

 

Inverse ARP의 구현에 대한 자세한 정보는 RFC 2390[4]을 참조하자.

 

3-3. DHCP ARP

DHCP를 이용한 IPv4 자동 할당은 편리하지만, 자칫 IPv4 주소의 충돌이라는 문제를 발생시킬 우려가 있다.

이 문제를 미연에 방지하기 위해 DHCP ARP가 RFC 2131[5]을 통해 정의되었다.

 

DHCP ARP는 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: 0.0.0.0

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Assigned-IP-Addr

 

여기서 출발지 프로토콜 주소가 0.0.0.0인 것은 이 ARP Request를 수신한 장비들이 자신의 ARP Cache Entry를 갱신하지 않도록 하기 위해서이며 (When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender’s hardware address, and 0 as the sender’s IP address, to avoid confusing ARP caches in other hosts on the same subnet.[6]) 이 요청에 대한 ARP Reply를 수신하지 못한다면 클라이언트는 할당받은 IP 주소를 사용할 것이다.

RFC 2131은 또한 ‘IP 주소의 갱신을 다른 시스템에게 보고하기 위해 ARP Reply를 브로드캐스팅하여 다른 시스템이 오래된 ARP Entry를 갱신하도록 해야 한다’ ( The client SHOULD broadcast an ARP reply to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet.[7])고 규정하고 있으나, 대부분의 시스템에서는 Gratuitous ARP라 불리는 ARP Request를 이용해 이 기능을 구현하고 있다.

 

3-4. Gratuitous ARP (gARP)

Gratuitous ARP (이하 gARP)는 자신의 IP나 MAC이 변동되어, 같은 서브넷 내의 다른 장비들의 ARP Cache Entry를 갱신할 필요가 있을 때 사용된다.

예를 들어 DHCP로부터 새로운 IP를 할당받았거나, VRRP에서 Active Router를 변경할 때, 클라이언트에서 2개의 NIC를 이용하여 고가용성(HA) 구성을 하였을 경우 등이 있다.

 

gARP 패킷은 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: Client-IP-Addr

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Client-IP-Addr

 

DHCP ARP 와는 다르게 출발지 프로토콜 주소 필드가 자신의 IP 주소로 설정되었다는 것을 알 수 있다.

gARP는 앞서 말했듯이 오래된 ARP 캐시 엔트리의 갱신이 목적이기 때문에 ARP Reply가 돌아오는 것을 기대하지 않지만, 만약 Reply가 돌아온다면 IP 주소가 충돌한다는 것을 의미하게 되므로 적절한 대처가 요구된다.

 

3-5. ARP Probe

ARP Probe는 IPv4 주소의 충돌을 감지하기 위한 수단으로써, RFC 5227[8]에 정의되어 있다.

ARP Probe는 기본적으로 DHCP ARP와 동일한 구성을 가지는데, 이것은 ARP Probe가 DHCP ARP를 참조했기 때문이다. (The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131: [9])

RFC 5227에서는 DHCP ARP를 확장하여, ‘IPv4를 할당받는 모든 경우에 ARP Request를 전송하도록'(Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means)[10]) 규정하고 있으며

RFC 2131의 모호함을 (the DHCP specification does not give any guidance to implementers[11]) 해결하였다.

 

3-5.1. ARP Probe의 동작

ARP Probe는 크게 Probing – Announcing – Conflict Detection and Address Defense의 순으로 이루어진다.

먼저, Probing은 DHCP ARP의 패킷 구성을 따르되, IP 할당 이후 0~1초 사이의 랜덤한 시간을 대기한 뒤 3개의 Probing Packet을 전송한다. 이 Probing Packet의 사이에는 1~2초 사이의 임의의 시간 간격을 준다.

마지막 Proving Packet을 전송하고 2초가 지난 뒤에도 ‘Sender IP Address’가 할당받은 IP인 ARP Packet(Request/Reply)이 도착하지 않으면, 클라이언트는 이 IP를 사용해도 된다고 판단, ARP Announcement 패킷-gARP와 동일-을 전송하고, 마지막 단계인 Conflict Detection and Address Defense로 천이한다.

 

Conflict Detection and Address Defense 단계에서 호스트는 Sender IP Address가 자신이 할당받은 IP이면서 Sender Hardware Address가 자신이 아닌 ARP 패킷이 들어오는지를 계속 확인한다.

만약 그러한 패킷이 발견되면, 호스트는 다음 3가지 중 하나의 동작을 취한다.

 

A. 즉시 그 IP 주소의 사용을 포기한 뒤, 설정 Agent(e.g. DHCP Server)에게 오류를 보고한다.

B. 현재 열려있는 TCP 세션이 있어서 IP를 포기할 수 없고, 10초가 지나도 다른 문제가 되는 ARP 패킷이 들어오지 않는다면 그 IP를 계속 사용하도록 결정할 수 있다. 그리고 ARP Announcement 패킷을 한번 더 전송한다. 만약 추가로 문제가 되는 ARP 패킷이 들어오면 호스트는 즉시 그 IP를 폐기하고, 오류를 Agnet에게 보고한다.

C. 만약 이 클라이언트가 네트워크에서 매우 중요한 시스템(e.g. Default Gateway)이어서 IP를 무슨 일이 있어도 포기할 수 없다면, 이 IP를 계속 사용하도록 결정할 수 있다. 이 경우 클라이언트는 Sender-MAC-Addr와 같은 정보를 로그에 기록하고, 네트워크 관리자에게 문제를 알려야 한다. 10초가 지나도 문제가 되는 ARP 패킷이 추가로 유입되지 않으면, 호스트는 ARP Announcement를 1회 전송하고 이 IP를 계속 사용할 수 있다. 만약 10초 이내에 다시 문제가 되는 ARP 패킷이 유입되면, 호스트는 IP  Defense loop를 방지하기 위해 ARP Announcement를 전송해서는 안 된다.

 

 

3-6. UnARP

UnARP는 Proxy ARP 환경에서의 ARP Cache Invaild 문제를 해결하기 위해 RFC 1868[12]을 통해 제시되었고, 현재 실험 프로토콜(Experimental Protocol)로 지정되어 있다.

RFC 1868은 현재 사용되는 timeout을 통한 ARP Entry 제거 방식 대신 클라이언트가 네트워크로부터 접속을 종료할 때, 그것을 명시적으로 ARP를 통해 알리는 것을 골지로 하며, 실험 프로토콜의 특성상 이것을 준수하는 장비는 잘 없다.

 


각주

[1] https://tools.ietf.org/html/rfc1122#page-22

[2] http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-1

[3] https://tools.ietf.org/rfc/rfc903.txt

[4] https://tools.ietf.org/html/rfc2390

[5] https://tools.ietf.org/html/rfc2131

[6] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[7] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[8] https://tools.ietf.org/html/rfc5227

[9] RFC 5227 – Section 1 (Introduction) : https://tools.ietf.org/html/rfc5227#section-1

[10] RFC 5227 – Section 2.1 : https://tools.ietf.org/html/rfc5227#section-2.1

[11] RFC 5227 – Section 1 : https://tools.ietf.org/html/rfc5227#section-1

[12] https://tools.ietf.org/html/rfc1868

 

라우터/스위치의 구조

인터넷이라는 거대한 통신망을 구성하고 있는 여러 프로토콜의 동작을 이해하려면 가장 먼저 실제로 데이터를 전송하는 장비들인 라우터와 스위치에 대한 이해가 필요하다.

이 글은 내가 네트워크 공부를 하면서 느꼈던 가장 큰 어려움인 ‘왜?’라는 질문에 대한 답이며, 그 때의 나와 같은 어려움을 겪고 있을 누군가를 위해 쓰여졌다.

라우터의 구성요소에 대해 체계적이고 자세한 정보를 올려주신 ‘넷매니아즈 (http://netmanias.com)’ 에 무한한 감사를 보낸다.


목차

  1. Introduction
  2. 라우터의 하드웨어 구성 요소
  3. 통신 시나리오

 

 

1. Introduction

우리는 네트워크로 전송된 패킷이 스위치와 라우터 사이를 계속 건너가면서 상대방 컴퓨터에 도달한다고 배웠다. 그리고 그 과정에서 ARP/MAC/IP 등등의 프로토콜을 통해 목적지를 식별할 수 있다고 배웠다.
그러나, 난 이것을 듣고 가장 먼저 의문이 들었다.

“클라이언트는 서버의 MAC을 어떻게 알 수 있을까?”, “IP 주소만으로 어떻게 목적지를 찾을 수 있을까?”

아직 캡술화(Encapsulation)와 라우팅 프로토콜에 대한 개념이 제대로 잡혀있지 않았기 때문에 생긴 의문이지만, 이것을 제대로 이해하는 것에는 상당한 시간과 노력이 필요했다.
그리고 실제로 이 기능을 구현한 장비의 작동 로직을 파악함으로써 완전한 이해에 도달할 수 있었다.

이 글은 아무것도 모르는 사람을 위해 작성된 것은 아니다. 이 글을 이해하려면 최소한 Lan Switching에 대한 지식은 갖추고 있어야 할 것이다.

그렇지만, 만약 당신이 지식은 갖고 있지만 스위칭과 라우팅의 명확한 개념을 잡지 못 하고 있다면, 이 글이 많은 도움이 될 것이라고 나는 확신한다.

 

2. 라우터의 하드웨어 구성 요소

Supervisor Engine
라우터의 핵심 기능을 가지고 있는 모듈로, Layer3 이상의 제어를 담당하며, Control Plane으로 불리기도 한다.
보통 범용 CPU 위에 여러 가지 기능을 수행하는 OS(IOS/JUNOS)가 올라가며, RIB/LSDB/ARP Table/MAC Table 등의 정보와, 라우팅, Management 등의 기능을 수행하는 프로세스들이 동작하는 모듈이다.

Line Card
패킷 송수신, QoS 등의 기능을 수행하는 모듈로, 실제 믈리 계층과의 연동을 맡는다. 이를 위해 FIB(Forwarding Information Base), MAC Table 등이 존재하며, 패킷을 실제로 처리하는 Packet Processor와 입/출력 패킷을 임시로 저장하는 Ingress Packet Buffer와 Egress Packet Buffer가 존재한다.
Data Plane으로 불리기도 한다.

Switch Fabric Module
Line Card간에 패킷을 전달하기 위한 가교 역할을 한다. Module 형태로 구현된 장비들의 경우, Line Card의 개수가 여러 개일 수 있는데, (Ex. Fa 0/1, Fa 1/1) 이들 사이의 데이터 전송에 이용된다.

3. 통신 시나리오

Host A가 Router B를 통해 Host C로 IP 패킷을 전송하는 사나리오를 이용해 라우터가 어떻게 동작하는지 알아보자.

Router_Structure

1. Host A가 Host C로 데이터를 보내려고 하지만 상대방의 MAC Address를 모르므로 먼저 ARP Request를 보낸다.

2-1. Router B의 Line Card #0에 Host A가 보낸 ARP Request가 도착한다.

2-2. Line Card #0의 Packet Processor는 ARP Request의 L2 헤더를 검사, 자신의 MAC Address Table에 Host A의 MAC이 존재하지 않는 것을 확인하고, Source MAC Learning Event를 발생시킨다. 이는 Control Plane으로 전달되어 CP의 MAC Address Table에 Host A의 MAC이 기록되고, Line Card #0의 MAC Address Table에도 같은 정보가 기록된다.

2-3. 해당 패킷이 ARP임을 Ether-Type Field(0x0806)을 통해 확인한 Packet Processor는 이 패킷을 Supervisor Engine으로 올려보낸다.

2-4. Line Card #0에서 보내온 ARP Request를 받은 Supervisor Engine은 자신의 ARP Entry를 확인한 뒤, ARP Table에 Host A의 MAC/IP Address와 인터페이스(Fa 0/1)를 기록한다.

2-5. 해당 요청이 ARP Request임을 확인한(ARP Operation Field) Supervisor Engine은 Line Card들에게 이 패킷이 들어온 인터페이스를 제외한 모든 인터페이스로 이 패킷을 Flooding 할 것을 지시한다.

2-6. Fa 0/0을 제외한 다른 모든 인터페이스로 ARP Request가 전송되고, Fa 1/0에 연결되어 있는 Host B가 이 패킷을 수신, ARP Reply를 내보낸다.

2-7. Line Card #1은 Host B의 ARP Reply를 수신, 자신의 MAC Address Table에 Host B의 MAC이 존재하지 않는 것을 확인하고 MAC Address Learning Event를 발생시킨다.

2-8. –MAC Learning, ARP 식별 설명 생략- Supervisor Engine은 자신의 FIB(Fowarding Information Base)를 참조, 이 Unicast 패킷이 Fa 0/0으로 전달되어야 함을 확인, Line Card #0에게 이 패킷을 Fa 0/0으로 내보낼 것을 지시한다.

2-9. Host A가 Host C의 ARP Reply를 수신, 자신의 ARP Table에 Host C의 MAC을 기록한다.

3. Host A와 C는 Ethernet Switching을 통해 통신한다.

CCNA Study – Lan Switching

 

이 글은 Switch에서 L2 Switching이 어떻게 처리되는지를 서술한다.

그리고 Cisco사의 장비를 예시로 설정법을 알아본다.

 

목차

 

 

1. Ethrnet의 역사

우리가 사용하는 Ethernet Frame은 대부분 1983년에 국제 표준이 된 Ethernet II (DIX 2.0)을 따른다. 802.3에서 802.3ab에 이르기까지, Ethernet Frame은 거의 변하지 않은 모습을 보인다. 그런데, DIX 2.0은 어떻게 만들어지게 된 것일까?

Ethernet은 1974년에 ALOHA 네트워크의 CSMA 아키텍쳐에 영감을 받은 Xerox사의 연구자들에 의해 개발되었다. 이들이 만들어낸 프로토콜은 ‘Xerox 시험 네트워크’를 거치면서 실증되었고, 그 이후 Intel과 DEC를 끌어들여 1980년, Data Link layer와 Physical Layer를 정의하고 48비트의 주소와 16비트의 Ether-type 필드를 골지로 한 DIX 1.0 프로토콜을 발표하였다. 그리고 1982년, 이들은 DIX 1.0의 개정판인 DIX 2.0을 발표, 이는 Ethernet II라는 이름으로 알려지게 되고, 이 프로토콜은 IEEE의 근거리 통신용 프로토콜 표준 작업인 802.3에 지대한 영향을 끼쳐, 거의 동일한 프로토콜이 1983년 IEEE 802.3으로 승인된다.

 

2. Ethernet Frame, L2 Switching

OSI 7 Layer중 두번째인 Data Link Layer에서 데이터가 어떻게 처리되는지를 알아보자.

Data Link Layer의 프로토콜 중 하나인 Ethernet에서 데이터의 단위는 Frame이다. 앞으로 Ethernet 데이터를 지칭할 때는 Frame이라고 하겠다.

 

Ethernet Frame의 구조는 다음과 같다.

  1. Preamble (7Byte)
  2. SOF or SFD (1Byte)
  3. Destination MAC Address (48bit)
  4. Source MAC Address (48bit)
  5. Ethernet Type (16bit)
  6. L3 Data
  7. Padding (Optional)
  8. CRC (32bit)
All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

이러한 순서로 구성된 이더넷 프레임은 L3 Protocol Data를 안에 품고 있는 형태가 된다. 이를 캡슐화(Encapsulation)라고 하며, 계층 사이의 독립성을 보장하는 기능을 한다.

이 중 Preamble은 10101010(2)의 나열로 이루어진 신호로, 송/수신측의 비트 동기화에 이용된다. Preamble의 바로 뒤에 오는 10101011(2)이라는 신호를 SOF(Start of Frame)이라고 부르며, 이 뒤에 이더넷 프레임이 온다는 것을 알린다.

또한, Dst-MAC, Src-MAC 다음에 오는 Ethernet Type의 값이 0x600보다 작으면 IEEE 802.2 LLC의 확장인 SNAP PDU가 되고, 이 값이 0x600보다 크면 Ethernet II (DIX 2.0) Frame이 된다. Ethernet II의 Ethernet Type은 이 프레임이 어떠한 상위 계층 프로토콜을 포함하고 있는 것인지를 알려준다.

그 중 대표적인 프로토콜은 다음과 같다.

0x0800 IPv4

0x0806 ARP

0x8100 VLAN Tag

0x8864 PPPoE

여기서 0x8100(VLAN Tag)은 TPID(Tag Protocol Identifier)라고 불리며, 그 뒤에 VLAN(802.1Q)와 QoS(802.1p)정보를 담은 TCI(Tag Control Information)가 온다는 것을 알린다. 그리고 TCI (16bit)가 지난 뒤에 다시 Ethernet Type (16bit)이 나와 L3 프로토콜을 지정한다.

자세한 IEEE 802.1q Frame의 구조는 이 글의 범위를 벗어나므로 여기서는 다루지 않겠다. 앞으로 VLAN Tagging을 공부할 때 다시 확인할 수 있을 것이다.

마지막으로 Padding은 Destination MAC부터 CRC까지의 Ethernet Frame의 크기가 64Byte보다 작을 경우에 추가되는데, 이것은 802.3의 CSMA/CD 알고리즘에서 Collision Detect를 위한 slot time을 보장하기 위한 최소 길이가 64byte인 것에 기인한다. 단, 전송률이 더욱 올라간 Gigabit Ethernet (802.3ab)에서는 최대 케이블 길이를 줄이는 것 대신(10M 이하로 줄어든다!) 프레임의 최소 길이는 64Byte로 유지하되, 512Byte에 미달할 경우 CRC 정보 뒤에 임의의 Symbol을 채워주도록 하였고, 이를 Carrier Extension이라고 한다.

이더넷 프레임의 구조를 알았으니,  실제로 L2 장비에서 이더넷 프레임이 어떻게 처리되는지를 알아보자.

 

1. Host A가 Switch B의 Fa 0/1 인터페이스로 프레임을 보낸다. 이 때 Source MAC Address는 Host A 자신의 MAC을, Destination MAC Address는 Host B의 MAC을 사용한다.

2. Switch B의 Line Card의 Fa 0/1로 이더넷 프레임이 들어온다. Switch B는 자신의 ARP Table을 확인하고 만약 Table에 Source MAC이 존재하지 않으면 Source MAC Learning Event를 발생시켜 Control Module의 ARP Table에 Source MAC을 기록하고, 자신의 ARP Table에도 Source MAC을 기록한다. 이렇게 Dynamic으로 기록된 MAC은 기본값으로 300초간 저장된다.

3. Line Card의 Packet Processor는 이 Ethernet Frame을 열어보고 목적지가 자신의 MAC과 일치하는지 확인한다. 이 경우에는 아니므로 프레임은 Ethernet Switching 되어야 하고, Packet Processor는 Switching을 위해 자신의 ARP Table을 참조한다. 만약 ARP Table에 Dst-MAC이 있으면 라인 카드는 프레임을 그 인터페이스로 포워딩하고, Dst-MAC이 없다면 프레임을 자신의 모든 인터페이스로 플러딩한다. (설명의 편의를 위해 이 스위치의 라인 카드의 수는 하나로 가정한다)

4. Host B가 Host A가 보낸 이더넷 프레임을 수신한다.

3. Cisco Switch에서의 Ethernet 설정

여기서 나오는 명령어들은 Cisco사의 Catalyst 2950 스위치를 기준으로 한다.

interfaceinterface port (range) (port Number)

Global Configuration 모드에서 사용하며, 스위치의 인터페이스 설정 모드로 들어간다. range 명령이나 하이픈(-)을 사용하여 여러 인터페이스를 동시에 설정할 수 있다.

duplexduplex auto/full/half

Interface Configuration 모드의 하위 명령어로, 이 인터페이스 포트가 어떠한 Duplex 모드로 동작할 것인지를 결정한다. 기본값은 auto이며, Interface Config에서 full-duplex, half-duplex를 입력하는 것으로도 동작 모드를 변경할 수 있다.

bandwidthbandwidth number (1 – 10000000)

Interface Configuration 모드의 하위 명령어로, 이 인터페이스에 할당된 Bandwidth를 지정한다. 여기서 유의할 점은 bandwidth 명령어로 설정하는 대역폭은 실제 링크 속도와는 관계가 없다는 것이다. 이 설정값은 EIGRP, OSPF 라우팅 프로토콜이 해당 인터페이스의 Metric 값을 결정하는 것에 영향을 미친다.