Skip to main content

OVS Phần 21: Tổng Kết & Thiết Kế — OVS vs Fabric VXLAN-EVPN Vật Lý

Phần 21/21 — bài chốt của loạt Open vSwitch (OVS). Hai mươi bài trước đã đi từ một câu hỏi rất cụ thể ở Phần 1 ("overlay có thể được terminate ở OVS hoặc ở leaf switch") tới toàn bộ chi tiết kỹ thuật cần để tự trả lời câu hỏi đó: cách OVS tự làm VTEP (Phần 9), cách OVN biến hàng trăm flow tay thành một control-plane phân tán (Phần 17), cách hai CMS lớn nhất (OpenStack, Kubernetes) cắm OVN vào thực tế (Phần 18, Phần 19), và cách debug toàn bộ chồng công nghệ đó khi nó hỏng (Phần 20). Bài này không dạy khái niệm mới nào ở tầng "cách cấu hình" — nó quay lại đúng câu hỏi kiến trúc ban đầu, trả lời nó cho trọn vẹn bằng mọi mảnh ghép đã học, và thêm đúng một phát hiện mới đủ quan trọng để không thể bỏ qua: OVN giờ có thể tự mình nói chuyện BGP EVPN thẳng với fabric vật lý, không cần leaf switch hay gateway trung gian nào làm hộ việc đó nữa.

Mục tiêu bài học: sau bài này bạn có trong tay một khung quyết định đầy đủ để chọn giữa ba kiến trúc thật — host-based thuần, network-based thuần, và kiến trúc hybrid (cổ điển hoặc native EVPN) — dựa trên đúng ba trục trade-off (ai giữ EVPN adjacency, ai scale MAC/ARP, ai chịu trách nhiệm troubleshoot) mà Phần 9 đã gieo hạt từ đầu Module 2; bạn hiểu đúng cơ chế OVN native BGP-EVPN dynamic routing (dynamic-routing-vni) — một mô hình thứ ba nằm ngoài hai cực đã học, biến hypervisor thành một PE/VTEP thật — và phân biệt được nó với ovn-bgp-agent (một dự án OpenStack hoàn toàn khác); và bạn tự viết được một trang thiết kế (design doc) chọn kiến trúc cho một tình huống cụ thể, tự justify được lựa chọn thay vì chọn theo cảm tính.

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

  1. Sau khi đã học đủ 20 bài, câu trả lời đầy đủ cho câu hỏi Bài 1 ("VXLAN terminate ở OVS hay ở leaf switch") là gì — và vì sao câu trả lời đúng không phải là chọn một trong hai, mà là hiểu rõ có ít nhất bốn kiến trúc khác nhau đang tồn tại trong thực tế?
  2. OVN native BGP-EVPN dynamic routing hoạt động ra sao, khác gì so với kiến trúc hybrid "cổ điển" (Geneve nội bộ + EVPN-VXLAN underlay tách biệt) đã có nền tảng từ Bài 9/17, và vì sao nó không phải cùng một thứ với ovn-bgp-agent?
  3. Với một tình huống triển khai cụ thể, làm sao chọn đúng kiến trúc — và trình bày lựa chọn đó thành một quyết định có thể bảo vệ được trước đội ngũ, không chỉ là cảm tính?

Mục lục​

1. Mở đầu: quay lại câu hỏi đã gieo từ Bài 1​

Phần 1, Mục 2 đóng lại bằng đúng một câu hỏi, cố tình để ngỏ: "bài toán kiến trúc thật sự thú vị nằm ở việc overlay có thể được terminate ở OVS (host-based VXLAN) hoặc ở leaf switch (network-based VXLAN), và lựa chọn này ảnh hưởng trực tiếp tới thiết kế fabric bạn đang vận hành." Hai mươi bài giữa đã lần lượt trang bị đủ công cụ để trả lời câu đó cho tử tế — không phải bằng một câu trả lời một dòng, mà bằng một khung quyết định thật.

Bài này không viết lại từ đầu. Phần 9, Mục 2 đã mổ xẻ đúng hai cực của câu hỏi này — VTEP host-based trong OVS và VTEP network-based ở leaf — kèm một dòng chú thích trong chính SVG của bài đó: "Câu hỏi kiến trúc này quay lại đầy đủ ở Bài 21." Đây chính là lúc quay lại giữ đúng lời hứa đó. Nhưng có một điều Bài 9 chưa thể nói tới, đơn giản vì tại thời điểm đó nó chưa tồn tại đủ ổn định để đưa vào bài: từ khoảng cuối 2025, OVN có thêm một tính năng native cho phép chính hypervisor tham gia BGP EVPN trực tiếp với fabric — không còn chỉ hai lựa chọn "OVS làm VTEP" hoặc "leaf làm VTEP" nữa, mà một dải kiến trúc rộng hơn hẳn. Mục 3-5 dưới đây trình bày đầy đủ dải đó.

2. Tổng kết 20 bài đã học​

Trước khi bàn tới kiến trúc, một bước lùi lại: 20 bài trước đã trang bị những gì, và mảnh nào trong số đó thật sự cần tới khi ra quyết định kiến trúc ở Mục 3-6? Bảng dưới đây tóm tắt 1-2 câu mỗi bài; cột cuối chỉ điền cho những bài có liên hệ trực tiếp tới câu hỏi trung tâm của bài này.

