라우터 내부에서 일어나는 일 | Notes

📡 입력 포트, 스위칭, 출력 포트

라우터 아키텍처 개요

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.26.03.png

라우터의 아키텍처는 크게 **제어 평면(control plane)**과 **데이터 평면(data plane)**으로 구성된다. 제어 평면은 주로 소프트웨어로 구현되며, 라우팅 결정과 네트워크 관리 기능을 담당한다. 이 영역은 **라우팅 프로세서(routing processor)**에 의해 수행되며, 밀리초 단위의 시간 프레임에서 동작한다. 여기서 라우팅 알고리즘이 실행되고, 포워딩 테이블이 계산된다.

반면, 데이터 평면은 하드웨어 중심으로 구성되며, 패킷 전달을 매우 빠른 속도로 처리하는 것이 목적이다. 이 영역은 입력 포트와 출력 포트, 그리고 그 사이를 연결하는 **고속 스위칭 패브릭(switching fabric)**으로 구성된다. 수신된 패킷은 입력 포트에서 처리된 후, 스위칭 패브릭을 통해 적절한 출력 포트로 전달되며, 이 전체 과정은 나노초 수준의 시간 프레임에서 이루어진다. 데이터 평면은 오직 패킷 전달에 집중하고, 제어 평면에서 계산된 포워딩 테이블에 따라 행동한다.

이러한 구조 덕분에 라우터는 한편으로는 전체 네트워크 토폴로지를 바탕으로 경로를 계산하고, 다른 한편으로는 계산된 결과에 따라 빠르게 패킷을 전송하는 두 가지 기능을 병렬적으로 수행할 수 있다. 제어 평면은 느리지만 지능적이고, 데이터 평면은 단순하지만 매우 빠르다는 특성이 이 구조의 핵심이다.

입력 포트 기능

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.26.12.png

입력 포트(input port)는 수신된 데이터그램이 라우터 내부를 통과하기 전에 수행해야 할 여러 기능을 처리하는 중요한 구성 요소다. 가장 먼저 물리 계층에서 비트 수준의 데이터를 수신하고, 이후 링크 계층에서 이를 프레임 단위로 재구성한다. 이 과정에서 사용하는 링크 계층 프로토콜은 이더넷과 같이 다양한 방식이 될 수 있으며, 전송되는 데이터가 네트워크 계층으로 올라올 수 있도록 처리한다.

프레임이 재구성되면, 입력 포트는 패킷의 헤더 정보를 분석해 포워딩 테이블을 조회하고, 이 패킷이 어느 출력 포트로 나가야 할지를 결정한다. 이 작업은 중앙 제어 방식이 아닌 **분산된 방식(decentralized switching)**으로 수행되며, 라우터 내부의 각 입력 포트 메모리에 있는 포워딩 테이블을 직접 참조해 처리된다. 이 구조는 중앙의 라우팅 프로세서를 거치지 않기 때문에, 매우 빠른 속도로 전송률(line speed)을 유지하면서 포워딩 결정을 내릴 수 있다.

패킷의 전달 경로가 결정되면, 해당 데이터그램은 **스위칭 패브릭(switch fabric)**으로 전달된다. 하지만 입력 포트로 들어오는 데이터그램의 속도가 스위칭 패브릭을 통과할 수 있는 속도보다 빠를 경우, **입력 포트 큐잉(input port queuing)**이 발생하게 된다. 이때 큐에 패킷이 일시적으로 저장되며, 혼잡이 심할 경우 지연이 생기거나 패킷이 손실될 수 있다. 입력 포트는 이렇게 전처리, 포워딩 결정, 큐잉까지 다양한 기능을 수행하며 전체 라우팅 처리 속도에 직접적인 영향을 미친다.

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.26.20.png

분산형 스위칭(decentralized switching)은 각 입력 포트가 독립적으로 포워딩 결정을 내리는 방식으로, 중앙의 제어 장치나 라우팅 프로세서를 거치지 않고 입력 포트 메모리에 저장된 포워딩 테이블을 직접 조회하여 패킷의 출력 포트를 결정한다. 이 방식은 패킷의 헤더 필드 값을 읽고, 이에 해당하는 동작을 지정하는 “매치(match) + 동작(action)” 구조로 동작한다. 덕분에 입력 포트는 **라인 속도(line speed)**로 빠르게 처리를 수행할 수 있다.

