OVS Phần 4: Cài Đặt và Lab OVS Đầu Tiên

Phần 4/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 1 (tổng quan), Phần 2 (so sánh Linux bridge) và Phần 3 (kiến trúc bên trong). Ba bài trước toàn nói bằng lời và output minh họa. Bài này khác hẳn: từ đây bạn tự tay gõ lệnh, tự tay xác nhận. Đọc xong, Bài 5 sẽ đào sâu ovs-vsctl — tạo port, gán VLAN, quản lý OVSDB.

Mục tiêu bài học: sau bài này bạn sẽ có OVS chạy thật trên máy mình — không chỉ đọc lý thuyết — biết chọn đúng đường cài đặt cho từng mục đích (cài package thật để dùng lâu dài, hay ovs-sandbox để thử nhanh không cần quyền root), và tự tay dựng được một lab tối thiểu: hai network namespace nói chuyện qua một OVS bridge, đủ để tận mắt thấy những gì Bài 1-3 mới chỉ mô tả bằng lời.

Ba câu hỏi mà bài này trả lời:

Có mấy cách để "có OVS chạy" trên máy, và khi nào nên chọn cách nào?
Cài đặt xong, làm sao biết OVS đã thật sự chạy đúng — service, kernel module?
Dựng một lab tối thiểu theo đúng các bước nào để tự tay thấy packet đi qua switch?

Mục lục

1. Nhắc lại nhanh: Bài 1-3 đã nói gì?
2. Hai đường để có OVS chạy: cài thật hay dùng sandbox?
3. Cài đặt OVS thật trên Ubuntu/Debian
4. Dựng lab đầu tiên: hai namespace nói chuyện qua một OVS bridge
Bài tập cuối bài

1. Nhắc lại nhanh: Bài 1-3 đã nói gì?

Bài 1 vẽ sơ đồ tổng, Bài 2 chứng minh OVS và Linux bridge là hai kernel module tách biệt, Bài 3 mổ xẻ chính xác ba mảnh ghép (ovsdb-server, ovs-vswitchd, datapath) và đường đi của một packet — miss/upcall lần đầu, hit/cache những lần sau. Tất cả những điều đó, tính đến giờ, bạn mới biết qua chữ và qua output minh họa đánh dấu rõ "chỉ mang tính ví dụ".

Bài này đổi vai: bạn không đọc về OVS nữa, bạn chạy OVS. Mọi con số, mọi tên field xuất hiện trong output từ đây trở đi là output thật, không còn ghi chú "minh họa" nào cả.

2. Hai đường để có OVS chạy: cài thật hay dùng sandbox?

Trước khi gõ lệnh đầu tiên, có một quyết định cần đưa ra: bạn muốn OVS tồn tại lâu dài trên máy (để dùng cho các bài lab tiếp theo trong loạt bài này), hay chỉ cần một môi trường thử nhanh, không muốn động vào hệ thống thật?

Đường 1 — cài package thật: dùng apt cài openvswitch-switch/openvswitch-common lên chính hệ điều hành, nạp kernel module, chạy service nền qua systemd. Đây là cách bạn sẽ dùng cho toàn bộ các bài lab còn lại của loạt bài này, vì nó tạo ra bridge/port thật, gắn được vào interface thật, ping được thật.

Đường 2 — ovs-sandbox: một script đi kèm trong chính mã nguồn OVS, dựng một môi trường OVS mô phỏng hoàn toàn bằng phần mềm — tài liệu chính thức của dự án nói thẳng: "Bạn không cần bất kỳ phần cứng mạng vật lý nào, thậm chí không cần quyền superuser trên hệ thống." Chạy xong, nó mở một shell lồng bên trong, đã có sẵn ovsdb-server và ovs-vswitchd chạy ở chế độ "dummy". Tài liệu chính thức nói rõ giới hạn của chế độ này: "bridge không thấy được với network stack của hệ điều hành, nên ip không thấy hay tác động được, và các công cụ như ping, tcpdump cũng sẽ không hoạt động." Đủ để bạn tập gõ ovs-vsctl/ovs-ofctl mà không sợ phá gì trên máy — nhưng không thay thế được việc thấy packet đi thật, đó là lý do Mục 4 vẫn cần Đường 1.