BàiChủ đềBài học chínhLiên hệ trực tiếp Bài 21
1Tổng quanOVS giải quyết bài toán multi-server virtualization (endpoint di động, cấu hình lập trình được, logical abstraction xuyên host); gieo câu hỏi trung tâm "VXLAN terminate ở OVS hay leaf"Câu hỏi mở đầu của cả series — Mục 1 vừa quay lại
2OVS vs Linux BridgeLinux bridge là kernel module riêng biệt (802.1D, tự STP); tiêu chí chọn OVS theo quy mô/nhu cầu automation—
3Kiến trúc bên trongBa mảnh ovsdb-server/ovs-vswitchd/datapath; OpenFlow flow (flow state) khác datapath flow (cache); 3 loại datapathNền tảng để hiểu vì sao OVN cần ovn-controller dịch tiếp xuống OpenFlow
4Cài đặt & lab đầu tiênHai đường cài (package thật / ovs-sandbox); lab tối thiểu 2 namespace qua 1 bridge OVSNguyên topology tái dùng ở Mục 7
5ovs-vsctl & OVSDBVòng đời bridge/port; gán VLAN tag=/trunks=; ovsdb-client dump; transaction atomicCú pháp nền cho mọi lệnh cấu hình ở Mục 7
6ovs-ofctl & OpenFlow cơ bảnOVSDB (config state) tách bạch flow table OpenFlow (flow state); NORMAL là fallback học-MAC—
7OVS + KVM/LibvirtGắn VM vào OVS qua virtualport type='openvswitch'; vnetX do libvirt tự quản—
8VLAN Trunking & Isolation5 giá trị vlan_mode; trunk port thật giữa 2 bridge; QinQ qua dot1q-tunnelGiới hạn 4094 VLAN là một lý do thực tế đẩy nhiều thiết kế sang host-based (Mục 3)
9Tunnel VXLAN/GRE/GeneveNền tảng trực tiếp của bài này. VTEP host-based (OVS) vs VTEP network-based (leaf); vì sao OVN chọn Geneve (55-bit metadata); OVN vẫn hỗ trợ VXLAN cho ToR vật lý qua VTEP schemaToàn bộ Mục 3-4 mở rộng trực tiếp từ đây
10Bonding/LACPBonding riêng tích hợp OVSDB, không dùng kernel bonding; 3 chế độ; liên hệ MLAG/vPCUplink redundancy trong sơ đồ hybrid ở Mục 4
11QoS & Rate Limitingingress_policing vs QoS/Queue (linux-htb) vs OpenFlow Meters—
12OpenFlow pipeline sâuMulti-table thật; goto_table (chuẩn) vs resubmit (OVS extension); ofproto/traceNền tảng đọc flow OVN thật ở Mục 7
13Connection tracking (conntrack)Action ct(), 8 flag ct_state, NAT qua nat()—
14DPDKBiến thể tăng tốc của datapath netdev; poll-mode driver bypass kernelLý do ovn-bgp-agent không tương thích DPDK (Mục 5)
15Hardware OffloadTC flower làm cầu nối offload xuống NIC/SmartNIC; hw-offload=true—
16Giám sát (sFlow/IPFIX/Mirror)3 cơ chế khác bản chất: full copy, sampling thống kê, flow record—
17OVN kiến trúcBài trung tâm Module 4. NB DB → ovn-northd → SB DB → ovn-controller → OpenFlow; logical switch/router mô phỏng phân tán; Geneve mang metadata vào metadata/reg14/reg15Toàn bộ khái niệm SB DB "nguồn sự thật dùng chung" bị native EVPN phá vỡ một phần (Mục 5)
18OVN trong OpenStack NeutronML2/OVS (agent Python, br-int/br-tun/br-ex) vs ML2/OVN (không br-tun, tunnel gắn thẳng br-int)ovn-bgp-agent (Mục 5) là dự án phụ trợ riêng của hệ sinh thái Neutron/OVN
19OVN trong KubernetesOVN-Kubernetes nhân bản OVN core theo "interconnect" (mỗi node một zone, transit-switch nối liên-zone); Antrea không dùng OVNOKEP-5088 (Mục 5) là đề xuất EVPN riêng cho nhánh CNI này
20Troubleshooting nâng caoQuy trình debug 5 bước tự tổng hợp (OVSDB → OpenFlow → datapath → NIC → log nội bộ); không có "OVS Troubleshooting Guide" chính thứcQuy trình này áp dụng nguyên vẹn khi debug kiến trúc hybrid ở Mục 7

Nhìn lại toàn bảng, có một điều đáng nói ngay: 16/20 bài không nói gì trực tiếp tới câu hỏi kiến trúc trung tâm — và đó là điều đúng đắn. Phần lớn kiến thức OVS (VLAN, QoS, conntrack, offload, giám sát...) áp dụng như nhau bất kể bạn chọn host-based hay network-based. Quyết định kiến trúc chỉ thật sự xoay quanh đúng 4-5 bài (9, 17, 18, 19, và một phần 20) — nhưng để hiểu vì sao quyết định đó khó, bạn cần toàn bộ nền tảng còn lại.

3. Bài toán kiến trúc cốt lõi: ba mô hình, ba trục trade-off​

Phần 9, Mục 2 đã trình bày đầy đủ hai cực — trích lại đúng nguyên văn phần cốt lõi:

"Host-based (VTEP trong OVS): [...] leaf switch không cần biết gì về VXLAN/EVPN cả [...] Đổi lại, mỗi hypervisor giờ phải tự vận hành một control-plane learn MAC [...] Network-based (VTEP ở leaf): [...] Chính leaf switch [...] mới là nơi đóng gói VXLAN, giữ BGP EVPN adjacency thật [...] Đội network giữ được toàn quyền quan sát/ACL/mirror tới tận từng MAC VM ngay tại leaf — thứ họ hoàn toàn mất quyền nhìn thấy ở mô hình host-based." — Phần 9, Mục 2

Mục 5 bài này thêm đúng một mô hình thứ ba — OVN native BGP-EVPN — nên trước khi đi sâu vào nó, hãy đặt cả ba cạnh nhau theo đúng ba trục trade-off outline gốc đã đặt ra: ai giữ EVPN adjacency, ai scale MAC/ARP ở đâu, và ai chịu trách nhiệm troubleshoot. Ở mô hình thứ ba, hypervisor sẽ tự đóng vai PE (Provider Edge — router biên trực tiếp giữ BGP EVPN adjacency với phần còn lại của mạng, khái niệm đã học ở loạt EVPN cùng repo) thay vì chỉ leaf switch mới được giữ vai trò đó.

