Network 공부

+ VM (OVS, Overlay Network, Tunneling)

id1112 2025. 3. 5. 09:52

OpenVswitch 는 VM 간에 Overlay Network 를 구성할 수 있는 스위치지만 GRE(Generic Routing Encapsulation) VXLAN 등의 터널링 프로토콜을 사용한다.

이때 OVS 는 터널링 프토코콜에 포함된 건가?

아니다

OVS 자체는 가상의 스위치로 L2 Network 기능을 제공한다.

하지만 Overlay Network 를 구성하려면 GRE, VXLAN 등의 터널링을 활용해야한다.

 

근데 이미 Linux Bridge 도 L2 스위칭을 제공하는 데 OVS 를 사용하는 이유가 무엇일까?

1. Advanced Networking Features

Linux Birdge는 터널링을 기본 지원하지 않음 등등 

OVS는 단순히 L2 스위칭뿐만 아니라 SDN(software defined networking) 환경에서 유연하고 강력한 기능을 제공하는 가상 스위치이다.

 

2. Overlay Network 지원

Tunneling 을 통해 Overlay Netwokr를 지원하여 물리적인 네트워크를 넘어서 가상의 네트워크를 구축할 수 있다.

서로 다른 물리 서버의 VM들을 같은 L2 네트워크처럼 연결할 수 있어 클라우드 환경에서 유용하다.

 

3. OpenFlow 기반 SDN 컨트롤 가능

SDN 컨트롤러(ONOS, OpenDaylight, Ryu 등)를 통해 중앙에서 제어할 수 있다.

반면 Linux Bridge 는 OverFlow 를 지원하지 않아서 SDN 환경에서 활용되기 어렵다.

 

4. 성능 및 확장성

OVS는 DPDK(Data Plane Development Kit) 같은 기술을 지원하여 성능을 크게 향상시킬 수 있다.

클라우드 환경(예: OpenStack, Kubernetes)에서는 수천 개의 VM과 컨테이너가 빠르게 생성/삭제되는데, OVS는 이와 같은 환경에서도 높은 확장성을 제공한다.

 

5. 트래픽 모니터링 및 정책 제어

OVS는 sFlow, NetFlow  등을 지원하여 네트워크 트래픽을 상세히 분석할 수 있다.

ACL 및 QOS ( Traffic Shaping) 설정도 가능하여 보다 정밀한 네트워크 제어가 가능하다.

 

OVS는 단순한 스위칭이 아니라 SDN, Overlay Network, 트래픽 제어 등을 위해 설계된 고급 가상 스위치이기 때문에 클라우드, 데이터센터, 컨테이너 환경에서 강력한 장점을 가진다.

단순한 VM 간 네트워크라면 Linux Bridge도 가능하지만, 고급 네트워크 기능이나 Overlay Network, SDN을 활용하려면 OVS가 필수적이라는 점이다.

 

VM 연결 간에 Tunneling 이랑 OverlayNetwork 를 구현하는 이유??

1. 서로 다른 VM HOST (물리 서버) 간 네트워크 연결이 가능하게 하기 위해서

기본적으로 Linux Bridge만 사용하면 같은 물리 서버 내 VM만 연결이 가능하다. 하지만 데이터센터 클라우 환경에서는 다른 물리 서버에 있는 VM 끼리도 같은 네투워크 (L2)에서 통신할 수 있어야한다.

물론 기존 네트워크 방식과 Linux Bridge도 물리적인 스위치 및 VLAN 설정을 통해 서로 다른 VM HOST 간의 네트워크 연결이 가능하다. 하지만 클라우드 환경 같이 수많은 VM을 서로 다른 물리적 서버에서 다발적으로 연결해서 사용하기에는 부적합하다..

OVerlay Network 는

물리 서버 간의 가상의 L2 네트워크를 새엇ㅇ하게 된다. 이는 기존 물리 네트워크와 독립적으로 동작하기 때문에 기존 네트워크 설정을 변경할 필요가 없다.

