OpenFlow(오픈플로우)는 소프트웨어 정의 네트워킹(SDN, Software-Defined Networking) 환경을 구현하기 위해 사용되는 핵심적이고 표준적인 통신 프로토콜입니다.
쉽게 설명하자면, 기존 네트워크 장비(스위치, 라우터)가 스스로 하던 '판단'과 '행동'을 분리한 뒤, 중앙의 똑똑한 두뇌(컨트롤러)가 여러 장비의 행동(스위치)을 한 번에 지시하고 제어할 수 있도록 서로 대화하는 언어라고 생각하시면 됩니다.
1. 등장 배경 및 핵심 원리
전통적인 네트워크 장비는 데이터를 어디로 보낼지 계산하고 결정하는 제어부(Control Plane)와 데이터를 실제로 전달하는 전송부(Data Plane)가 하나의 하드웨어 장비 안에 통합되어 있었습니다. 이로 인해 트래픽 경로를 수정하거나 새로운 보안 정책을 적용하려면 관리자가 각 장비에 일일이 접속하여 설정해야 하는 번거로움과 비효율성이 존재했습니다.
OpenFlow는 이 두 가지 영역을 분리하는 SDN의 핵심 아이디어를 구체화합니다.
- 제어부의 중앙 집중화: 네트워크 전체를 조망하는 '두뇌' 역할을 하는 컨트롤러(Controller)를 중앙에 별도로 둡니다.
- 전송부의 단순화: 개별 스위치나 라우터는 판단 기능을 잃는 대신, 컨트롤러의 지시에 따라 패킷을 전달(Forwarding)하는 '손발' 역할에만 충실하게 됩니다.

2. OpenFlow의 주요 구성 요소
OpenFlow 아키텍처는 크게 세 가지 핵심 요소로 이루어집니다.

| 구성 요소 | 역할 및 특징 |
| SDN Controller (컨트롤러) | 네트워크 전체의 토폴로지(구조)와 트래픽을 모니터링하고 최적의 경로를 계산하여 스위치에 지시를 내리는 중앙 제어 소프트웨어입니다. |
| OpenFlow Switch (스위치) | 컨트롤러가 내려준 명령(Flow Table)에 따라 들어오는 데이터를 목적지로 전달하거나 폐기하는 하드웨어/소프트웨어 스위치입니다. |
| OpenFlow Protocol (프로토콜) | 컨트롤러와 스위치 간에 명령과 상태 정보를 주고받기 위해 사용하는 안전한 통신 규약(Secure Channel)입니다. |
3. OpenFlow의 동작 원리 (Step-by-Step)
실제 데이터(패킷)가 네트워크 스위치에 도착했을 때 OpenFlow가 어떻게 이를 처리하는지 단계별로 살펴보겠습니다.