💡 Hình dung như thế này: ba mô hình này giống ba cách một công ty vận chuyển quốc tế tổ chức việc thông quan. Network-based giống việc thuê hẳn một đại lý hải quan chuyên nghiệp (leaf switch) đứng ra khai báo, đóng gói, và chịu trách nhiệm với hải quan (BGP EVPN) — bạn (hypervisor) chỉ việc đưa hàng thô. Host-based thuần giống việc mỗi kho hàng (hypervisor) tự đóng gói, dán tem riêng theo quy tắc nội bộ công ty (SB DB) — không cần đại lý hải quan, nhưng hàng đó không được hải quan quốc tế công nhận, phải qua một cửa nhất định mới hợp lệ. OVN native EVPN giống việc chính kho hàng đó được cấp phép trở thành một chi nhánh hải quan chính thức (PE router) — tự khai báo trực tiếp với hải quan quốc tế, không cần trung gian nữa, nhưng đổi lại kho hàng đó giờ phải tự chịu trách nhiệm pháp lý mà trước kia chỉ đại lý mới phải lo.

Ba Mô Hình — Ba Trục Trade-offKhông có đáp án đúng tuyệt đối — chỉ có đánh đổi khác nhau theo từng trụcNetwork-based thuầnVTEP ở leaf (Bài 9)Host-based thuầnVTEP trong OVS (Bài 9/17)OVN native EVPNhypervisor = PE (Mục 5)Ai giữ EVPNadjacency?Leaf switch giữBGP EVPN thật với RR.Hypervisor khôngtham gia BGP.Không ai giữ BGPEVPN cả. OVN tự quảnqua SB DB (Bài 17) —cơ chế khác BGP hoàn toàn.ovn-controller + FRRtrên MỖI chassis giữEVPN adjacency thật —hypervisor = PE thật.Scale MAC/ARPở đâu?Type-2 route trongcontrol-plane BGP EVPN.Giới hạn: TCAM/forwarding-table của ASIC leaf.Port_Binding trong SB DB(RAFT cluster dùng chung).Giới hạn: RAM/CPU củaSB DB + từng ovn-controller.Type-2 EVPN thật, do FRRsinh — nhưng chỉ lưu localmemory từng chassis,KHÔNG qua SB DB.Ai chịu tráchnhiệm troubleshoot?Đội network — toolchainquen thuộc ngay tại leaf(show bgp evpn, show macaddress-table).Đội cloud/virtualization —ovn-trace, lflow-list, khớpcookie (Bài 17/20). Networkteam gần như "mù".CẢ HAI đội — lỗi có thể ởFRR, kernel VRF, hay logicOVN. Chi phí vận hành thật,không chỉ lợi ích.Mô hình thứ 3 không "tốt hơn" 2 mô hình cũ ở mọi mặt — nó đổi một bộ trade-off khác, còn rất mới (Mục 5)Đa số triển khai production hiện nay vẫn dùng 1 trong 2 mô hình đầu — xem khung quyết định Mục 6

Ba dòng cuối bảng trên nói cho hết một sự thật cần nhấn mạnh trước khi đi tiếp: mô hình thứ ba (Mục 5) không "thắng" hai mô hình cũ ở mọi mặt. Nó xóa bỏ ranh giới rạch ròi "OVS chỉ lo layer 2/3 nội bộ, leaf mới nói BGP" mà Bài 9/17 đã dạy — nhưng đổi lại, nó đòi hỏi cả đội network lẫn đội cloud cùng hiểu một hệ thống lai (FRR + kernel VRF + OVN logic) mà trước đây mỗi bên chỉ cần hiểu phần của mình.

4. Kiến trúc hybrid cổ điển: Geneve nội bộ, EVPN-VXLAN underlay và VTEP gateway​

Trong thực tế, gần như không triển khai nào là "thuần" 100% một trong hai cực ở Mục 3. Kiến trúc phổ biến nhất — gọi là "hybrid cổ điển" vì nó đã ổn định và được dùng rộng rãi từ trước khi Mục 5 xuất hiện — kết hợp cả hai theo đúng nguyên lý: hai loại overlay hoàn toàn tách biệt, không cần biết tới nhau.

  • OVN/OVS làm overlay tenant bên trong host: logical network (Phần 17) dùng Geneve giữa các hypervisor, giải quyết đúng bài toán multi-tenant isolation trong cloud.
  • Fabric vật lý làm underlay EVPN-VXLAN thuần túy: leaf/spine chỉ cần route được IP giữa các hypervisor — đúng vai trò "underlay" mà loạt EVPN cùng repo đã định nghĩa. Fabric hoàn toàn không "thấy" logical network bên trong OVN, chỉ thấy một luồng UDP Geneve giữa các VTEP-IP của hypervisor — y hệt điều Phần 9, Mục 6 đã chứng minh bằng tcpdump: NIC transport không hề biết gì về IP nội bộ của VM.
  • VXLAN gateway biên, đúng hai trường hợp có cơ sở chính thức — không phải "gateway cho mọi thứ" như cách nói mơ hồ thường gặp:
    1. Bare-metal server cần vào logical network OVN. Phần 9, Mục 2 đã trích FAQ chính thức OVN: "OVN does support VXLAN for use with ASIC-based top of rack switches, using ovn-controller-vtep(8) and the OVSDB VTEP schema". Một ToR switch vật lý hỗ trợ VTEP schema đóng vai trò VTEP thay cho server không chạy được OVS — Phần 17, Mục 3 đã liệt kê đúng hai loại LSP phục vụ việc này: vtep, l2gateway.
    2. Nối hai vùng L3 khác nhau (liên-DC, hoặc ra ngoài tenant network). Đây là điểm dễ hiểu nhầm nhất: không phải lúc nào cũng cần một "gateway" đổi encapsulation. Phần lớn trường hợp chỉ cần layer 3 routing bình thường — traffic đã decap ra IP thường trước khi rời một trong hai domain, rồi định tuyến qua Border Leaf bằng Type 5 route (loạt EVPN cùng repo đã dạy khái niệm này), phía OVN thì qua Gateway Router/localnet LSP ra provider network (Phần 17/18). Hai overlay không cần nói chung một encapsulation — chúng chỉ cần route được tới nhau ở layer 3.