git clone https://github.com/openvswitch/ovs.git
cd ovs/tutorial
./ovs-sandbox

💡 Hình dung như thế này: ovs-sandbox giống bãi tập lái xe trong sân trường — an toàn tuyệt đối, không cần bằng lái (root), sai đâu sửa đó không ảnh hưởng ai, nhưng xe ở đó không thật sự chở bạn đi đâu cả. Cài package thật giống lái ra đường thật — cần đăng ký (root, systemd), có rủi ro nếu thao tác sai, nhưng đó là nơi bạn thật sự đến được đích.

Vì mục tiêu của loạt bài là dựng lab thật, xuyên suốt các bài sau, Mục 3-4 dưới đây đi theo Đường 1.

3. Cài đặt OVS thật trên Ubuntu/Debian

Trên Ubuntu (bài này dùng bản LTS hiện tại — 26.04 "Resolute Raccoon", nhưng lệnh dưới đây không đổi qua nhiều bản Ubuntu gần đây) và Debian, tài liệu chính thức của dự án nói rõ: "Debian và Ubuntu có gói openvswitch-switch và openvswitch-common, bao gồm các thành phần userspace cốt lõi của switch."

sudo apt update
sudo apt install openvswitch-switch openvswitch-common

Cài xong, openvswitch-switch.service — một service dạng "umbrella", quản lý chung cả hai daemon ovs-vswitchd và ovsdb-server (đúng hai trong ba mảnh ghép Bài 3 đã nói) — sẽ tự khởi động. Kiểm tra:

sudo systemctl status openvswitch-switch.service

# Output minh họa
● openvswitch-switch.service - Open vSwitch
     Loaded: loaded (/usr/lib/systemd/system/openvswitch-switch.service; enabled)
     Active: active (exited) since ...

(Output minh họa — cấu trúc đúng theo lệnh thật, số liệu cụ thể tùy máy.) Dòng active (exited) không phải dấu hiệu lỗi, dù chữ "exited" nghe như service vừa chết. openvswitch-switch.service được khai kiểu Type=oneshot với RemainAfterExit=yes — nó chỉ chạy đúng một lần để khởi động ovsdb-server và ovs-vswitchd (hai tiến trình nền riêng, không phải con của chính unit này), rồi tự thoát và được systemd coi là "vẫn active" vì RemainAfterExit=yes. Thấy "exited" ở đây là bình thường; muốn biết hai daemon thật có đang chạy không, phải kiểm tra bằng lsmod/ovs-vsctl show như dưới đây, không phải nhìn dòng Active này.

Kernel module openvswitch.ko (mảnh ghép thứ ba — datapath, Bài 3 Mục 2) thường tự nạp theo package, nhưng đáng kiểm tra lại bằng đúng lệnh bạn đã học ở Bài 3:

lsmod | grep openvswitch

Nếu dòng này trống, nạp tay bằng sudo modprobe openvswitch rồi chạy lại lsmod để xác nhận — module xuất hiện thì mới có datapath để dùng.

Cuối cùng, xác nhận cả ba mảnh ghép đã sẵn sàng bằng đúng lệnh Bài 1 Mục 4 từng chạy — lúc đó chỉ là version check, giờ là xác nhận thật:

ovs-vsctl --version
sudo ovs-vsctl show

ovs-vsctl show vẫn trả về rỗng — đúng như Bài 1 đã giải thích, vì chưa có bridge nào được tạo. Mục 4 sẽ thay đổi điều đó.

4. Dựng lab đầu tiên: hai namespace nói chuyện qua một OVS bridge