같은 서브넷처럼 보이지만 실제로는 Tunneling을 통해 패킷을 전달한다

-> 이 말이 무엇일까?

Overlay Netowkr에서는 VM들이 같은 서브넷에 있는 것처럼 보이지만 실제로는 물리 네트워크 위에서 터널링을 통해 패킷이 전달된다. (가상으로 같은 네트워크를 만드는 것)

 

ex) Overlay Network로 서로 다른 서버의 VM 연결

VM1 -> VM2 로 패킷을 보내는 과정  (VXLAN/GRE Tunneling)

VM1(192.168.1.10)에서 VM2(192.168.1.20)로 패킷을 보냄
→ VM1은 같은 서브넷(192.168.1.0/24)이라고 생각하고 그냥 패킷을 전송.

Host1의 OVS (Open vSwitch)에서 VXLAN/GRE 터널링 적용
→ Host1은 패킷을 보고, "VM2는 다른 물리 서버에 있네?" 라고 판단.
→ 그래서 이 패킷을 VXLAN/GRE로 캡슐화하여 Host2로 전송.

물리 네트워크(Host1 ↔ Host2)에서는 캡슐화된 패킷이 전달됨
→ Host1의 물리 IP(192.168.100.1) → Host2의 물리 IP(192.168.100.2)로 전달됨.
→ 즉, 기존 네트워크에서 보면 단순한 UDP/TCP 트래픽처럼 보임!

Host2에서 VXLAN/GRE 캡슐화를 해제하여 VM2로 전달
→ Host2가 캡슐화를 해제하고, 원래 패킷을 VM2(192.168.1.20)에게 전달.

 

같은 서브넷처럼 보이는 이유

1) VM들은 같은 서브넷(예: 192.168.1.0/24)에 있는 것처럼 동작

ARP 요청을 보낼 때도 기존 L2 네트워크처럼 보인다.

일반적인 L2 스위치처럼 MAC 주소를 학습하고 패킷을 전달한다.

2) 실제로는 물리 네트워크에서 터널링을 사용하여 패킷을 전달

기존 네트워크를 변경하지 않고, 물리적으로 떨어진 VM들끼리 가상의 네트워크를 형성.
캡슐화를 통해 패킷을 목적지까지 전송하고, 도착하면 캡슐화를 해제.

 

2. 네트워크를 분리하여 Isolation (격리) 및 보안 강화

클라우드 환경에서는 다수의 사용자가 같은 물리 서버를 공유하는 경우가 많다. 만약 이 때 모든 VM이 같은 네트워크 안에 존재한다면 보안 문제가 발생하고 트래픽이 혼잡해질 수 잇다.

문제점:
같은 네트워크에서 모든 VM이 브로드캐스트 패킷을 받음 → 성능 저하.
네트워크가 분리되지 않으면, 보안적으로 취약.
여러 고객(테넌트)이 같은 네트워크를 사용하면 IP 충돌 발생 가능.

 

Overlay Network (VXLAN, GRE)로 해결이 가능하다.
각 테넌트(사용자)마다 독립적인 가상 네트워크(VXLAN ID) 제공하여 서로 다른 네트워크로 구분한다. 그래서  IP 대역이 중복되어도 서로 다른 네트워크로 구분되어있기 때문에 충돌이 발생하지 않는다. 
이로 인해 보안 격리 가능하며,  A 테넌트와 B 테넌트의 VM이 서로 접근 불가능하다. 기존 물리 네트워크 변경 없이 여러 개의 네트워크를 논리적으로 구성 가능하다.

 

다른 물리 서버에 있는 VM끼리도 같은 네트워크처럼 연결하기 위해

네트워크를 논리적으로 분리해서 보안과 확장성을 확보하기 위해

그래서 결론적으로 클라우드, 데이터센터, 컨테이너 환경에서 필수적인 네트워크 기술이 된 것이다.