Kiến Trúc Hybrid Cổ Điển — Hai Overlay Tách Biệt Hoàn ToànGeneve (tenant, trong host) và EVPN-VXLAN (underlay, fabric) không cần nói chung 1 encapsulationHypervisor AVM (vNIC)OVN logical switch/routerbr-int — flow OpenFlow (Bài 17)Geneve tunnel portVTEP-IP host = 1 endpoint duy nhấtHypervisor BVM (vNIC)OVN logical switch/routerbr-int — flow OpenFlow (Bài 17)Geneve tunnel portVTEP-IP host = 1 endpoint duy nhấtGeneve — overlay tenant, tách biệt hoàn toànuplink NICuplink NICLeaf switch — chỉ thấy 2 IP VTEP host đang nói UDP GeneveKhông biết gì về VM/logical network bên trong — đúng bài học Bài 9 Mục 6Spine — Route Reflector giữ BGP EVPN adjacency thật với mọi leafUnderlay EVPN-VXLAN thuần túy — chỉ route IP giữa các VTEP-host, không "thấy" tenantBorder Leaf — Type 5 routeLayer 3 routing thuần, không đổi encapBare-metalqua ToR VTEPovn-controller-vtepWAN / DC khácliên-DC (DCI)Hai overlay không cần nói chung 1 encapsulation — chỉ cần route được tới nhau ở layer 3.VTEP gateway (ovn-controller-vtep + VTEP schema) chỉ dùng cho bare-metal cần vào chínhlogical network OVN — không phải cơ chế nối "Geneve nói chuyện với EVPN-VXLAN".Đây là kiến trúc phổ biến nhất production hiện nay — xem Mục 5 cho kiến trúc mới hơnvà Mục 6 cho khung quyết định giữa hai kiến trúc.

5. Kiến trúc hybrid mới: OVN nói chuyện trực tiếp BGP EVPN với fabric​

Đây là phần khiến bài này không lỗi thời ngay khi xuất bản. Từ OVN 25.09.0, có thêm một tính năng native cho phép chính logical switch/router trong OVN tham gia BGP EVPN thật với fabric — không qua bất kỳ gateway hay VTEP schema trung gian nào của Mục 4. Tài liệu kiến trúc chính thức gọi đây là Dynamic Routing Integration, chia làm hai mảnh tách biệt: IP Route Exchange (trao đổi route thuần layer 3, đã ổn định từ OVN 25.03) và EVPN (mảnh layer 2, mới hơn, chính là trọng tâm mục này).

5.1 Cơ chế: dynamic-routing-vni, FRR, và hypervisor trở thành PE thật​

EVPN được bật bằng cách gán other_config:dynamic-routing-vni lên một Logical Switch với một giá trị VNI hợp lệ — tài liệu chính thức viết thẳng: "EVPN is enabled on a logical switch by setting the dynamic-routing-vni option to a valid VNI (VXLAN Network Identifier) value (0–16777215)." Ba interface bắt buộc đi kèm: dynamic-routing-bridge-ifname (Linux bridge đại diện domain EVPN), dynamic-routing-vxlan-ifname (device VXLAN dùng cho traffic EVPN), và dynamic-routing-advertise-ifname (interface dùng để quảng bá MAC/IP cục bộ cho routing daemon).

Chuỗi sự kiện, đối chiếu trực tiếp với kiến trúc SB DB đã học ở Phần 17:

  1. FRR (Free Range Routing, chạy trên từng chassis) giữ BGP EVPN adjacency thật với fabric — đúng nghĩa đen "nói chuyện BGP", không phải một cơ chế nội bộ OVN nào giả lập lại BGP.
  2. ovn-controller giám sát ba interface EVPN kể trên, học remote VTEP, MAC (FDB), và ARP/ND neighbor — những thứ FRR đã học được qua BGP EVPN và cài vào bảng kernel (bridge FDB, VXLAN FDB, ARP/ND neighbor table).
  3. Từ dữ liệu học được đó, ovn-controller tự tạo VXLAN tunnel port dạng flow-based ngay trong br-int — không cần một bridge tunnel riêng như br-tun của ML2/OVS (Phần 18).
  4. Chiều ngược lại: ovn-controller cài static FDB/ARP-ND cho workload cục bộ lên interface advertise; FRR đọc các entry đó từ kernel và tự sinh EVPN Type-2 route thật (route quảng bá cặp MAC/IP — loạt EVPN cùng repo đã dạy khái niệm này) gửi ra fabric.

Điểm kiến trúc quan trọng nhất, đáng một cảnh báo riêng: dữ liệu EVPN học động (remote VTEP, MAC, IP neighbor) không lưu vào SB DB — tài liệu chính thức nói rõ: "Dynamically learned EVPN information (remote VTEPs, MAC addresses, IP neighbors) is not stored in the OVN Southbound database. Instead, each ovn-controller instance processes this information locally, in memory." Đây là một khác biệt lớn so với mọi thứ Phần 17 đã dạy — nơi SB DB luôn đóng vai trò "nguồn sự thật dùng chung" cho toàn hệ thống. Với dữ liệu EVPN động, mỗi ovn-controller tự giữ một bản riêng, không đồng bộ qua cụm RAFT.