Mục tiêu của lab này rất khiêm tốn, cố tình khiêm tốn: dựng đúng một bridge, gắn hai "máy" giả lập vào hai đầu, cho chúng ping nhau qua switch — không OpenFlow tùy biến, không VLAN, không tunnel. Những thứ đó là chủ đề của Bài 5 trở đi. Ở đây chỉ cần thấy OVS switch được, đúng nghĩa đen.

"Hai máy" ở đây là hai network namespace (ns1, ns2) — một cơ chế của kernel Linux cho phép mô phỏng nhiều "máy" độc lập về mặt network trên cùng một kernel, mỗi namespace có bảng định tuyến, interface, ARP table riêng, y hệt hai máy vật lý tách biệt dù đang chạy chung một OS. Nếu quy đổi sang thế giới vật lý bạn đã quen: đây tương đương việc cắm hai laptop test vào hai access port trên một switch thật — chỉ khác là ở đây không cần phần cứng, không cần dây cáp, cả "hai máy" lẫn "switch" đều chỉ là phần mềm trên cùng một kernel. Nối chúng vào bridge bằng veth pair — man page chính thức của kernel mô tả đúng cơ chế: "packet truyền trên một đầu được nhận ngay lập tức ở đầu kia... có thể hình dung như một sợi dây patch cable ảo". Đó chính xác là việc bạn sắp làm: "kéo dây" giữa hai không gian network khác nhau (ở đây là giữa một namespace và namespace gốc, nơi OVS bridge đang sống).

# Tạo 2 network namespace
sudo ip netns add ns1
sudo ip netns add ns2

# Tạo bridge
sudo ovs-vsctl add-br br0

# Veth pair cho ns1: veth0 sẽ nằm trong ns1, veth0-ovs ở lại namespace gốc để gắn vào bridge
sudo ip link add veth0 type veth peer name veth0-ovs
sudo ip link set veth0 netns ns1
sudo ovs-vsctl add-port br0 veth0-ovs
sudo ip link set veth0-ovs up

# Veth pair cho ns2, làm y hệt
sudo ip link add veth1 type veth peer name veth1-ovs
sudo ip link set veth1 netns ns2
sudo ovs-vsctl add-port br0 veth1-ovs
sudo ip link set veth1-ovs up

# Gán IP + bật interface bên trong từng namespace
sudo ip netns exec ns1 ip addr add 10.0.0.1/24 dev veth0
sudo ip netns exec ns1 ip link set veth0 up
sudo ip netns exec ns1 ip link set lo up

sudo ip netns exec ns2 ip addr add 10.0.0.2/24 dev veth1
sudo ip netns exec ns2 ip link set veth1 up
sudo ip netns exec ns2 ip link set lo up

# Ping từ ns1 sang ns2 — packet phải đi qua đúng br0
sudo ip netns exec ns1 ping -c 3 10.0.0.2

# Output minh họa
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.041 ms

(Output minh họa — cấu trúc đúng theo lệnh thật, số liệu cụ thể tùy máy.) time cực nhỏ (dưới 1ms) không phải trùng hợp — cả hai namespace vẫn nằm trên cùng một kernel, packet không hề ra khỏi máy vật lý, chỉ đi qua đúng software switch mà bạn vừa dựng.

Đây chính xác là lúc bạn có thể quay lại hoàn thành bài tập cuối Bài 3: ngay sau lệnh ping ở trên, chạy sudo ovs-appctl dpctl/dump-flows — sẽ thấy đúng một datapath flow ICMP vừa được cài, y như Bài 3 Mục 3 đã mô tả bằng output minh họa. Giờ nó không còn là minh họa nữa.

Xác nhận lại toàn cảnh bằng ovs-vsctl show — lần này không còn rỗng:

sudo ovs-vsctl show

# Output minh họa
c1e4a2f0-....
    Bridge br0
        Port veth1-ovs
            Interface veth1-ovs
        Port veth0-ovs
            Interface veth0-ovs
        Port br0
            Interface br0
                type: internal
    ovs_version: "3.7.1"

