sejong.jeonjo@gmail.com

작성일: 2023년 9월 15일

South Carolina 대학의 'Open Virtual Switch Lab Series' 문서를 바탕으로 내가 실습한 내용을 이곳에 정리함.
( Network namespace 개념부터 차곡차곡 쌓아 올리면서 Open vSwitch Use Case를 설명하기 때문에 공부하는 사람에게 많은 도움이 된다 )

참고 문서:
    [ 링크 클릭 ]  OVS 실습 문서 (Open Virtual Switch Lab Series, 2021년 09월 30일)
    [ 링크 클릭 ]  OVS 개념 및 구성 소개 [ Link ]

아래 그림을 기반으로 Open vSwitch와 Namespace를 구성하여 테스트한다.

위 그림에 묘사된 것과 같이 Network를 구성하기 위해 아래 명령을 작성했다. (따라해보면 위 그림과 똑같은 Network 만들어진다)

## root namespace에 존재하는 모든 network interface를 조회
$ ip link

## 네임스페이스 my-ns-a, my-ns-b 를 생성
$ ip netns add my-ns-a
$ ip netns add my-ns-b

## Linux kernel에 존재하는 모든 namespace 조회
$ ip netns
my-ns-b
my-ns-a

## 'my-ns-a' 네임스페이스에 존재하는 network interface 조회
$ ip netns exec my-ns-a ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

## 가상 스위치 'sw1'를 생성
$ ovs-vsctl add-br sw1

## root namespace에 존재하는 network interface를 조회
$ ip link
... 중간 생략 ...
47: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 86:3d:02:69:23:4f brd ff:ff:ff:ff:ff:ff
48: sw1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:68:07:5d:c0:40 brd ff:ff:ff:ff:ff:ff

## Open vSwitch에 namespace를 연결하기
##  1) veth peer 생성하기
$ ip link add my-ns-a-eth0 type veth peer name sw1-eth1

$ ip link add my-ns-b-eth0 type veth peer name sw1-eth2

$ ip link
... 중간 생략 ...
47: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 86:3d:02:69:23:4f brd ff:ff:ff:ff:ff:ff
48: sw1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:68:07:5d:c0:40 brd ff:ff:ff:ff:ff:ff
51: sw1-eth1@my-ns-a-eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether be:01:52:6f:4b:58 brd ff:ff:ff:ff:ff:ff
52: my-ns-a-eth0@sw1-eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:24:a4:bf:78:f3 brd ff:ff:ff:ff:ff:ff
53: sw1-eth2@my-ns-b-eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 46:d4:ad:57:18:20 brd ff:ff:ff:ff:ff:ff
54: my-ns-b-eth0@sw1-eth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:78:4d:57:db:37 brd ff:ff:ff:ff:ff:ff

##  2) veth peer를 각각의 namepace에 연결하기 (Attaching to namespaces)
$ ip link set my-ns-a-eth0 netns my-ns-a

$ ip link set my-ns-b-eth0 netns my-ns-b

$ ip netns exec my-ns-a ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
52: my-ns-a-eth0@if51: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 96:24:a4:bf:78:f3 brd ff:ff:ff:ff:ff:ff link-netnsid 0

$ ip netns exec my-ns-b ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
54: my-ns-b-eth0@if53: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 2a:78:4d:57:db:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0


##  3) 가상 스위치 sw1에 veth peer를 연결하기 (Attaching veth peer to switch sw1) 
$ ovs-vsctl add-port sw1 sw1-eth1

$ ovs-vsctl show
...
    Bridge sw1
        Port sw1
            Interface sw1
                type: internal
        Port sw1-eth1
            Interface sw1-eth1
...

$ ovs-vsctl add-port sw1 sw1-eth2

$ ovs-vsctl show
...
    Bridge sw1
        Port sw1
            Interface sw1
                type: internal
        Port sw1-eth2
            Interface sw1-eth2
        Port sw1-eth1
            Interface sw1-eth1
...


## 가상 스위치의 network port를 activate 하기. (Turning up the network port)
$ ip link set sw1-eth1 up

$ ip link set sw1-eth2 up

$ ip link 
...
51: sw1-eth1@if52: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master ovs-system state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether be:01:52:6f:4b:58 brd ff:ff:ff:ff:ff:ff link-netns my-ns-a
53: sw1-eth2@if54: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master ovs-system state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 46:d4:ad:57:18:20 brd ff:ff:ff:ff:ff:ff link-netns my-ns-b
...