Cổ Điển vs Native EVPN — Ai Thật Sự Nói BGP?Cổ điển (Mục 4) — leaf là PE duy nhấtNative EVPN (Mục 5) — hypervisor cũng là PEHypervisor: chỉ OVN + Geneve nội bộKhông FRR, không BGPHypervisor: OVN + FRR chạy trênCHÍNH chassis đó — dynamic-routing-vniuplink — chỉ UDP Geneve đơn thuầnuplink — mang cả UDP VXLAN + gói BGP EVPNLeaf switch — PE duy nhất, giữBGP EVPN adjacency thật với spineLeaf switch — CHỈ còn một PE trongsố nhiều PE (hypervisor cũng là PE)Ranh giới "OVS chỉ overlay nội bộ, leaf mới nói EVPN" (Bài 9/17) không còn tuyệt đối.Đổi lại: dữ liệu EVPN học động chỉ tồn tại local memory từng ovn-controller,KHÔNG qua SB DB — phá một giả định Bài 17 đã dạy về "SB DB là nguồn sự thật chung"

5.2 Mốc phiên bản — đã tự verify lại qua NEWS gốc, không dùng nguyên trạng từ file research​

Vì tính năng này phát triển rất nhanh, các mốc dưới đây được verify trực tiếp từ file NEWS trên nhánh main của kho mã nguồn OVN (không chỉ dựa vào tóm tắt gián tiếp):

  • OVN 25.09.0 — thêm other_config:dynamic-routing-vni: nguyên văn NEWS "Add the "other_config:dynamic-routing-vni" to Logical Switches. If set to valid integer the LS is considered to be connected to EVPN L2 domain." Tại mốc này, EVPN còn đang gắn nhãn thử nghiệm.
  • OVN 26.03.0 — nhãn thử nghiệm được gỡ: nguyên văn NEWS "The EVPN support is now considered stable. Its "experimental" tag has been removed." Cùng bản này, OVN mở rộng thêm khả năng tự học IP neighbor (Type-2 MAC+IP) và tiêm thẳng vào pipeline logical router liên quan.
  • Cần verify thêm: file NEWS trên nhánh main hiện vẫn ghi ngày phát hành của cả hai mục trên dưới dạng placeholder (xxx xx xxxx) thay vì ngày cụ thể — đây là cách OVN duy trì NEWS trên nhánh phát triển (ngày thật chỉ được điền khi cắt bản release chính thức). Vì vậy bài này không khẳng định ngày phát hành chính xác của 25.09.0/26.03.0, chỉ khẳng định chắc chắn thứ tự và nội dung hai mốc trên — nếu cần ngày cụ thể, tra lại trực tiếp trang release notes tại thời điểm đọc.
  • Ngoài EVPN (layer 2), OVN còn một mảnh liên quan nhưng tách biệt — IP Route Exchange (trao đổi route layer 3 thuần, bảng Advertised_Route/Learned_Route, không cần VNI) — đã ổn định sớm hơn, từ khoảng OVN 25.03.0. Hai mảnh này thường bị gộp chung khi nói "OVN dynamic routing", nhưng chỉ EVPN (Mục 5.1) mới đúng nghĩa "hypervisor trở thành VTEP/PE tham gia BGP EVPN" mà bài này tập trung.

⚠️ Về mức độ trưởng thành/adoption: tính năng này còn rất mới (ổn định từ 26.03.0). Không có số liệu khảo sát/adoption chính thức nào được tìm thấy tại thời điểm viết bài — nói "hiếm khi dùng trong production" là một suy đoán hợp lý dựa trên độ mới của tính năng, không phải một số liệu đã kiểm chứng. Cách diễn đạt an toàn: đây là tính năng ổn định về mặt kỹ thuật, nhưng chưa có dữ liệu adoption rộng rãi tại thời điểm loạt bài này được viết — tự kiểm tra lại tình hình thực tế trước khi đặt cược một triển khai production mới vào nó.

5.3 Đừng gộp nhầm: ovn-bgp-agent là một dự án khác​

Đây là cái bẫy dễ gặp nhất khi tìm hiểu thêm ngoài bài này: ovn-bgp-agent nghe rất giống nhưng là một dự án hoàn toàn tách biệt khỏi tính năng native ở Mục 5.1-5.2.

OVN native EVPN (Mục 5.1)ovn-bgp-agent
Thuộc vềOVN core, dùng chung cho mọi CMSDự án phụ trợ riêng của hệ sinh thái OpenStack Neutron/OVN (Phần 18)
Bài toán giải quyếtHypervisor tham gia BGP EVPN thật với fabricMulti-tenant với overlapping subnet CIDR giữa các tenant — thứ BGP thường không phân biệt được
Cấu hình quaother_config:dynamic-routing-vni trực tiếp trên Logical SwitchAPI networking-bgpvpn (admin/tenant) + annotate qua external_ids
Cơ chế steer trafficFlow-based VXLAN tunnel port ngay trong br-int, ovn-controller cài FDB/ARP-NDKernel routing (VRF Linux, VXLAN device, Bridge) để steer traffic vào VRF
Tương thích DPDK/SR-IOVKhông bị giới hạn theo tài liệu OVN core (Bài 14)Không hỗ trợ — tài liệu chính thức nói thẳng: "Network traffic is steer by kernel routing (VRF, VXLAN, Bridges), therefore DPDK, where the kernel space is skipped, is not supported", và tương tự với SR-IOV

Nếu triển khai của bạn đang dùng OVS-DPDK (Phần 14) hoặc SR-IOV, ovn-bgp-agent loại trừ ngay từ đầu — nhưng tính năng native ở Mục 5.1 không có giới hạn tương tự vì nó không steer traffic qua kernel routing theo cùng cách.

5.4 Hướng mở rộng cho Kubernetes: OKEP-5088 — đề xuất thiết kế, chưa triển khai​

Ở phía OVN-Kubernetes (Phần 19), có một đề xuất thiết kế riêng đáng nhắc: OKEP-5088, mang EVPN vào UserDefinedNetwork (UDN — tính năng đa mạng logic per-namespace, nằm ngoài phạm vi "default network" mà Bài 19 đã học). File research chuẩn bị cho bài này ghi nhận URL tài liệu 404 tại thời điểm research; lúc viết bài, URL trang docs (ovn-kubernetes.io/okeps/okep-5088-evpn/) vẫn 404 khi truy cập trực tiếp, nhưng nội dung gốc được xác nhận đọc được qua kho mã nguồn chính thức trên GitHub (ovn-kubernetes/ovn-kubernetes, nhánh master, docs/okeps/okep-5088-evpn.md) — đủ tin cậy để trích dẫn có kiểm chứng, khác với việc chỉ dựa vào snippet công cụ tìm kiếm như bản research ban đầu.

