OVS Phần 2: OVS Là Gì — So Sánh Sâu Với Linux Bridge
Phần 2/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 1, nơi đã so sánh OVS với Linux bridge ở mức khái quát (Mục 2). Bài này đào sâu: Linux bridge thực sự làm được gì, giới hạn thật sự nằm ở đâu, và tiêu chí cụ thể nào giúp bạn quyết định dùng cái nào cho một tình huống thật. Đọc xong, Bài 3 sẽ mổ xẻ kiến trúc bên trong OVS (ovs-vswitchd, kernel datapath) — phần mà bài này chỉ chạm tới ở mức "chúng là hai thứ khác nhau".
Mục tiêu bài học: sau bài này bạn sẽ biết chính xác Linux bridge hỗ trợ và không hỗ trợ gì (VLAN, STP/RSTP, tooling), hiểu vì sao OVS không phải "Linux bridge cộng thêm tính năng" mà là một kernel module hoàn toàn tách biệt, và có một bộ tiêu chí cụ thể để tự quyết định dùng cái nào — thay vì chọn theo cảm tính hay theo bài viết đầu tiên tìm được trên mạng.
Ba câu hỏi mà bài này trả lời:
- Linux bridge thực sự làm được gì, và giới hạn ở đâu so với những gì Bài 1 đã nói khái quát?
- Tiêu chí cụ thể nào giúp bạn quyết định dùng Linux bridge hay OVS cho một tình huống thật?
- Vì sao ở quy mô lớn (OpenStack, multi-tenant), Linux bridge gần như luôn thua cuộc?
Mục lục
- 1. Nhắc lại nhanh: Bài 1 đã nói gì?
- 2. Linux bridge: kiến trúc và khả năng thật sự
- 3. OVS không phải "Linux bridge cộng thêm" — hai kernel module hoàn toàn tách biệt
- 4. Tiêu chí quyết định: khi nào Linux bridge đủ dùng, khi nào bắt buộc OVS
- 5. Case thực tế: vì sao OpenStack khai tử driver Linux bridge
- 6. CLI lab: dựng cả hai loại bridge cạnh nhau
- Bài tập cuối bài
1. Nhắc lại nhanh: Bài 1 đã nói gì?
Bài 1 đã nói: Linux bridge là một switch layer 2 học-MAC theo chuẩn 802.1D, chạy hoàn toàn trong kernel, phù hợp cho mạng đơn giản một host; OVS thêm ba thứ Linux bridge không có — OVSDB (data model có thể query/subscribe từ xa), OpenFlow (pipeline match/action lập trình được), và tunneling tích hợp sẵn (VXLAN/GRE/Geneve). Đó là bức tranh đúng, nhưng vẫn ở mức khái quát — đủ để bạn hiểu OVS "thêm gì", chưa đủ để bạn tự tin trả lời "vậy trường hợp cụ thể của tôi thì sao?". Bài này lấp đúng khoảng trống đó.
2. Linux bridge: kiến trúc và khả năng thật sự
Nhiều người hình dung Linux bridge như một khái niệm mơ hồ — "cái gì đó nối các interface lại với nhau". Thực chất nó là một kernel module cụ thể, tên bridge.ko, cài đặt đúng những gì tiêu đề Kconfig của nó ghi: "802.1d Ethernet Bridging". Nó học địa chỉ MAC trên từng port, forward theo bảng đã học, flood khi chưa biết đích, và — điểm hay bị bỏ sót — tự chạy Spanning Tree Protocol ngay trong kernel: mã nguồn STP (br_stp.c, br_stp_bpdu.c, br_stp_if.c, br_stp_timer.c) được biên dịch thẳng vào module bridge.ko, không phải một tính năng tùy chọn cần cài thêm.
💡 Hình dung như thế này: Linux bridge giống một switch unmanaged bạn mua ở cửa hàng điện tử — cắm dây vào là chạy, tự học MAC, tự chạy STP cơ bản để tránh loop nếu lỡ tạo mạch vòng. Nhưng bạn không SSH vào được, không có API cấu hình từ xa, không đổi được hành vi forward ngoài những gì nhà sản xuất đã cố định sẵn.
VLAN: một sự thật hay gây bất ngờ
Nếu bạn quen switch vật lý, sẽ mặc định VLAN trunking là tính năng "phải có" trên bất kỳ switch nào. Với Linux bridge, đây không phải sự thật hiển nhiên: khả năng VLAN-aware bridging (bridge tự lọc/gắn VLAN tag theo từng port, gần giống access/trunk port trên switch vật lý) chỉ được thêm vào kernel từ phiên bản 3.9 (phát hành 4/2013), qua patch "bridge: Add vlan filtering infrastructure" của Vlad Yasevich — và quan trọng hơn, tính năng này tắt theo mặc định ngay cả trên kernel hiện đại (CONFIG_BRIDGE_VLAN_FILTERING là tùy chọn, vlan_filtering mặc định = 0).
Trước 3.9, cách duy nhất để "trunk" nhiều VLAN qua Linux bridge là tạo riêng từng sub-interface 802.1q (ví dụ eth0.10, eth0.20) rồi gắn mỗi cái vào một bridge riêng — nghĩa là một bridge cho một VLAN, không có khái niệm "một bridge, nhiều VLAN, lọc theo port" như switch vật lý vẫn làm. Từ 3.9 trở đi, bạn bật vlan_filtering trên một bridge duy nhất rồi gán VLAN theo từng port bằng lệnh bridge vlan add — gần với mô hình access/trunk quen thuộc hơn, nhưng vẫn là tính năng phải bật tay, không phải mặc định.
STP có, nhưng chỉ là bản cũ
Kernel bridge chạy STP (802.1D) gốc — hội tụ chậm (30-50 giây khi topology đổi), đúng như chuẩn STP nguyên bản từ thập niên 1990. RSTP (802.1w, hội tụ dưới giây) không nằm trong kernel — muốn dùng phải cài thêm daemon userspace riêng tên mstpd (cũng xử lý luôn MSTP/PVST+). Mô tả chính thức của gói mstpd trên Debian nói thẳng: nó "mang lại tốc độ hội tụ nhanh hơn của RSTP mà bản cài sẵn trong kernel không cung cấp".
Tooling: brctl đã bị chính nhà phát triển gọi là lỗi thời
Công cụ cũ brctl (gói bridge-utils) — thứ nhiều tài liệu cũ vẫn dùng làm ví dụ — bị chính manpage Debian ghi rõ: "brctl(8) is obsolete", khuyến nghị dùng lệnh bridge từ gói iproute2 thay thế vì có bộ tính năng đầy đủ hơn (STP guard, hairpin mode, fast leave, root block — những thứ brctl không hề cài đặt). Công cụ hiện đại là tổ hợp ip link (tạo/xóa bridge, gán port) và bridge (cấu hình VLAN, FDB, STP) — đây cũng là bộ lệnh sẽ dùng trong lab ở Mục 6.
3. OVS không phải "Linux bridge cộng thêm" — hai kernel module hoàn toàn tách biệt
Đây là chỗ rất nhiều người hiểu sai, kể cả người đã dùng OVS một thời gian: nghĩ rằng OVS được xây "trên nền" Linux bridge, chỉ là thêm vài tính năng. Không đúng. Nhìn thẳng vào cây mã nguồn kernel Linux: net/bridge/ (module bridge) và net/openvswitch/ (module openvswitch) là hai thư mục ngang hàng, hai mục Kconfig độc lập (Kconfig là hệ thống khai báo tùy chọn build của kernel — quyết định module nào được biên dịch, module nào không), biên dịch ra hai kernel module hoàn toàn riêng biệt — bridge.ko và openvswitch.ko. Không có dòng code nào dùng chung.
💡 Hình dung như thế này: đừng nghĩ OVS là chiếc xe đạp thường (Linux bridge) được lắp thêm động cơ. Nó là một chiếc xe máy được thiết kế lại từ đầu — nhìn ngoài cũng có hai bánh, cũng chở người, nhưng động cơ, khung sườn, cách vận hành bên trong hoàn toàn khác, không phải "xe đạp độ thêm".
Hệ quả thực tế: khi bạn chạy ovs-vsctl add-br br0, kernel nạp openvswitch.ko — không đụng gì tới bridge.ko cả, dù từ góc nhìn người dùng cả hai đều "trông giống" một bridge có thể gắn port vào. Kiến trúc bên trong openvswitch.ko xử lý packet theo mô hình flow table + datapath (match/action, cache theo flow) — khác hẳn mô hình FDB (forwarding database) + STP của bridge cổ điển. Bài 3 sẽ mổ xẻ chính xác mô hình flow table đó hoạt động ra sao.
Muốn tự tay xác nhận điều này thay vì chỉ tin lời giải thích, kiểm tra module nào đang thực sự nạp trong kernel:
# Sau khi đã dựng cả br-linux (Mục 6) và br-ovs, kiểm tra module kernel đang chạy
lsmod | grep -E 'bridge|openvswitch'
# Output minh họa
openvswitch 200704 0
nf_conntrack 172032 1 openvswitch
bridge 311296 0
stp 16384 1 bridge
llc 16384 2 bridge,stp
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Hai dòng openvswitch và bridge xuất hiện độc lập nhau, không dòng nào liệt kê dòng kia trong cột "Used by" — đúng bằng chứng thực nghiệm cho việc chúng là hai module tách biệt. Chú ý bridge còn kéo theo stp như một dependency riêng (đúng như Mục 2 đã nói: mã STP nằm ngay trong bridge.ko), trong khi openvswitch kéo theo nf_conntrack — framework connection-tracking của Netfilter, thứ Linux bridge cổ điển không cần tới.
Muốn biết thêm chi tiết về module openvswitch (version, tham số, dependency đầy đủ):
modinfo openvswitch
# Output minh họa (rút gọn)
filename: /lib/modules/6.8.0-.../kernel/net/openvswitch/openvswitch.ko
description: Open vSwitch switching datapath
depends: nf_conntrack,libcrc32c,nsh
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Trường filename cho thấy chính xác đường dẫn net/openvswitch/openvswitch.ko đã nói ở trên — không có gì mơ hồ về việc đây có phải "Linux bridge cộng thêm" hay không.
Có một chi tiết lịch sử càng làm rõ ranh giới này. Những bản OVS rất sớm (trước 1.10, khoảng năm 2012) từng có một daemon riêng tên ovs-brcompatd — "bridge compatibility mode" — cho phép brctl (công cụ điều khiển Linux bridge) tưởng như đang nói chuyện với một bridge thật, trong khi thực chất lệnh được dịch ngầm sang datapath của OVS. Ngay cả ở thời điểm đó, đây vẫn chỉ là một front-end dịch lệnh đứng ngoài, không phải code dùng chung giữa hai module — và khi OVS 1.10 đổi kiến trúc nội bộ, ovs-brcompatd bị bỏ hẳn vì quá khó duy trì song song. Không còn bản OVS hiện đại nào giả lập giao diện Linux bridge nữa.
4. Tiêu chí quyết định: khi nào Linux bridge đủ dùng, khi nào bắt buộc OVS
Ghép lại những gì Mục 2-3 vừa nói thành tiêu chí quyết định cụ thể — không phải "OVS luôn tốt hơn", mà "OVS giải quyết đúng những vấn đề Linux bridge không có công cụ để giải":
Linux bridge đủ dùng khi:
- Một host duy nhất, vài VM tĩnh, không cần thay đổi cấu hình thường xuyên.
- Không cần một hệ thống bên ngoài (orchestrator) tự động tạo/sửa/xóa cấu hình qua API — bạn cấu hình tay hoặc qua công cụ hệ thống (Netplan, systemd-networkd) là đủ.
- Không cần tunnel VXLAN/GRE/Geneve tích hợp — nếu có cần, bạn chấp nhận tự dựng interface
vxlanriêng và quản lý thủ công. - Không cần match/action theo từng flow (OpenFlow) — VLAN + iptables/nftables là đủ để phân vùng và lọc traffic.
- Ưu tiên footprint nhẹ: không có
ovs-vswitchd/ovsdb-serverchạy nền, không có thêm một tầng OVSDB phải học.
Bắt buộc hoặc nên dùng OVS khi:
- Nhiều host cần đồng bộ cấu hình qua một API chuẩn hóa (OVSDB) thay vì SSH vào từng máy.
- Cần tunnel VXLAN/GRE/Geneve như một loại port có sẵn, không phải ghép thêm interface riêng.
- Cần logic forward phức tạp theo flow — security group, logical routing, load balancing theo điều kiện packet — thứ OpenFlow làm được mà VLAN/iptables đơn thuần không làm được gọn.
- Cần tích hợp với một SDN controller (OVN, hoặc controller tự viết) để quản lý logic network tập trung.
- Cần visibility tích hợp sẵn: sFlow, IPFIX, port mirroring qua cấu hình OVSDB thay vì công cụ rời.
Nếu bạn đang lăn tăn giữa hai lựa chọn cho một lab cá nhân đơn giản, một host, không automation — Linux bridge nhẹ hơn thật, dùng nó. Nhưng ngay khi bài toán chạm tới nhiều host cần đồng bộ, tiêu chí quyết định gần như luôn nghiêng hẳn về OVS. Mục 5 là một ví dụ thực tế, ở quy mô công nghiệp, cho thấy điều đó.
5. Case thực tế: vì sao OpenStack khai tử driver Linux bridge
Nếu bạn muốn một bằng chứng cụ thể, không lý thuyết, cho tiêu chí ở Mục 4 — đây là một ví dụ hiếm khi tìm được rõ ràng đến vậy: OpenStack Neutron (thành phần networking của OpenStack) từng cho phép chọn giữa hai ML2 mechanism driver để dựng network cho VM — linuxbridge (dùng Linux bridge thuần, VXLAN qua interface vxlan riêng, security group qua iptables) và openvswitch (dùng OVS, OpenFlow, conntrack cho security group).
Số phận của driver linuxbridge đi đúng theo tiêu chí Mục 4 dự đoán:
- Bản Zed (Neutron 21.0.0): driver
linuxbridgebị đánh dấu experimental, do — nguyên văn release note — "lack of resources to maintain it" (thiếu nhân lực bảo trì). Từ đó, muốn tiếp tục dùng phải tự bật cờexperimentaltrong cấu hình. - Bản 2025.1 (Neutron 26.0.0): driver
linuxbridgebị gỡ bỏ hoàn toàn. Release note ghi rõ: "Users are advised to migrate to a different supported driver (OVS or, preferably, OVN) before upgrade." Không có công cụ migrate tự động — ai còn dùng phải tự chuyển tay.
Đây không phải OVS "thắng" vì mạnh hơn về mặt kỹ thuật thuần túy — Linux bridge vẫn làm tốt đúng việc nó được thiết kế để làm. Vấn đề là ở quy mô một nền tảng cloud orchestration thật (hàng trăm compute node, cần tunnel, cần security group phức tạp, cần automation), Linux bridge thiếu đúng những thứ Mục 4 liệt kê — và cộng đồng, khi phải chọn duy trì driver nào, đã chọn dồn lực vào OVS (và xa hơn là OVN, thứ Module 4 của loạt bài này sẽ nói tới).
6. CLI lab: dựng cả hai loại bridge cạnh nhau
Chưa cần cài OVS đầy đủ — Bài 4 sẽ làm kỹ phần đó. Ở đây chỉ cần dựng một Linux bridge thật để tự tay thấy các khái niệm ở Mục 2, và đối chiếu nhanh với OVS.
# Tạo Linux bridge bằng iproute2 (không dùng brctl — đã lỗi thời theo Mục 2)
sudo ip link add name br-linux type bridge
sudo ip link set br-linux up
# Xem trạng thái — chú ý flag NO-CARRIER/UP, và vlan_filtering mặc định = 0
ip -d link show br-linux
# Output minh họa (rút gọn)
5: br-linux: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
bridge forward_delay 1500 hello_time 200 max_age 2000
vlan_filtering 0 vlan_protocol 802.1Q
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Field vlan_filtering 0 xác nhận đúng điều Mục 2 vừa nói: dù chạy trên kernel hiện đại, VLAN-aware bridging vẫn tắt theo mặc định, phải tự bật.
# Bật VLAN filtering, gán 1 port vào bridge, rồi gán VLAN 100 cho port đó
sudo ip link set br-linux type bridge vlan_filtering 1
sudo ip link set veth0 master br-linux
sudo bridge vlan add vid 100 dev veth0
# So sánh: tạo bridge OVS (giả sử đã cài — Bài 4 hướng dẫn cài từ đầu)
sudo ovs-vsctl add-br br-ovs
sudo ovs-vsctl show
Điểm đáng chú ý khi so bridge vlan add vid 100 dev veth0 (Linux bridge) với việc gán VLAN kiểu OVS (ovs-vsctl set port <p> tag=100, sẽ thực hành kỹ ở Bài 5): cùng một khái niệm VLAN access port, nhưng một bên là lệnh netlink (giao thức socket kernel dùng để cấu hình network trực tiếp — nền tảng của cả ip link lẫn bridge) thao tác trực tiếp trên kernel bridge, một bên đi qua OVSDB — đúng khác biệt kiến trúc "config qua database" mà Bài 1 đã nói.
Nếu bạn chỉ nhớ được một điều sau bài này, hãy nhớ đúng điều ở Mục 3: OVS không phải Linux bridge "độ" thêm tính năng, mà là một switch được viết lại từ đầu — nắm chắc ranh giới đó, bạn sẽ thấy Bài 3 (kiến trúc ovs-vswitchd/datapath) dễ vào hơn nhiều.
Bài tập cuối bài
-
Dựng cả hai loại bridge theo lab ở Mục 6 trên cùng một máy test, rồi tự ghi lại (bằng bảng hoặc gạch đầu dòng) ít nhất 3 khác biệt về thao tác bạn nhận thấy — không chỉ chép lại lệnh, mà mô tả cảm nhận: lệnh nào trực quan hơn, lệnh nào cần nhớ nhiều cú pháp hơn.
(Gợi ý đối chiếu — không phải đáp án duy nhất, chỉ để tự so bảng ghi chú của bạn đã đủ ý chưa):
Thao tác Linux bridge OVS Tạo bridge ip link add ... type bridgeovs-vsctl add-brGán VLAN cho port bridge vlan add vid ... dev ...(đi qua netlink)ovs-vsctl set port ... tag=...(đi qua OVSDB)Xem toàn bộ cấu hình Phải gộp nhiều lệnh rời: ip -d link show,bridge vlan show,bridge linkMột lệnh duy nhất: ovs-vsctl show -
Tự tra
docs.openstack.orgbản release mới nhất, kiểm tra xem tình trạng driverlinuxbridgeở Mục 5 có thay đổi gì thêm không (đã hoàn toàn biến mất, hay có nỗ lực hồi sinh nào) — đối chiếu với thông tin trong bài, vì đây là thông tin có thể đổi theo thời gian.
Nguồn tham khảo
- VLAN-aware bridging (
CONFIG_BRIDGE_VLAN_FILTERING) được thêm vào kernel 3.9 (phát hành 4/2013), tắt theo mặc định — commit "bridge: Add vlan filtering infrastructure" (Vlad Yasevich), github.com/torvalds/linux, commit 243a2e63; xác nhận chéo qua kernelnewbies.org/Linux_3.9 và cateee.net LKDDB — BRIDGE_VLAN_FILTERING. - iproute2 hỗ trợ
bridge vlangần như cùng thời điểm với tính năng kernel (bản iproute2 3.9.0, phát hành 4/2013), không phải thêm nhiều năm sau — LWN.net: iproute2 3.9.0. brctl(8)được chính manpage Debian gọi là lỗi thời ("obsolete"), khuyến nghị dùng lệnhbridgetừ iproute2 vì đầy đủ tính năng hơn (STP guard, hairpin mode, fast leave, root block không có trong brctl) — Debian manpage: brctl(8).- Kernel bridge biên dịch sẵn mã STP 802.1D (
br_stp*.c) ngay trong modulebridge.ko; RSTP không nằm trong kernel, cần daemon userspacemstpd— docs.kernel.org/networking/bridge.html, Debian package: mstpd. openvswitch.ko(net/openvswitch/) vàbridge.ko(net/bridge/) là hai mục Kconfig, hai kernel module độc lập, không dùng chung code — net/openvswitch/Kconfig, net/bridge/Kconfig (torvalds/linux).- Driver ML2
linuxbridgecủa OpenStack Neutron bị đánh dấu experimental ở bản Zed do thiếu nhân lực bảo trì, rồi bị gỡ bỏ hoàn toàn ở bản 2025.1 (khuyến nghị chuyển sang OVS hoặc OVN) — OpenStack Neutron Zed Release Notes, OpenStack Neutron 2025.1 Release Notes. - OVS từng có daemon
ovs-brcompatdgiả lập giao diện Linux bridge chobrctl, nhưng bị gỡ bỏ hoàn toàn từ bản OVS 1.10 (2012) do đổi kiến trúc nội bộ khiến việc duy trì song song quá khó — Open Vswitch Releases FAQ, ovs-dev patch: "Remove Linux bridge compatibility".
Tiếp theo: Module 1, Bài 3 — Kiến trúc chi tiết: ovs-vswitchd, kernel datapath vs userspace datapath.