- 패킷 도착: 외부에서 OpenFlow 스위치로 새로운 네트워크 패킷이 들어옵니다.
- Flow Table(플로우 테이블) 검색: 스위치는 내부에 저장된 규칙 목록인 '플로우 테이블'을 검색하여, 이 패킷(출발지/목적지 IP, 포트 번호 등)을 어떻게 처리해야 할지 확인합니다.
- 일치(Match) 시 즉시 처리: 테이블에 해당 패킷과 일치하는 규칙이 있다면, 명시된 행동(Action: 특정 포트로 전달, 패킷 폐기 등)을 즉시 수행합니다.
- 불일치(Miss) 시 컨트롤러에 질의: 테이블에 규칙이 없는 처음 보는 유형의 패킷이라면, 스위치는 스스로 판단하지 않고 통신 채널을 통해 컨트롤러에게 "이 패킷을 어떻게 처리할까요?"라고 묻습니다 (이를 Packet-In 메시지라고 합니다).
- 규칙 생성 및 업데이트: 전체 네트워크 상황을 파악하고 있는 중앙 컨트롤러가 해당 패킷의 최적 경로를 계산한 뒤, 스위치에게 "앞으로 이런 패킷이 오면 이렇게 처리해라"는 새로운 규칙을 내려보내어 플로우 테이블을 업데이트합니다 (이를 Flow-Mod 메시지라고 합니다). 이후 동일한 패킷들은 컨트롤러를 거치지 않고 스위치에서 즉시 고속으로 처리됩니다.
4. 구체적인 활용 예시
기업 사내 네트워크에서 "특정 부서(A팀)의 업무 시간 내 스트리밍 사이트 접속을 차단하라"는 보안 정책을 적용한다고 가정해 보겠습니다.
- OpenFlow 도입 이전: 네트워크 관리자가 A팀 주변의 수많은 개별 라우터와 방화벽 장비에 일일이 원격 접속하여 접근 제어 목록(ACL) 코드를 수정하고 반영해야 했습니다.
- OpenFlow 도입 이후: 관리자는 중앙의 SDN 컨트롤러 대시보드에서 "A팀 IP 대역 -> 스트리밍 서버 IP 트래픽 = Drop(폐기)"이라는 정책을 한 번만 입력합니다. 컨트롤러가 즉각적으로 OpenFlow 프로토콜을 통해 하위의 모든 관련 스위치들의 플로우 테이블을 동시에 업데이트하여, 빠르고 오류 없이 전사적인 정책 적용이 완료됩니다.
이러한 중앙 집중식 제어 원리 덕분에 OpenFlow는 네트워크 관리의 유연성과 자동화를 극대화하며, 현재 대규모 클라우드 데이터센터나 통신사 네트워크를 구축하는 데 없어서는 안 될 기반 기술로 자리 잡았습니다.
플로우 테이블(Flow Table)
플로우 테이블(Flow Table)은 OpenFlow 스위치 내부에 위치하여, 들어오는 네트워크 패킷을 어떻게 처리할지 결정하는 규칙(Rule)들의 집합이자 핵심 데이터베이스입니다.
기존 라우터의 '라우팅 테이블'이나 방화벽의 '접근 제어 목록(ACL)' 기능이 합쳐져 훨씬 정교해진 형태라고 볼 수 있습니다. 중앙의 컨트롤러(Controller)가 이 테이블에 규칙을 추가, 수정, 삭제하며 전체 네트워크 데이터의 흐름(Flow)을 제어합니다.
1. 플로우 테이블 엔트리(Entry)의 핵심 구조
플로우 테이블은 여러 개의 '엔트리(규칙 한 줄)'로 구성됩니다. 각 엔트리는 패킷 처리를 위해 다음과 같은 6가지 주요 필드로 이루어져 있습니다.