Vài điểm cốt lõi, trích trực tiếp từ tài liệu đề xuất:

  • Mục tiêu: "FRR providing EVPN connectivity via BGP and acting as the Kubernetes worker node PE router." — mỗi worker node trở thành PE, đúng tinh thần Mục 5.1 nhưng áp riêng cho UDN thay vì mọi logical switch.
  • Khi bật EVPN, Geneve không còn được dùng cho chính UDN đó — tài liệu nói rõ: với UDN đã bật EVPN, VXLAN thay thế Geneve làm overlay layer 2, còn layer 3 dùng routing per-node thuần túy qua FRR/VRF. Đây là điểm khác biệt quan trọng: EVPN ở đây không phải "một lớp gateway phụ thêm" mà là thay thế hẳn cơ chế vận chuyển mặc định của riêng UDN đó.
  • Giới hạn nêu rõ trong tài liệu: "Support for EVPN in local gateway mode only" và "Support for EVPN in on-prem deployments only" — chưa hỗ trợ shared gateway mode hay các nền tảng Kubernetes managed trên cloud.
  • Đây là một đề xuất thiết kế (OKEP), không phải tính năng đã merge/vận hành — các phần "Future-Goals" của tài liệu còn liệt kê cả việc "hỗ trợ liên kết hai cụm Kubernetes qua EVPN rồi cho phép di chuyển VM giữa chúng" như một mục tiêu tương lai, chưa phải hiện tại.

Nói ngắn gọn: nếu bạn đang vận hành OVN-Kubernetes và cân nhắc EVPN, đây là hướng đang được thiết kế, không phải thứ có thể bật lên hôm nay như tính năng OVN core ở Mục 5.1.

6. Khung quyết định: chọn mô hình nào cho tình huống của bạn​

Không có một "kiến trúc đúng" áp dụng mọi nơi — bảng dưới đây là khung câu hỏi để tự đánh giá, không phải một quyết định sẵn.

Câu hỏiNghiêng về...
Đã có sẵn fabric EVPN-VXLAN vật lý trưởng thành, đội network mạnh, muốn giữ toàn quyền quan sát tới từng MAC VM?Network-based thuần (Mục 3) — nhưng đánh đổi trần VLAN 4094 nếu không dùng EVPN Type 5/routing giữa domain
Cần multi-tenant nặng, đội cloud/K8s mạnh hơn network, không muốn phụ thuộc trần VLAN vật lý, chấp nhận network team "mù" traffic nội bộ?Host-based thuần (Mục 3), thường qua OVN (Phần 17)
Có cả tenant logic phức tạp (OVN) lẫn fabric EVPN vật lý sẵn có, cần cả hai cùng tồn tại, có bare-metal cần vào chung logical network?Hybrid cổ điển (Mục 4) — kiến trúc production phổ biến nhất hiện nay
Muốn xóa ranh giới network/cloud, để chính hypervisor tham gia BGP EVPN thật, đội ngũ đủ năng lực vận hành cả FRR lẫn OVN, và chấp nhận rủi ro của một tính năng còn mới?OVN native EVPN (Mục 5.1) — cân nhắc kỹ mức độ trưởng thành trước khi đặt vào production
Dùng OpenStack, cần multi-tenant với subnet CIDR trùng nhau giữa tenant, KHÔNG dùng DPDK/SR-IOV?Cân nhắc ovn-bgp-agent (Mục 5.3) — không phải thứ thay thế Mục 5.1
Dùng OVN-Kubernetes, cần UDN nối ra ngoài qua EVPN?Theo dõi OKEP-5088 (Mục 5.4) — chưa sẵn sàng production tại thời điểm viết bài
Dùng OVS-DPDK hoặc SR-IOV?Loại trừ ngay ovn-bgp-agent; các mô hình còn lại vẫn khả thi
Khung Quyết Định — 4 Nhánh Chính, 2 Ca Đặc BiệtKhông có nhánh nào "đúng tuyệt đối" — chỉ có nhánh khớp nhất với ràng buộc thật của bạnTình huống triển khai của bạnnghiêng về đặc điểm nào?Network-based thuầnFabric EVPN trưởng thành,đội network mạnh, cần thấyMAC VM tận leafMục 3Host-based thuầnMulti-tenant nặng, độicloud mạnh hơn, không phụthuộc trần VLAN vật lýMục 3, qua OVNHybrid cổ điểnCó cả OVN lẫn fabric EVPNsẵn có, bare-metal cần vàochung logical networkMục 4 — phổ biến nhấtOVN native EVPNMuốn xóa ranh giới network/cloud, đủ năng lực FRR+OVN,chấp nhận rủi ro tính năng mớiMục 5.1Dùng OpenStack, tenant CIDR trùng nhau, KHÔNG DPDK/SR-IOV?→ cân nhắc ovn-bgp-agent (Mục 5.3) — không thay thế 4 nhánh trênDùng OVN-Kubernetes, UDN cần nối ra ngoài qua EVPN?→ theo dõi OKEP-5088 (Mục 5.4) — chưa sẵn sàng productionKhông có nhánh nào "thắng" tuyệt đối — chọn theo đúng ba trục trade-off Mục 3

7. CLI lab tổng hợp: một luồng traffic đầy đủ từ VM tới fabric​

Không có lệnh nào mới ở đây — mục này chỉ xâu chuỗi lại đúng những lệnh đã dùng thật ở Bài 4-17, theo đúng thứ tự một packet đi từ VM tới fabric vật lý trong kiến trúc hybrid cổ điển (Mục 4), rồi chỉ ra bước nào khác đi nếu chuyển sang native EVPN (Mục 5).