전통적인 방식에서는 **목적지 기반 포워딩(destination-based forwarding)**을 사용해, 목적지 IP 주소만을 기준으로 출력 포트를 선택한다. 하지만 보다 유연한 네트워크 제어를 위해, 오늘날에는 일반화된 포워딩(generalized forwarding) 개념이 도입되어, 목적지 주소뿐만 아니라 다양한 헤더 필드(예: 출발지 주소, 포트 번호, 프로토콜 타입 등)를 기준으로 포워딩 결정을 내릴 수 있다. 이를 통해 트래픽 필터링, QoS 정책, 네트워크 가상화 등 다양한 고급 기능이 가능해진다.

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.26.36.png

Destination-based forwarding은 라우터가 패킷의 목적지 IP 주소를 기반으로 포워딩 테이블을 참조하여, 해당 패킷이 어느 출력 인터페이스로 나가야 하는지를 결정하는 전통적인 방식이다. 이때 포워딩 테이블에는 목적지 주소 범위(Destination Address Range)와 해당 범위에 속하는 패킷을 어느 링크 인터페이스(Link Interface)로 전달할 것인지에 대한 정보가 포함되어 있다.

예를 들어 목적지 주소가 11001000 00010111 00010000 00000110이라면, 이 주소가 어느 범위에 속하는지 포워딩 테이블에서 찾은 후, 해당 항목에 지정된 인터페이스로 패킷을 전송하게 된다. 위 예시에서는 특정 주소 범위가 인터페이스 3, 다른 범위가 인터페이스 2로 매핑되어 있으며, 그 외의 경우에는 “otherwise” 규칙에 따라 기본 경로(default route)를 따를 수 있다.

하지만 현실에서는 주소 범위가 꼭 예쁘게 나누어지지 않는다. 즉, 주소들이 명확히 구분되는 정돈된 블록으로 정렬되어 있지 않거나, 여러 범위가 겹칠 수도 있다. 이럴 때는 가장 구체적인(prefix가 가장 긴) 항목을 우선하는 longest prefix match 방식이 적용된다. 포워딩 테이블의 각 항목은 일반적으로 CIDR 형식의 주소(prefix/length)로 표현되며, 라우터는 입력된 목적지 IP 주소와 가장 많이 일치하는 접두사를 가진 항목을 찾아 출력 인터페이스를 결정한다. 따라서 포워딩 테이블이 겹치거나 정렬되지 않아도, 정확하고 일관된 라우팅 결정을 내릴 수 있다.

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.26.52.png

Longest prefix matching은 라우터가 포워딩 테이블에서 목적지 주소에 가장 많이 일치하는 주소 접두사(prefix)를 찾아, 해당 항목에 지정된 링크 인터페이스로 패킷을 전달하는 방식이다. 이 방식은 여러 항목이 동시에 일치할 수 있는 상황에서, 가장 구체적인(=가장 긴 접두사를 가진) 경로를 선택함으로써 정확하고 효율적인 라우팅을 가능하게 한다.

예시를 통해 살펴보면 다음과 같다.

목적지 주소:

11001000 00010111 00010110 10100001

이 주소를 보고 포워딩 테이블 항목과 비교할 때, 여러 항목이 앞부분에서 일치할 수 있다. 예를 들어:
- 11001000 00010111 00010******* → 길이 20비트 일치
- 11001000 00010111 00011******* → 길이 20비트 일치
- 11001000 00010111 00011000******** → 이 경우에는 앞 24비트 이상 일치함
이 중에서 가장 긴 접두사 일치를 갖는 항목은 11001000 00010111 00011000********이므로, 해당 목적지 주소는 인터페이스 1로 전달된다.
목적지 주소:

11001000 00010111 00011000 10101010

이 경우에는 정확히 11001000 00010111 00011000********과 일치하므로, 인터페이스 1이 선택된다.

요약하면, 목적지 주소가 포워딩 테이블의 여러 항목과 일치할 수 있을 때는 단순히 첫 번째 일치 항목을 선택하는 것이 아니라, **가장 많은 비트를 일치시키는 항목(=가장 구체적인 경로)**을 선택하는 것이 longest prefix matching의 핵심 원리이다. 이 방식은 CIDR 기반의 유연한 주소 할당 구조와 잘 어울리며, 현대의 라우터들이 실제로 사용하는 방식이다.

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_11.49.09.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_11.49.14.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-06-13_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_11.49.20.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.27.23.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.28.38.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.28.48.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.28.58.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.29.05.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.29.16.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.29.24.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.29.32.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.29.42.png

📡 버퍼 관리, 스케줄링

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.30.03.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.30.16.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.30.34.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.30.52.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.31.02.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.31.12.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.31.19.png

%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2025-04-14_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.31.28.png