System Programming/Linux Device Driver
Netlink Sockets #1 내부 아키텍쳐, 메세지 포맷
uzguns
2024. 10. 27. 02:21
Netlink는 Linux kernle 내부 메세징 시스템으로 kernle과 user space 간의 통신 수단으로 사용된다.
■ Linux의 IP 패킷 포워딩 절차
____ +---------------+
+->-| FW |---> | TCP, UDP, ... |
| +----+ +---------------+
| |
^ v
| _|_
+----<----+ | FW |
| +----+
^ |
| Y
To host From host
stack stack
^ |
|_____ |
Ingress ^ Y
device ____ +-------+ +|---|--+ ____ +--------+ Egress
->----->| FW |-->|Ingress|-->---->| Forw- |->| FW |->| Egress | device
+----+ | TC | | ard | +----+ | TC |-->
+-------+ +-------+ +--------+- Ingress Device (입력 장치): 네트워크 인터페이스를 통해 들어오는 패킷이 가장 먼저 도달하는 부분
- Firewall (FW):
- 입력 방화벽: Ingress device에서 들어오는 패킷은 먼저 방화벽 모듈을 통과한다. 이 방화벽에서 패킷은 드롭될 수도 있고, 변경(munged)될 수도 있다.
- 출력 방화벽: 출발지 장치에서 나가는 패킷은 최종적으로 이 방화벽 모듈을 통과한다.
- Ingress Traffic Control (Ingress TC): 패킷이 방화벽을 통과한 후에는 Ingress Traffic Control 모듈을 통과하게 된다. 이 모듈은 트래픽 제어, 계측, 그리고 폴리싱(policing)을 담당한다. 이 모듈에서의 설정에 따라 패킷이 드롭될 수 있다.
- Forwarding Module: 패킷이 통과하는 유일하게 필수적인 모듈. RFC 1812에 따라 동작하며, 패킷이 라우팅 또는 전달되기 위한 필수적인 처리 과정을 거친다.
- 만약 패킷이 이 모듈을 통과하지 못하면(비준수로 인해) 드롭된다.
- 이 모듈은 또한 패킷을 호스트 스택으로 보낼지, 아니면 계속 전달할지 결정하는 분기점으로 호스트 스택으로 보내는 경우는 패킷이 시스템 자체를 위한 것이거나 더 높은 수준의 처리가 필요할 때
- Host Stack: 패킷이 포워딩 모듈에 의해 호스트 스택으로 전달될 경우, 패킷은 다시 방화벽 및 네트워크 프로토콜 스택(TCP, UDP 등)을 통해 처리된다.
- Egress Traffic Control (Egress TC): 포워딩 모듈을 통과한 패킷은 출력을 위한 Egress Traffic Control 모듈을 통과한다. 이 모듈은 출력 트래픽을 제어하고 필요한 경우 패킷을 수정하거나 드롭할 수 있다.
- Egress Device (출력 장치): 패킷이 최종적으로 나가는 인터페이스. 모든 처리가 끝난 후, 이곳을 통해 패킷이 외부로 전송된다.
ip service는 control plane, forwarding plane 으로 네트워크에서 IP 패킷을 처리하는 방식을 정의한다. 라우팅 프로토콜과 정책 관리 시스템이 control plane에서 네트워크의 경로를 결정하고, forwarding plane에서 실제로 패킷을 전달한다. ip service의 범위는 단순한 패킷 포워딩에서 복잡한 QoS, 방화벽, NAT 처리까지 확장될 수 있다.
Control Plane (CP)
.------------------------------------
| /^^^^^^\ /^^^^^^\ |
| | | | COPS |-\ |
| | ospfd | | PEP | \ |
| \ / \_____/ | |
/------\_____/ | / |
| | | | / |
| |_________\__________|____|_________|
| | | |
******************************************
Forwarding ************* Netlink layer ************
Engine (FE) *****************************************
.-------------|-----------|----------|---|-------------
| IPv4 forwarding | | |
| FE Service / / |
| Component / / |
| ---------------/---------------/--------- |
| | | / | |
packet | | --------|-- ----|----- | packet
in | | | IPv4 | | Egress | | out
-->--->|------>|---->|Forwarding|----->| QoS |--->| ---->|->
| | | | | Scheduler| | |
| | ----------- ---------- | |
| | | |
| --------------------------------------- |
| |
-------------------------------------------------------- control plane은 IP 서비스의 경로를 결정
- 라우팅 프로토콜: OSPF, RIP 등
- 정책 관리 애플리케이션: COPS, PEP 등
- forwarding plane은 IP 패킷을 실제로 처리하는 계층
- IP 패킷이 라우팅되거나, QoS 처리 등을 거쳐 다음 hop으로 전달된다.
■ Netlink Architecture
ip service의 구성요소의 제어는 템플릿을 이용하여 정의된다.
FEC와 CPC는 이러한 템플릿을 사용하여 통신함으로써 IP 서비스를 제공할 수 있게 된다.
예를 들어 FEC 는 v4 포워딩 또는 경로 추가 및 삭제와 같은 서비스 운영 방식에 대한 업데이트를 제어 평면 구성요소(CPC)로부터 지속적으로 받을 수 있다.
Netlink 컨텍스트에서 FEC와 CPC 간의 상호작용은 프로토콜을 정의한다. Netlink 는 CPC 와 FEC가 각각의 프로토콜을 정의할 수 있는
■ Message Format
Netlink 메세지 헤더는 하나 이상의 Netlink 헤더와 관련된 페이로드로 구성된 바이트 스트림으로 이루어진다. 페이로드가 하나의 메세지에 담기에 너무 큰 경우 여러 Netlink 메세지로 나누어 전송할 수 있으며 이를 멀티 파트 메세지라고 한다.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Process ID (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Length (길이): 32 비트
- 헤더를 포함한 메시지의 바이트 단위 길이입니다.
- Type (유형): 16 비트
- 메시지 내용을 설명합니다. 표준 메시지 타입은 다음과 같습니다:
- NLMSG_NOOP: 메시지를 무시합니다.
- NLMSG_ERROR: 오류를 알리는 메시지로, 페이로드에 nlmsgerr 구조체가 포함됩니다. 이는 NACK로 볼 수 있으며, 일반적으로 FEC에서 CPC로 전달됩니다.
- NLMSG_DONE: 멀티파트 메시지를 종료하는 메시지입니다.
- 각 IP 서비스는 여러 메시지 타입을 정의할 수 있습니다. 예를 들어 NETLINK_ROUTE 서비스는 RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE, RTM_DELROUTE 등 여러 타입을 제공합니다.
- 메시지 내용을 설명합니다. 표준 메시지 타입은 다음과 같습니다:
- Flags (플래그): 16 비트
- Netlink에서 사용되는 표준 플래그 비트는 다음과 같습니다:
- NLM_F_REQUEST: 모든 요청 메시지에 설정해야 하며, 일반적으로 사용자 공간에서 커널 공간으로 보냅니다.
- NLM_F_MULTI: 멀티파트 메시지의 일부임을 나타내며, NLMSG_DONE으로 종료됩니다.
- NLM_F_ACK: 성공 시 확인을 요청합니다. 일반적으로 사용자 공간(CPC)에서 커널 공간(FEC)으로 요청이 전달됩니다.
- NLM_F_ECHO: 요청을 에코합니다. 일반적으로 사용자 공간(CPC)에서 커널 공간(FEC)으로 요청이 전달됩니다.
- FEC에서 구성 정보를 조회하는 GET 요청에 대한 추가 플래그:
- NLM_F_ROOT: 단일 항목 대신 전체 테이블을 반환합니다.
- NLM_F_MATCH: 메시지 내용에 포함된 기준에 맞는 모든 항목을 반환합니다.
- NLM_F_ATOMIC: 참조하는 테이블의 원자적 스냅샷을 반환합니다. 이 기능은 FE에서 서비스를 장시간 중단할 가능성이 있기 때문에 특별한 권한이 필요할 수 있습니다.
- 플래그 비트의 편의를 위한 매크로:
- NLM_F_DUMP: NLM_F_ROOT와 NLM_F_MATCH를 OR 연산으로 결합한 값입니다.
- NEW 요청을 위한 추가 플래그 비트:
- NLM_F_REPLACE: 이 요청을 통해 기존 일치하는 구성 객체를 대체합니다.
- NLM_F_EXCL: 구성 객체가 이미 존재할 경우 대체하지 않습니다.
- NLM_F_CREATE: 구성 객체가 존재하지 않으면 생성합니다.
- NLM_F_APPEND: 객체 목록의 끝에 추가합니다.
- BSD 스타일의 라우트 소켓 사용과의 대응:
- BSD ADD 연산은 NLM_F_CREATE와 NLM_F_EXCL의 OR 연산에 해당합니다.
- BSD CHANGE 연산은 NLM_F_REPLACE에 해당합니다.
- BSD Check 연산은 NLM_F_EXCL에 해당합니다.
- BSD APPEND는 실제로 NLM_F_CREATE에 매핑됩니다.
- Netlink에서 사용되는 표준 플래그 비트는 다음과 같습니다:
- Sequence Number (시퀀스 번호): 32 비트
- 메시지의 시퀀스 번호입니다.
- Process ID (PID): 32 비트
- 메시지를 보내는 프로세스의 PID입니다. 커널은 이를 사용하여 올바른 소켓에 멀티플렉싱합니다. PID가 0이면 커널에서 사용자 공간으로 메시지를 보낼 때 사용됩니다.