태그: Ethernet

Linux Network Bridge Overview

 

리눅스에서 네트워크를 구성하다 보면 흔히 브리지라는 것을 접하게 된다. 여러개의 이더넷 포트를 하나의 세그먼트로 묶어주는 역할을 하는 이 소프트웨어 장치는 과연 어떤 것일까?
이 질문에 대답하려면 먼저 컴퓨터 네트워크의 역사에서 브리지의 위치를 알아볼 필요가 있다.

1. 네트워크 브리지

초창기 컴퓨터 네트워크는 여러 인터페이스들이 서로 경쟁 관계에 있었고(Ethernet, Token Ring, FDDI..) 대부분 하나의 회선을 여러 클라이언트가 나눠 쓰는 버스(Bus) 형태의 구조를 가지고 있었다.
버스 구조에서 두 개의 버스를 가진 네트워크를 서로 연결하려면 어떤 장치가 필요할까?

버스가 물리적으로 분리되어 있다면, 그 두 회선을 연결해주는 장치가 있어야 할 것이다. 그 결과 리피터(Repeater)가 탄생하였다. -허브(Hub)라고 부르기도 한다-
리피터는 아주 단순한 장비여서, 한 포트로 수신한 전기 신호를 다른 포트로 전송해주는 일밖에 하지 못한다.
때문에 CSMA/CD를 사용하는 초창기 이더넷에서는 Collision Domain이 커지는 효과를 가져왔고, 버스의 길이를 물리적으로 연장함으로써 Detection Gap을 넘는 전파 지연 가질 위험성도 내포하고 있었다.

일이 이렇게 되니, 이 문제를 해결할 수 있는 보다 지능적인 장비가 필요했고, 리피터에 MAC 주소 학습/포워딩 결정 기능을 더한 브리지가 탄생하였다.
브리지부터는 단순히 전기 신호를 재전송하는 것이 아닌, L2 프로토콜을 해석하고, 프레임의 정보를 얻을 수 있는(주로 MAC Address) 기능을 갖게 된다.

브리지는 클라이언트들의 MAC Address를 학습하고, 목적지 클라이언트 MAC이 존재하는 네트워크의 포트로만 패킷을 전송함으로써 리피터의 문제를 해결하였다.

브리지 동작은 크게 Transparent Bridging과 Source Routed Bridging으로 나뉘는데, 우리가 흔히 접하는 것이 Transparent Bridging, 내부에 홉 순서를 가지고 있는 프레임을 처리하는 것이 Source Routed Bridging이다.
토폴로지 구성 또한 두 종류가 있는데, 일반적으로 같은 세그먼트의 LAN을 서로 연결하는 LAN Bridging과 원격지 네트워크를 서로 연결하는 Remote Bridging이 바로 그것이다.

그리고 여기서 브리지의 한계가 드러나게 된다.
일반적으로 동일한 프로토콜을 사용하는 LAN과 달리, 원격지 네트워크는 LAN과 다른 프로토콜을 사용할 수 있으며, WAN 라인은 LAN에 비해 대역폭이 좁다.
그래서 LAN에서 발생한 트래픽이 WAN 회선을 타고 원격지 네트워크로 전송될 때, WAN 회선의 대역폭을 넘는 트래픽이 전달된다면 브릿지는 잉여 프레임을 버퍼에 저장할 수 밖에 없고, 버퍼의 용량이 초과된다면 나머지 프레임들은 모두 드랍될 수 밖에 없다. 때문에 패킷 드랍이 일어나지 않도록 브리지는 가장 작은 대역폭을 가진 포트에 맞춰 모든 포트의 전송률이 결정된다.

이런 한계점은 스위치의 등장과 함께 최종적으로 해결되었는데, 스위치에서는 링크가 1:1로 연결되므로 기본적으로 다른 포트의 전송 대역폭을 신경 쓸 필요가 없어졌다.

 

2. 리눅스의 소프트웨어 브리지

그렇다면 리눅스의 브리지는 어떤 기능을 가지고 있는 것일까.
결론부터 말하자면 리눅스의 브리지는 레거시 네트워크에서 흔히 말하는 브리지가 아니라, 소프트웨어적으로 구현된 스위치이다.
리눅스 브리지는 다수의 포트를 가질 수 있으며, STP가 동작하고, 인터페이스의 대역폭이 상호 독립적이기 때문에 브리지가 아니라 스위치라고 보아야 한다.

그럼 이제 리눅스 브리지의 동작에 대해 이야기해보도록 하자.

앞서 말했듯이, 브리지 동작에는 Transparent Bridging과 Source Routed Bridging이 존재한다.
리눅스의 브리지는 이 둘 중에서 Transparent Bridging을 수행한다. 이 때문에 다중 브리지가 존재하는 환경에서는 루핑이 발생할 수 있고, STP가 구현되었다.
그리고 리눅스의 브리지는 기본적으로 Ethernet을 사용하고, Remote Bridging을 적용할 수 없다. 또한, 하나의 포트는 한번에 하나의 브리지에만 할당될 수 있다.
상용 브리지 중에서는 하나의 포트를 여러 브리지에 할당하고 포워딩 정책을 통해 전송 포트를 결정하는 경우도 있으므로, 리눅스 브리지는 최대한 단순한 구성을 취하고 있음을 알 수 있다.

현재 리눅스 커널의 메인라인에는 802.1d Ethernet Bridging이 들어가 있으며, 커널을 컴파일 할 때 브리지 모듈을 탑재하는 것으로 활성화/비활성화를 결정할 수 있다.
브리지가 활성화된 커널에서 bridge-utils을 이용하는 것으로 브리지를 설정할 수 있다. 명령어는 brctl이다.

 

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 값을 결정하는 것에 영향을 미친다.