## 각각의 namespace에 IP address를 할당하기
$ ip netns exec my-ns-a ip link set dev my-ns-a-eth0 up

$ ip netns exec my-ns-b ip link set dev my-ns-b-eth0 up

$ ip netns exec my-ns-a ip address add 192.168.1.10/24 dev my-ns-a-eth0

$ ip netns exec my-ns-b ip address add 192.168.1.20/24 dev my-ns-b-eth0

## 설정 정보 확인하기
$ ip netns exec my-ns-a ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
52: my-ns-a-eth0@if51: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:24:a4:bf:78:f3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.10/24 scope global my-ns-a-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::9424:a4ff:febf:78f3/64 scope link
       valid_lft forever preferred_lft forever

$ ip netns exec my-ns-b ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
54: my-ns-b-eth0@if53: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2a:78:4d:57:db:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.20/24 scope global my-ns-b-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2878:4dff:fe57:db37/64 scope link
       valid_lft forever preferred_lft forever

## namespace 'my-ns-a'의 routing table 확인하기
$ ip netns exec my-ns-a ip route
192.168.1.0/24 dev my-ns-a-eth0 proto kernel scope link src 192.168.1.10

## namespace 'my-ns-b'의 routing table 확인하기
$ ip netns exec my-ns-b ip route
192.168.1.0/24 dev my-ns-b-eth0 proto kernel scope link src 192.168.1.20

## namespace 'my-ns-a'에서 bash shell 시작하기
$ ip netns exec my-ns-a bash