(Output minh họa — cấu trúc đúng theo lệnh thật, số liệu cụ thể tùy máy.) Chú ý dòng Port br0 / type: internal xuất hiện dù bạn chưa từng tạo nó tay — tài liệu chính thức xác nhận: bản thân bridge luôn tự có kèm một internal port cùng tên, dùng được để gán IP thẳng lên br0 nếu muốn quản lý bridge như một interface bình thường của host.

Nếu bạn chỉ nhớ được một điều sau bài này, hãy nhớ: từ giờ trở đi, mọi khái niệm Bài 1-3 nói bằng lời đều có thể tự tay gõ lệnh kiểm chứng trên chính máy bạn — không cần tin lời tài liệu nữa.

Bài tập cuối bài

Dựng lại đúng lab ở Mục 4, nhưng với ba namespace (ns1, ns2, ns3) thay vì hai, cả ba cùng gắn vào br0. Ping lần lượt giữa từng cặp — xác nhận cả ba vẫn "nhìn thấy" nhau dù bạn chưa cấu hình bất kỳ OpenFlow rule nào ngoài hành vi mặc định. Đây chính là hành vi học-MAC cơ bản Bài 1 đã nói OVS vẫn giữ nguyên từ một switch layer 2 bình thường.
Chạy sudo ovs-appctl dpctl/dump-flows ngay sau bài tập 1, rồi chờ qua mốc 10 giây không ping gì thêm, chạy lại — xác nhận đúng hành vi max-idle Bài 3 đã nêu bằng số liệu thật của chính bạn, không phải output minh họa nữa.

Nguồn tham khảo

Debian/Ubuntu có gói openvswitch-switch và openvswitch-common, gồm các thành phần userspace cốt lõi của switch — Installing Open vSwitch on Debian, docs.openvswitch.org.
Gói openvswitch-switch trên Ubuntu 26.04 LTS "Resolute Raccoon" ở bản 3.7.1-2 — Launchpad: openvswitch-switch trong Resolute.
openvswitch-switch.service là service quản lý chung ovs-vswitchd và ovsdb-server — Ubuntu bug #1585201, launchpad.net.
ovs-sandbox không cần phần cứng mạng vật lý hay quyền superuser, chạy ovsdb-server/ovs-vswitchd ở chế độ "dummy" bên trong một shell lồng — Open vSwitch Advanced Features, docs.openvswitch.org, mã nguồn script tại tutorial/ovs-sandbox, github.com/openvswitch/ovs.
Bridge OVS luôn tự có kèm một internal port cùng tên, có thể gán IP thẳng lên để dùng như interface quản lý — Common Configuration Issues FAQ, docs.openvswitch.org.
ip netns (tạo/quản lý network namespace) và ip link ... type veth (tạo veth pair) là lệnh chuẩn của iproute2, không riêng của OVS — ip-netns(8), man7.org, ip-link(8), man7.org.
veth: "packet truyền trên một đầu được nhận ngay lập tức ở đầu kia", ví như "một sợi dây patch cable ảo" — veth(4), man7.org.
Kernel module openvswitch thường tự nạp cùng package, nếu thiếu thì nạp tay bằng modprobe openvswitch — xác nhận qua thảo luận cộng đồng chính thức của dự án, ovs-discuss mailing list, mail.openvswitch.org.

Tiếp theo: Module 1, Bài 5 — ovs-vsctl: tạo port, gán VLAN, quản lý cấu hình qua OVSDB.

Mục lục​

1. Nhắc lại nhanh: Bài 1-3 đã nói gì?​

2. Hai đường để có OVS chạy: cài thật hay dùng sandbox?​

3. Cài đặt OVS thật trên Ubuntu/Debian​

4. Dựng lab đầu tiên: hai namespace nói chuyện qua một OVS bridge​

Bài tập cuối bài​

Nguồn tham khảo​