| 구성 요소 | 설명 | 구체적인 예시 |
| 매치 필드 (Match Fields) | 패킷이 이 규칙에 해당하는지 판별하는 조건입니다. OSI 1~4계층의 헤더 정보를 모두 조합하여 세밀한 필터링이 가능합니다. | 스위치 입력 포트, 출발지/목적지 MAC 주소, IP 주소(예: 192.168.1.10), TCP/UDP 포트 번호(예: 80) |
| 우선순위 (Priority) | 들어온 패킷이 여러 엔트리의 매치 필드와 동시에 일치할 경우, 어떤 규칙을 최우선으로 적용할지 결정하는 순위입니다. | Priority 100 (숫자가 클수록 높은 우선순위를 가짐) |
| 카운터 (Counters) | 해당 규칙에 일치하여 처리된 패킷의 개수, 누적 바이트(Byte) 수, 규칙이 유지된 시간 등의 통계 정보를 기록합니다. | 누적 처리 패킷: 1,500개, 누적 전송량: 3MB |
| 명령 (Instructions) | 매치 필드와 일치하는 패킷에 대해 스위치가 수행해야 할 일련의 동작 지침입니다. 액션을 즉각 실행하거나 패킷을 다음 테이블로 넘깁니다. | "즉시 액션(Action)을 적용하라", "다음 테이블(Table 2)로 이동시켜라" |
| 액션 (Actions) | 패킷에 가해지는 실질적인 물리적/논리적 조작입니다. | 특정 스위치 포트로 전송(Forward), 패킷 폐기(Drop), VLAN 태그 추가, IP/MAC 주소 변환 |
| 타임아웃 (Timeouts) | 해당 규칙이 테이블에 유지되는 수명입니다. 하드웨어 메모리 낭비를 막기 위해 사용됩니다. | 300초 동안 매치되는 패킷이 없으면 규칙 삭제(Idle Timeout) |
2. 다중 테이블과 파이프라인 처리 (Pipeline Processing)
OpenFlow 1.1 버전부터는 복잡한 네트워크 정책을 하나의 테이블에서 처리할 때 발생하는 과부하를 막기 위해 다중 테이블(Multiple Tables) 구조가 도입되었습니다.
- 패킷이 스위치에 들어오면 항상 Table 0부터 순차적으로 처리를 시작합니다.
- Table 0에서 특정 조건을 검사한 뒤, 명령(Instructions) 필드의 지시에 따라 Table 1, Table 2 등으로 패킷을 보내어(Go-To-Table) 단계별로 처리를 이어나갑니다.
- 이러한 방식을 통해 스위치는 'L2 포워딩(Table 0) -> 방화벽 접근 제어(Table 1) -> QoS 품질 제어(Table 2)'와 같은 일련의 파이프라인 처리를 논리적이고 체계적으로 수행할 수 있습니다.
3. 테이블 미스 (Table-Miss) 처리 원리
패킷이 들어왔는데 플로우 테이블의 어떤 매치 필드와도 일치하지 않는 경우를 테이블 미스(Table-Miss)라고 합니다. 스위치는 규칙이 없는 패킷을 마주했을 때 수행할 기본 행동(Table-Miss Flow Entry)을 우선순위 0으로 설정해 둡니다.
- 컨트롤러로 전송 (Packet-In): 스위치가 스스로 처리 방법을 모르므로, OpenFlow 채널을 통해 컨트롤러에게 패킷 헤더를 보내어 "새로운 길을 알려달라"고 요청합니다. 가장 일반적인 방식입니다.
- 패킷 폐기 (Drop): 보안 정책상 허용되지 않은 알 수 없는 패킷으로 간주하여 즉시 버립니다.
- 다음 테이블로 전달 (Go-To-Table): 현재 테이블에서는 매칭되지 않았지만, 파이프라인의 다음 테이블로 넘겨 추가로 검사하게 합니다.
4. 구체적인 동작 예시
외부에서 사내 웹 서버(10.0.0.1)로 향하는 HTTP(포트 80) 접속 요청 패킷이 스위치에 도착했다고 가정해 보겠습니다.
- 매치 필드 검색: 스위치는 패킷의 헤더를 읽고 Table 0을 검색하여 [목적지 IP: 10.0.0.1, TCP 목적지 포트: 80]이라는 조건이 있는지 찾습니다.
- 일치 및 액션 수행: 테이블에서 해당 조건과 일치하는 엔트리를 발견합니다. 이 엔트리의 액션 필드에는 [출력: 포트 5번]이라고 명시되어 있습니다.
- 카운터 증가: 해당 엔트리의 처리 통계(패킷 수 +1)가 카운터에 실시간으로 기록됩니다. 이 정보는 추후 컨트롤러가 네트워크 트래픽 통계를 모니터링할 때 사용됩니다.
- 전송 완료: 스위치는 컨트롤러에 질의하는 지연 시간 없이, 하드웨어 속도로 즉시 패킷을 5번 포트로 내보내어 웹 서버로 향하게 합니다.
'시스템구조' 카테고리의 다른 글
| Bitcoin 기반 블록체인 (0) | 2026.02.22 |
|---|---|
| 쿠버네티스(Kubernetes, K8s) (0) | 2026.02.21 |
| [디지털 전송] 라인 코딩 (Line Coding) (0) | 2026.02.16 |