$ ifconfig
my-ns-a-eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.10  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::9424:a4ff:febf:78f3  prefixlen 64  scopeid 0x20<link>
        ether 96:24:a4:bf:78:f3  txqueuelen 1000  (Ethernet)
        RX packets 86  bytes 21517 (21.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13  bytes 1006 (1.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ ping 192.168.1.20 -c 2
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=0.088 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.079 ms

--- 192.168.1.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.079/0.083/0.088/0.004 ms

$ traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 64 hops max
  1   192.168.1.20  0.452ms  0.003ms  0.002ms

OVS로 VLAN network를 구성하고 테스트해볼까 생각했는데, 이미 다른 분이 아주 상세하게 테스트한 내용을 잘 적어놓았네 ^^

https://m.blog.naver.com/love_tolty/222609033937

OCP Cluster를 구축한 직후에  ovs-vsctl 명령으로 Open vSwitch의 구성을 확인해봤다.

특징한 살펴보면, 

• br-int Bridge에 각 Kube Node로 가는 물리 Port(50.50.51.2x)는 geneve 터널링 방식을 사용.
  (아래 ovs-vsctl 명령 결과에서 geneve로 검색하면 됨)

[root@worker1 ~]# ovs-vsctl show
9cad81c8-d7be-4b18-90e8-03aadd86a8cb
    Bridge br-ex
        Port enp131s0f0
            Interface enp131s0f0
                type: system
        Port patch-br-ex_worker1.twcm.cloud-to-br-int
            Interface patch-br-ex_worker1.twcm.cloud-to-br-int
                type: patch
                options: {peer=patch-br-int-to-br-ex_worker1.twcm.cloud}
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        fail_mode: secure
        datapath_type: system
        Port ovn-5e8778-0
            Interface ovn-5e8778-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.22"}
        Port "83cf7b04f35b763"
            Interface "83cf7b04f35b763"
        Port br-int
            Interface br-int
                type: internal
        Port d10af31c1d33dac
            Interface d10af31c1d33dac
        Port "460c3ee2f55e7c9"
            Interface "460c3ee2f55e7c9"
        Port ovn-f95ec3-0
            Interface ovn-f95ec3-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.21"}
        Port patch-br-int-to-br-ex_worker1.twcm.cloud
            Interface patch-br-int-to-br-ex_worker1.twcm.cloud
                type: patch
                options: {peer=patch-br-ex_worker1.twcm.cloud-to-br-int}
        Port ovn-84a2f7-0
            Interface ovn-84a2f7-0
                type: geneve
                options: {csum="true", key=flow, remote_ip="50.50.51.23"}
        Port "5fe45b331cff8df"
            Interface "5fe45b331cff8df"
        Port ovn-k8s-mp0
            Interface ovn-k8s-mp0
                type: internal
        Port "59a37a9be52afdb"
            Interface "59a37a9be52afdb"
    ovs_version: "2.15.4"

실제 Pod가 사용하는 Overlay Network Port인 ovn-k8s-mp0는 아래 보이는 것처럼 MTU가 1400 bytes이다.

geneve 터널링을 위해 100 byte를 사용해야 하므로, MTU가 1400 bytes가 된 것이다.

[root@worker1 ~]# ifconfig ovn-k8s-mp0
ovn-k8s-mp0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
        inet 10.131.0.2  netmask 255.255.254.0  broadcast 10.131.1.255
        inet6 fe80::ec45:a3ff:fe53:665  prefixlen 64  scopeid 0x20<link>
        ether ee:45:a3:53:06:65  txqueuelen 1000  (Ethernet)
        RX packets 248078  bytes 20827992 (19.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 264379  bytes 23121981 (22.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Pod가 IP Networking은 일반적인 L2 Switching 통해서 처리되므로, 아래 routing table을 참조하여 이웃하는 Worker, Master Node로 전달된다. 

10.128.0.0  10.131.0.0 network가 Pod가 사용하는 Network이다.

[root@worker1 ~]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         50.50.51.10     0.0.0.0         UG        0 0          0 br-ex
10.128.0.0      10.131.0.1      255.252.0.0     UG        0 0          0 ovn-k8s-mp0
10.131.0.0      0.0.0.0         255.255.254.0   U         0 0          0 ovn-k8s-mp0
50.50.51.0      0.0.0.0         255.255.255.0   U         0 0          0 br-ex
169.254.169.0   50.50.51.10     255.255.255.252 UG        0 0          0 br-ex
169.254.169.3   10.131.0.1      255.255.255.255 UGH       0 0          0 ovn-k8s-mp0
172.30.0.0      50.50.51.10     255.255.0.0     UG        0 0          0 br-ex

Netfilter를 살펴보면,

Pod와 Service 리소스를 생성하면서 Netfilter의 Chain Rule 변화 여부를 모니터링 해봤는데, 변화가 없다.

[root@worker1 ~]# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-ETP  all  --  anywhere             anywhere
OVN-KUBE-EXTERNALIP  all  --  anywhere             anywhere
OVN-KUBE-NODEPORT  all  --  anywhere             anywhere

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-SNAT-MGMTPORT  all  --  anywhere             anywhere
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
OVN-KUBE-EXTERNALIP  all  --  anywhere             anywhere
OVN-KUBE-NODEPORT  all  --  anywhere             anywhere

Chain KUBE-MARK-MASQ (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x4000

Chain KUBE-MARK-DROP (0 references)
target     prot opt source               destination
MARK       all  --  anywhere             anywhere             MARK or 0x8000

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             mark match ! 0x4000/0x4000
MARK       all  --  anywhere             anywhere             MARK xor 0x4000
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ random-fully

Chain KUBE-KUBELET-CANARY (0 references)
target     prot opt source               destination

Chain OVN-KUBE-SNAT-MGMTPORT (1 references)
target     prot opt source               destination
SNAT       all  --  anywhere             anywhere             /* OVN SNAT to Management Port */ to:10.131.0.2

Chain OVN-KUBE-NODEPORT (2 references)
target     prot opt source               destination

Chain OVN-KUBE-EXTERNALIP (2 references)
target     prot opt source               destination

Chain OVN-KUBE-ETP (1 references)
target     prot opt source               destination
[root@worker1 ~]#

그리고 위 상황에서 Service  리소스를 한개를 ClusterIP type에서 NodePort type으로 변경했더니,

아래와 같이 OVN-KUBE-NODEPORT에 Chain Rule 한개 추가되었다.

[root@worker1 ~]# iptables -L -t nat

... 중간 생략 ...

## 이 내용이 추가되었음.

Chain OVN-KUBE-NODEPORT (2 references)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL tcp dpt:31785 to:172.30.44.86:80

## 참고로 위 Chain Rule은 iptables 명령으로 추가한다면, 아래와 같이 실행하면 된다.
## (설명) destination port가 31785이면, 172.30.44.86:80 주소로 DNAT 처리하는 Rule을
##       OVN-KUBE-NODEPORT 체인에 추가하라는 명령.
# -A OVN-KUBE-NODEPORT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 31785 -j DNAT --to-destination 172.30.44.86:80

... 중간 생략 ...

이하, 작성 중...

Kuberentes를 사용하면서 이해하기 어려운 부분이 CNI(Cluter Network Interface)이다.

실제로 각 CNI 마다 동작하는 방식과 구현이 다른데 CNI라고 퉁쳐서 표현하다보니 Kubernetes를 사용하는 운영자 입장에서는 CNI가 어떻게 IP Traffic(트래픽)을 처리하는지 알기 어렵다.

여러 종류의 CNI 중에서 내가 사용하고 있는 특정 CNI에 대해서 깊이 있게 설명하는 자료도 별로 없으니 스터디하기가 더욱 어렵다.

나의 일터에서는 주로 Openshift SDN을 사용하기 때문에 오늘은 시간을 내서 Openshift SDN을 깊게 파헤쳐보려 한다.

우선 아래 그림에 있는 빨간색 숫자를 따라 가면서 보자.

이 빨간 색 숫자의 순서대로 요청 패킷이 처리된다.

그림에 순서에 맞게 설명을 적었기 때문에 전반적인 설명은 필요 없을 것 같다.

단, 복잡한 처리가 있는 부분을 좀더 살펴 본다면,

(2) Netfilter를 이용하여 DNAT, SNAT 처리

Kubernetes Pod 정보를 조회해보면 Cluster IP를 볼 수 있다. 바로 그 Pod의 Cluster IP로 DNAT 처리되는 것이다.

즉, 10.10.12.208:8080 목적지 주소를 보고, 이 주소 값과 Mapping되는 Kubernetes Pod IP를 찾고 Netfilter를 이용하여 DNAT 처리한다.

Worker 1 Node에서 iptables 명령을 이용하여 Netfilter의 Chain Rule을 조회하면 실제로 아래와 같이 정보를 볼 수 있다.

이 Chain Rule대로 관련 Packet 조건을 찾고, 그 조건에 맞는 Netfilter Chain을 따라가면서 DNAT처리하는 것이다.

$  iptables -t nat -L KUBE-SERVICES -nv | grep 10.10.12.208
 1760  106K KUBE-FW-BAR7JSQD2GL6A2KT  tcp  --  *      *       0.0.0.0/0            10.10.12.208         /* almighty/almighty5:web loadbalancer IP */ tcp dpt:8080

… 중간 생략 …

$ iptables -t nat -L KUBE-SEP-ZBWV76PMI2XAVMCD -nv
 1949  117K DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* almighty/almighty5:web */ tcp to:10.128.2.151:8080

—> kube-proxy가 실제 iptables 룰 생성시 사용한 명령은 아래와 같음.
KUBE-SEP-ZBWV76PMI2XAVMCD -p tcp -m comment --comment "almighty/almighty5:web" -m tcp -j DNAT --to-destination 10.128.2.151:8080

만약 Destination Pod가 다른 Worker Node에 있다면, 다른 Worker Node로 IP Packet을 보내기 위해 tun0 인터페이스를 이용하여야 한다. 이때 tun0의 IP Address로 SNAT 하도록 하는 Chain Rule 적용을 받는다.

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
OPENSHIFT-MASQUERADE  all  --  anywhere             anywhere             /* rules for masquerading OpenShift traffic */
KUBE-POSTROUTING  all  --  anywhere             anywhere             /* kubernetes postrouting rules */

Chain KUBE-POSTROUTING (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             mark match ! 0x1/0x1
MARK       all  --  anywhere             anywhere             MARK xor 0x1
MASQUERADE  all  --  anywhere             anywhere             /* kubernetes service traffic requiring SNAT */ random-fully

(3) DST IP로 갈 수 있는 Routing Table을 조회하여 tun0로 Packet을 보냄

아마 대부분 Kubernetes 사용자가 헷갈려하는 부분일 것이다.

만약 Destination Pod가 같은 Worker Node에 있다면, 단순히 Netfilter가 처리한 대로 Packet Forward만 하면 된다.

그런데, Destination Pod가 다른 Worker Node에 있다면 관련있는 물리 Network Port를 찾아서 보내야 한다.

위 그림에서 Worker 1과 Worker 2의 tun0 간에는 ARP Packet이 브로드캐스팅되므로, 이미 Worker 1에서는 Destination Pod IP에 해당하는 MAC Address를 알고 있다. 

(참고: arp 명령으로 Worker 1 노드의 ARP Table 조회 가능)

따라서 일반적인 L2 Forward 처리와 동일하게 처리된다.

(4) ~ (5) Encapsulate, Decapsulate

일반적인 VxLAN 터널링을 사용하여 Worker Node간에 Pod의 메시지를 전송해준다.

VxLAN 터널링 때문에 tun0의 MTU는 1450 byte가 된다. (왜냐하면, 터널링 헤더 메시지 때문에 50 Byte만큼 tun0 포트의 MTU가 작아지게 된다)

나머지 절차는 모두 L2 Switching이기 때문에 딱히 설명할 것이 없다.

응답 메시지는 따로 설명하지 않았다.

왜냐하면,

L2 Switching 구간은 단순히 Source Address와 Destination Address를 반대로 뒤집으면 되고,

Netfilter가 SNAT 처리한 부분의 Connection Track 정보를 찾아서 원래의 주소값으로 치환해주면 되기 때문이다.

블로그 작성자: sejong.jeonjo@gmail.com

테스트한 날짜: 2024년 3월 13일
테스트에 사용한 OS: Ubuntu 22.02
                        (Ubuntu 버전마다 설치할 pkg가 다르다. Ubuntu 20.04와 22.04만 이 블로그의 설명이 유효하다.)

Open vSwitch 설치

Open vSwitch를 설치한다.

$ sudo -s

$ apt update -y 

$ apt install -y openvswitch-common openvswitch-switch

$ apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager

libvirt-daemon과 virt-manager간 연동이 되려면, OS를 한번 Reboot 해줘야 한다.

Open vSwitch 설정

KVM Hypervisor의 VM이 사용할 Virtual Switch를 구축한다.

$ sudo -s

##
## br-ex 라는 이름의 Virtual Switch를 만든다.
##

$ ovs-vsctl add-br br-ex

$ ovs-vsctl show


##
## 인터넷과 연결된 Port를 eth0라고 가정한다.
## 이 eth0 port를 br-ex switch에 추가한다.
## [ 주의 ]
##   eth0 port를 bridge에 추가하는 순간, 기존에 eth0로 networking하던 것들이 모두 단절되니까
##   eth0 외에 eth1과 같이 여분의 network port를 추가로 만들어 놓는 것이 좋다.
##

$ ovs-vsctl add-port br-ex eth0

$ ovs-vsctl show


##
## netplan 설정 파일을 작성한다. (아래 예제를 참고)
##

$ cat /etc/netplan/00-installer-config.yaml

network:
  version: 2
  ethernets:
    eth0:                ## ovs bridge에 추가한 eth0 포트에는 IP 주소를 할당하지 않는다.
      dhcp4: false
    br-ex:               ## ovs bridge의 br-ex 포트에 eth0에 있는 주소를 설정한다.
      addresses:
      - 10.1.4.64/24
      gateway4: 10.1.4.1
      routes:
        - to: 10.1.4.0/24
          via: 10.1.4.1   
        - to: default
          via: 10.1.4.1
      nameservers:
        addresses:
        - 1.1.1.1
        - 8.8.8.8
    eth1:
      addresses:
      - 10.1.3.171/24
      routes:
        - to: 10.1.3.0/24
          via: 10.1.3.1      
      nameservers:
        addresses:
        - 1.1.1.1
        - 8.8.8.8
    eth2:
      dhcp4: false
    eth3:
      dhcp4: false
      
$ netplan apply

$ ifconfig br-ex

... 생략 ...

위와 같이 수행한 후, Ubuntu OS를 Reboot해서 Network Port eth0, br-ex가 정상적으로 구성되는지 확인한다.

(꼭, Reboot해야 하는 것은 아닌데 설정이 적용되는지 확인하는 차원에서 Reboot해보는 것을 권장한다)

KVM의 Network Profile 작성

KVM이 위에서 만든 br-ex virtual switch를 사용할 수 있도록 network profile을 작성한다.

$  cat > br-ex.xml <<-EOF

<network> 
 <name>br-ex</name>        # KVM이 User에게 출력해주는 이름 
 <forward mode='bridge'/> 
 <bridge name='br-ex'/>    # OVS가 가지고 있는 실제 bridge name 
 <virtualport type='openvswitch'/> 
</network> 
EOF

$

KVM에 Network Bridge 정보 등록

KVM 명령어인 virsh을 이용하여 br-ex switch 정보를 등록한다.

$ virsh  net-define  br-ex.xml
$ virsh  net-start  br-ex
$ virsh  net-autostart  br-ex
$ virsh  net-list​

위 설정 작성 후, Ubuntu Desktop 화면에서 'Virtual Manager' App을 실행하면 'br-ex' switch를 사용할 수 있다.

블로그 작성자: sejong.jeonjo@gmail.com