# 1. Xác nhận OVS đã sẵn sàng trên hypervisor (Bài 4)
sudo ovs-vsctl show

# 2. OVN tự tạo br-int khi ovn-controller khởi động (Bài 17 Mục 6) — không cần add-br tay
sudo ovs-vsctl set Open_vSwitch . external_ids:system-id="chassis-a"
sudo ovs-vsctl set Open_vSwitch . external_ids:ovn-remote="tcp:127.0.0.1:6642"
sudo ovs-vsctl set Open_vSwitch . external_ids:ovn-encap-type="geneve"
sudo ovs-vsctl set Open_vSwitch . external_ids:ovn-encap-ip="10.0.0.11"

# 3. Tạo logical network qua ovn-nbctl (Bài 17 Mục 4) — CMS thật (Neutron/Kubernetes,
#    Bài 18/19) làm việc này tự động, ở đây gõ tay để thấy rõ từng bước
ovn-nbctl ls-add sw0
ovn-nbctl lsp-add sw0 sw0-port1
ovn-nbctl lsp-set-addresses sw0-port1 "50:54:00:00:00:01 192.168.0.2"

# 4. Verify logic đã lan đúng xuống flow OpenFlow thật (Bài 17 Mục 6, Bài 12)
ovn-trace --summary sw0 'inport == "sw0-port1" && eth.src == 50:54:00:00:00:01'
sudo ovs-ofctl dump-flows br-int | grep "cookie=0x"

# 5. Traffic liên-hypervisor rời br-int qua Geneve (Bài 9 Mục 3) — leaf switch
#    chỉ thấy đúng 1 luồng UDP giữa 2 VTEP-IP host, xác nhận bằng tcpdump như Bài 9 Mục 6
sudo tcpdump -i eth0 -vv udp port 6081

# 6. Nếu traffic cần ra khỏi domain OVN (bare-metal, DCI) — kiểm tra localnet/gateway
#    router đã cấu hình đúng chưa (Bài 17/18), rồi xác nhận route Type 5 phía fabric
#    bằng toolchain BGP EVPN quen thuộc (loạt EVPN cùng repo) — ngoài phạm vi OVS.

# 7. Nghi ngờ có lỗi ở bất kỳ bước nào? Áp đúng quy trình 5 bước Bài 20:
#    OVSDB (bước 1-2) -> OpenFlow (bước 3-4) -> datapath -> NIC -> log nội bộ.

Nếu chuyển sang native EVPN (Mục 5.1): bước 2-3 giữ nguyên, nhưng bridge br-int giờ có thêm tunnel port flow-based do ovn-controller tự tạo từ dữ liệu FRR học được qua BGP EVPN thật — không cấu hình ovn-nbctl thêm cho phần này (cấu hình nằm ở other_config:dynamic-routing-vni trên Logical Switch, và ba interface dynamic-routing-* đã nói ở Mục 5.1). Bước debug ở bước 7 cần thêm log/trạng thái của FRR (vtysh -c "show bgp l2vpn evpn" — lệnh FRR, ngoài phạm vi series này) bên cạnh toolbox OVS đã học ở Bài 20, đúng chi phí vận hành đã cảnh báo ở Mục 3.

Một Luồng Traffic Đầy Đủ — VM Tới Fabric Vật LýKiến trúc hybrid cổ điển (Mục 4) — 2 điểm khác biệt khi dùng native EVPN (Mục 5) đánh dấu bên phải1. OVS sẵn sàng, chassis đăng ký với OVNovs-vsctl show / set external_ids:ovn-* (Bài 4)2-3. Logical network qua ovn-nbctl → br-intOVN tự dịch xuống flow OpenFlow thật (Bài 17)Native EVPN: br-int có thêmtunnel port flow-based tự tạotừ FRR — không qua ovn-nbctl4. Verify flow thật đã lan xuống br-intovn-trace / ovs-ofctl dump-flows (Bài 12/17)5. Geneve rời uplink NICtcpdump xác nhận 1 luồng UDP giữa 2 VTEP-IP (Bài 9)Leaf switch — chỉ thấy 2 VTEP-IP nói GeneveKhông biết gì về VM/logical network (Mục 4)6-7. Ra ngoài domain? Type 5 route ở BorderLeaf. Lỗi ở đâu? Áp quy trình 5 bước Bài 20Native EVPN: thêm bước đọctrạng thái FRR (vtysh show bgpl2vpn evpn) cạnh toolbox Bài 20Không có lệnh nào mới ở đây — chỉ xâu chuỗi lại đúng những lệnh đã dùng thật ở Bài 4-17

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

Viết một trang thiết kế (design doc) ngắn — không quá một trang — cho tình huống sau, rồi tự justify lựa chọn bằng đúng khung Mục 6:

Công ty bạn có 50 hypervisor, cần chạy multi-tenant (nhiều khách hàng, mạng ảo cô lập nhau), và đã có sẵn một fabric EVPN-VXLAN vật lý đang chạy ổn định cho các workload bare-metal khác trong cùng data center. Đội network có kinh nghiệm vận hành BGP EVPN tốt; đội cloud vừa mới bắt đầu học OVN qua loạt bài này.

Design doc cần trả lời tối thiểu:

  1. Chọn kiến trúc nào trong bốn mô hình đã học (host-based thuần, network-based thuần, hybrid cổ điển, OVN native EVPN) — và một câu giải thích "vì sao không chọn ba cái còn lại", không chỉ nói "vì cái này tốt".
  2. Ai giữ EVPN adjacency, ai scale MAC/ARP, ai troubleshoot trong lựa chọn của bạn — dùng đúng ba trục Mục 3, áp cụ thể vào tình huống 50 hypervisor này (không phải trả lời chung chung).
  3. VXLAN gateway/Border Leaf có cần không — nếu tenant cần ra ngoài (Internet, DCI), bạn định route ở đâu?
  4. Có đáng cân nhắc OVN native EVPN (Mục 5) cho tình huống này không? Với dữ kiện "đội cloud vừa mới học OVN", hãy tự đánh giá thẳng thắn: chi phí vận hành thêm một mảnh FRR + kernel VRF có đáng đánh đổi lấy việc xóa ranh giới network/cloud hay không — không có đáp án "đúng" duy nhất, nhưng câu trả lời phải có lý do, không phải cảm tính.
  5. Một rủi ro/giới hạn cụ thể của lựa chọn bạn chọn — không design doc nào hoàn hảo, và biết trước rủi ro là một phần của thiết kế tốt.

Không cần nộp CLI thật — đây là bài tập tư duy kiến trúc, đúng tinh thần "bài chốt series": kiểm tra bạn có dùng được toàn bộ 20 bài trước để tự ra quyết định, không chỉ nhớ cú pháp.

Lời kết: hành trình 21 bài​

Series này bắt đầu bằng một câu hỏi tưởng như đơn giản — OVS là gì, và vì sao Linux bridge không đủ cho môi trường ảo hóa đa server — rồi đi qua bốn module: nền tảng công cụ (ovs-vsctl/ovs-ofctl), một OVS đơn lẻ trong topology thật (VLAN, tunnel, bonding, QoS), OVS ở mức thực chiến (pipeline sâu, conntrack, DPDK, offload, giám sát), và cuối cùng là SDN tích hợp thật (OVN, Neutron, Kubernetes, troubleshooting). Hai mươi bài đó không phải hai mươi mảnh rời rạc — chúng cùng xây một câu trả lời cho đúng một câu hỏi kiến trúc đã đặt ra từ Bài 1, và bài này là nơi câu trả lời đó được ráp lại đầy đủ.

Nếu chỉ giữ lại một điều sau toàn bộ 21 bài, hãy giữ lại điều này: không có kiến trúc mạng "đúng tuyệt đối" — chỉ có đánh đổi phù hợp với đúng ràng buộc bạn đang có (đội ngũ, fabric sẵn có, mức độ multi-tenant, khẩu vị rủi ro với tính năng mới). OVN native BGP-EVPN ở Mục 5 là bằng chứng rõ nhất cho điều đó: nó không "thay thế" hai mô hình cũ, nó chỉ thêm một điểm nữa trên cùng một trục đánh đổi mà Bài 9 đã vẽ ra từ đầu Module 2. Công cụ và kiến trúc sẽ còn thay đổi tiếp sau ngày bài này được viết — nhưng ba trục trade-off (EVPN adjacency, scale MAC/ARP, ai troubleshoot) sẽ còn đúng lâu hơn bất kỳ tên tính năng cụ thể nào.

Cảm ơn bạn đã đi hết 21 bài.

Nguồn tham khảo​

  • Câu hỏi mở đầu "overlay có thể được terminate ở OVS hoặc ở leaf switch" — Phần 1, Mục 2 cùng series.
  • Đối lập VTEP host-based/network-based, trích dẫn FAQ OVN về ovn-controller-vtep/VTEP schema — Phần 9, Mục 2 cùng series.
  • Kiến trúc OVN core (NB DB/ovn-northd/SB DB/ovn-controller), các loại LSP vtep/l2gateway — Phần 17 cùng series.
  • Kiến trúc ML2/OVS vs ML2/OVN, br-int/br-tun/br-ex — Phần 18 cùng series.
  • Kiến trúc OVN-Kubernetes interconnect (zone, transit-switch) — Phần 19 cùng series.
  • Quy trình debug 5 bước tự tổng hợp — Phần 20 cùng series.
  • Khái niệm RD/RT, Route Type 1-2-3-5, ARP suppression, Symmetric/Asymmetric IRB, EVPN Multi-Homing (ESI), Type 5 IP Prefix Route/Border Leaf — EVPN Phần 1, EVPN Phần 2, EVPN Phần 3 cùng repo.
  • other_config:dynamic-routing-vni, ba interface dynamic-routing-bridge-ifname/dynamic-routing-vxlan-ifname/dynamic-routing-advertise-ifname, cơ chế FRR + ovn-controller học/cài FDB-ARP/ND qua kernel, và xác nhận dữ liệu EVPN học động không lưu SB DB ("processes this information locally, in memory") — verify trực tiếp 2026, Dynamic Routing Integration — docs.ovn.org.
  • Mốc dynamic-routing-vni thêm ở OVN 25.09.0 và nhãn "experimental" bị gỡ ở OVN 26.03.0 ("The EVPN support is now considered stable. Its "experimental" tag has been removed."), cùng mốc dynamic-routing/Learned_Route (IP Route Exchange) ổn định từ OVN 25.03.0 — verify trực tiếp từ file nguồn 2026, NEWS — github.com/ovn-org/ovn (nhánh main).
  • Kiến trúc ovn-bgp-agent: giải quyết overlapping tenant CIDR, dùng kernel VRF/VXLAN/Bridge + FRR + API networking-bgpvpn, và xác nhận trực tiếp không hỗ trợ DPDK/SR-IOV ("Network traffic is steer by kernel routing (VRF, VXLAN, Bridges), therefore DPDK... is not supported") — verify trực tiếp 2026, EVPN driver design — docs.openstack.org/ovn-bgp-agent.
  • OKEP-5088 (đề xuất EVPN cho OVN-Kubernetes UDN): mục tiêu, kiến trúc VRF/FRR/PE router, thay thế Geneve bằng VXLAN cho UDN đã bật EVPN, giới hạn "local gateway mode only"/"on-prem deployments only" — trang docs chính thức (ovn-kubernetes.io/okeps/okep-5088-evpn/) trả về 404 tại thời điểm viết bài; nội dung verify qua nguồn markdown gốc 2026, okep-5088-evpn.md — github.com/ovn-kubernetes/ovn-kubernetes (nhánh master).

Đây là bài cuối cùng của loạt Open vSwitch (OVS) — 21/21.