Skip to main content

OVS Phần 17: OVN — Logical Switching/Routing và Distributed Control Plane

Phần 17/21 trong loạt Open vSwitch (OVS) — mở đầu Module 4: Chuyên gia/SDN tích hợp, sau khi Module 3 (Bài 12-16) đã đào sâu một OVS đơn lẻ hết mức: pipeline OpenFlow nhiều bảng, conntrack, DPDK, hardware offload, giám sát. Bài 1 Mục 3 đã nhắc tên OVN và nói OVN dùng "cả OVSDB lẫn OpenFlow", kể tên ovn-controller cùng Northbound DB/Southbound DB — nhưng bỏ sót hẳn một mảnh trung tâm: ovn-northd. Bài 17 vá đúng mảnh còn thiếu đó và dựng lại toàn cảnh kiến trúc OVN từ đầu.

Mục tiêu bài học: sau bài này bạn nắm đúng luồng dữ liệu NB DB → ovn-northd → SB DB → ovn-controller → OpenFlow, hiểu vì sao cần một "trình biên dịch" (ovn-northd) đứng giữa thay vì để ovn-controller đọc thẳng cấu hình logic; phân biệt được logical switch/logical router (khái niệm CMS-facing, nằm trong NB DB) với logical flow (dạng đã biên dịch, nằm trong SB DB); tự tạo được logical switch/router bằng ovn-nbctl thật; và verify được bằng ovn-trace cùng ovs-ofctl dump-flows — kể cả cách khớp trực tiếp một OpenFlow flow với đúng logical flow đã sinh ra nó.

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

  1. ovn-northd đóng vai trò gì giữa NB DB và SB DB mà Bài 1 chưa nói tới, và vì sao OVN cần một "trình biên dịch" đứng giữa thay vì để ovn-controller đọc thẳng cấu hình logic?
  2. Tạo một logical switch/logical router bằng ovn-nbctl thì thực chất đang ghi vào bảng nào, và ai biến nó thành flow chạy thật trên hypervisor?
  3. Làm sao xác nhận một logical switch port cụ thể đã thật sự trở thành OpenFlow flow trên đúng hypervisor, không chỉ tin tưởng suông rằng "OVN lo hết"?

Mục lục​

1. Từ Bài 1 tới mảnh còn thiếu: ovn-northd là gì​

Tài liệu kiến trúc chính thức liệt kê đúng các thành phần của một triển khai OVN, theo đúng thứ tự từ trên xuống: "A Cloud Management System (CMS)... The OVN/CMS Plugin... The OVN Northbound Database... ovn-northd(8)... The OVN Southbound Database... ovn-controller(8)... ovs-vswitchd(8) and ovsdb-server(1)." Bài 1 đã nhắc tới NB DB, SB DB, và ovn-controller — nhưng ovn-northd chưa từng xuất hiện. Đây không phải một chi tiết phụ có thể bỏ qua: nó là mắt xích duy nhất nối hai database lại với nhau.

Vai trò của nó được mô tả rất rõ ràng: "ovn-northd(8) connects to the OVN Northbound Database above it and the OVN Southbound Database below it. It translates the logical network configuration in terms of conventional network concepts, taken from the OVN Northbound Database, into logical datapath flows in the OVN Southbound Database below it."

💡 Hình dung như thế này: NB DB giống bản vẽ kiến trúc một tòa nhà — ghi "phòng A nối với hành lang B", dễ đọc với kiến trúc sư (CMS) nhưng thợ điện không thi công trực tiếp từ đó được. ovn-northd giống kỹ sư MEP dịch bản vẽ kiến trúc đó thành sơ đồ đi dây điện chi tiết — vẫn chưa phải điện thật chạy trong tường, nhưng đã đủ cụ thể để thợ điện (mỗi ovn-controller trên từng hypervisor) tự thi công phần của mình mà không cần hỏi lại kiến trúc sư.

Vì sao không để ovn-controller đọc thẳng NB DB? Ba lý do rút ra trực tiếp từ đúng vai trò trên: (1) NB DB dùng ngôn ngữ của CMS (logical switch, ACL...), còn thứ mỗi hypervisor cần là flow rule cụ thể — cần một bước dịch; (2) nếu để hàng trăm ovn-controller cùng tính toán lại y hệt phép dịch đó, vừa lãng phí CPU vừa dễ lệch kết quả giữa các hypervisor; (3) SB DB đóng vai trò một "cache đã biên dịch sẵn" dùng chung — mỗi ovn-controller chỉ cần đọc đúng phần dữ liệu logic liên quan tới các port đang chạy trên chassis của mình, không cần hiểu lại toàn bộ cấu hình logic của cả hệ thống.

2. Toàn cảnh kiến trúc OVN: NB DB tới OpenFlow​

Một thuật ngữ sẽ xuất hiện liên tục từ đây: chassis. Tài liệu chính thức định nghĩa gọn: "Hypervisors and gateways are together called transport node or chassis." — nói cách khác, "chassis" chỉ là tên gọi chung cho bất kỳ máy vật lý nào đang chạy ovn-controller, bất kể đó là một hypervisor chứa VM hay một gateway nối ra mạng vật lý; dùng "chassis" thay vì "hypervisor" vì không phải node nào cũng chứa VM.

Sơ đồ dưới đây dựng lại đúng cấu trúc chính thức trong ovn-architecture(7), kèm chi tiết ba bảng trong SB DB mà tài liệu mô tả: "The OVN Southbound Database contains three kinds of data: Physical Network (PN) tables that specify how to reach hypervisor and other nodes, Logical Network (LN) tables that describe the logical network in terms of 'logical datapath flows,' and Binding tables that link logical network components' locations to the physical network. The hypervisors populate the PN and Port_Binding tables, whereas ovn-northd(8) populates the LN tables."

Toàn Cảnh Kiến Trúc OVNCấu hình chảy Bắc→Nam (CMS→chassis) — trạng thái chảy Nam→Bắc (chassis→CMS)CMS (vd OpenStack Neutron)OVN/CMS PluginOVN Northbound DB (NB DB)ovn-northd (Mục 1)OVN Southbound DB (SB DB) — trung tâm hệ thốngPN tables + Logical_Flow (LN) + Port_BindingChassis A (hypervisor)ovn-controllerovs-vswitchd(OpenFlow thật)ovsdb-server(local OVSDB)br-int — integration bridgeChassis B (hypervisor)ovn-controllerovs-vswitchd(OpenFlow thật)ovsdb-server(local OVSDB)br-int — integration bridgeGeneve tunnel(data plane, Mục 5)NB DB/SB DB chỉ mang thông tin điều khiển — packet thật KHÔNG đi qua databaseMỗi ovn-controller chỉ cần biết logical flow liên quan tới port trên chassis của nó

Ba điểm quan trọng nhất rút ra từ sơ đồ trên, dễ hiểu nhầm nếu chỉ đọc lướt:

  1. Packet thật không bao giờ đi qua NB DB/SB DB. Hai database chỉ mang thông tin điều khiển (logical switch nào có port nào, port nào đang chạy trên chassis nào). Traffic thật giữa hai VM trên hai chassis khác nhau đi thẳng qua tunnel Geneve giữa hai ovs-vswitchd, không hề chạm tới OVSDB.
  2. ovn-controller không đọc NB DB. Nó chỉ nói chuyện với SB DB (phía bắc) và với ovs-vswitchd/ovsdb-server cục bộ (phía nam) — đúng như mô tả: "Northbound, it connects to the OVN Southbound Database to learn about OVN configuration and status... Southbound, it connects to ovs-vswitchd(8) as an OpenFlow controller." NB DB là "vùng cấm" đối với mọi ovn-controller.
  3. Trạng thái chảy ngược từ nam lên bắc. Khi một VM thật sự khởi động trên một chassis, ovn-controller cập nhật cột chassis trong bảng Binding (SB DB) — rồi ovn-northd phát hiện thay đổi đó và cập nhật ngược lên cột up trong NB DB, để CMS biết networking của VM đã sẵn sàng. Đây chính xác là cơ chế nhiều CMS (kể cả OpenStack) dùng để quyết định "khi nào được phép chạy VM".

3. Logical switch và logical switch port​

Định nghĩa chính thức: "Logical network concepts in OVN include logical switches and logical routers, the logical version of Ethernet switches and IP routers, respectively... they are not associated or bound to any physical location, and they are implemented in a distributed manner at each hypervisor that participates in OVN." Điểm mấu chốt nằm ở cụm "implemented in a distributed manner" — một logical switch không tồn tại ở một nơi cụ thể nào cả; nó được mô phỏng lại y hệt trên mọi hypervisor có port thuộc về nó, mỗi nơi tính toán qua flow OpenFlow riêng: "When a VM sends a packet to a VIF logical switch port, the Open vSwitch flow tables simulate the packet's journey through that logical switch... This happens without transmitting the packet across any physical medium... If the flow tables ultimately decide to output the packet at a logical port attached to another hypervisor, then that is the time at which the packet is encapsulated for physical network transmission and sent."

Loại logical switch port phổ biến nhất gắn vào một VIF — tài liệu định nghĩa cụ thể: "A VIF on a hypervisor is a virtual network interface attached either to a VM or a container running directly on that hypervisor." Nói đơn giản: VIF chính là card mạng ảo của một VM/container, đúng thứ mà external_ids:iface-id ở Mục 6 sẽ gắn vào.

Logical switch port (LSP) có nhiều loại, không chỉ mỗi loại gắn VM:

Loại LSPÝ nghĩa
VIF (mặc định, type rỗng)Cổng gắn trực tiếp một VM/container — loại phổ biến nhất.
routerNối logical switch sang một logical router port cụ thể (Mục 4).
localnetBridge logical switch ra một VLAN vật lý — dùng cho gateway hoặc gắn VM thẳng ra mạng vật lý.
localportTồn tại trên mọi chassis cùng lúc, không tunnel — OpenStack dùng loại này để phục vụ metadata cho VM.
vtep, l2gatewayDùng cho gateway nối vào ToR switch vật lý hỗ trợ VTEP schema (đã nhắc ở Bài 9).

Toàn bộ vòng đời một VIF — từ lúc CMS tạo tới lúc port lên up — được tài liệu mô tả chi tiết từng bước; rút gọn lại thành đúng chuỗi nhân-quả cần nhớ: CMS ghi vào Logical_Switch_Port (NB DB) → ovn-northd thấy thay đổi, thêm dòng vào Logical_Flow (SB DB, "add a flow to recognize that packets destined to the new port's MAC address should be delivered to it") và tạo một dòng Binding còn trống cột chassis → khi VM thật sự chạy, ovn-controller trên đúng hypervisor đó phát hiện external_ids:iface-id trên interface mới, tự điền cột chassis trong Binding → ovn-northd thấy cột chassis hết rỗng, cập nhật ngược cột up trong NB DB để báo CMS. Đây chính là chuỗi sự kiện đứng sau nguyên tắc "trạng thái chảy nam→bắc" đã nêu ở Mục 2.

4. Logical router và logical patch port: nối hai mạng logic​

Logical router port (LRP) là điểm nối vào/ra một logical router — và có một ràng buộc quan trọng cần nhớ: "A LRP connects a logical router either to a logical switch or to another logical router. Logical routers only connect to VMs, containers, and other network nodes indirectly, through logical switches." Nói cách khác: logical router không bao giờ gắn thẳng VM — muốn một VM đi qua router, VM đó phải nằm trên một logical switch, rồi switch đó nối sang router qua đúng một cặp port đặc biệt.

Cặp port đó gọi là logical patch port: "These port bindings always occur in pairs, and a packet that enters on either side comes out on the other. ovn-northd connects logical switches and logical routers together using logical patch ports." Về phía logical switch, port này có type=router; về phía logical router, đó chính là một LRP bình thường — hai bên trỏ vào nhau qua tùy chọn router-port.

Logical Switch — Logical Patch Port — Logical RouterTopology logic không quan tâm sw0-port1 và sw1-port1 đang chạy trên chassis nàoLogical Switch sw0192.168.0.0/24sw0-port1 (VIF)patchLogical Router lr0lrp0.0.1/24lrp1.0.1/24LRP chỉ nối switch hoặc router khác — không gắn thẳng VMpatchLogical Switch sw111.0.0.0/24sw1-port1 (VIF)sw0-port1 thật sự chạytrên Chassis Asw1-port1 thật sự chạytrên Chassis BTopology (trên) hoàn toàn tách biệt vị trí vật lý (dưới) — SB DB tự tìm chassis, Geneve tự dựng tunnel

Cú pháp thật, đúng theo ovn-nbctl(8) và ví dụ chính thức trong tutorial OVN sandbox — dựng lại đúng topology trong sơ đồ trên:

# Hai logical switch, mỗi cái một port VIF
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"

ovn-nbctl ls-add sw1
ovn-nbctl lsp-add sw1 sw1-port1
ovn-nbctl lsp-set-addresses sw1-port1 "50:54:00:00:00:03 11.0.0.2"

# Logical router với 2 LRP, mỗi LRP là gateway của đúng 1 subnet
ovn-nbctl lr-add lr0
ovn-nbctl lrp-add lr0 lrp0 00:00:00:00:ff:01 192.168.0.1/24
ovn-nbctl lrp-add lr0 lrp1 00:00:00:00:ff:02 11.0.0.1/24

# Cặp logical patch port nối switch <-> router — dùng shortcut lsp-add-router-port
ovn-nbctl lsp-add-router-port sw0 sw0-lr0 lrp0
ovn-nbctl lsp-add-router-port sw1 sw1-lr0 lrp1

Lệnh lsp-add-router-port chính là đường tắt cho đúng ba bước lsp-add + lsp-set-type router + lsp-set-options router-port=... gộp lại: "Creates a new logical switch port named port on switch with type router, sets the router-port option to lrp_peer, and sets addresses to router." — dùng shortcut này thay vì gõ tay ba lệnh, ít khả năng gõ sai router-port hơn.

5. Từ Geneve tới OpenFlow: tunnel key trở thành field nào​

Bài 9 Mục 4 đã trả lời "vì sao OVN chọn Geneve" bằng con số cụ thể: ba mẩu metadata OVN cần mang qua mạng vật lý — 24-bit logical datapath, 15-bit logical ingress port, 16-bit logical egress port — cộng lại 55 bit, vượt quá khả năng của VXLAN (24-bit) hay GRE (32-bit), chỉ Geneve có TLV mở rộng đủ chỗ chứa. Điều Bài 9 chưa nói tới — vì lúc đó chưa học OVN — là ba mẩu metadata đó đi về đâu khi tới nơi. Câu trả lời nằm trong ovn-architecture(7):

Metadata trong tunnel keyKhi vào tới OVS, lưu ở đâu
Logical datapath (24-bit)Field OpenFlow gọi là ``metadata'' — "OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls 'metadata' to store the logical datapath."
Logical ingress port (15-bit)"OVN stores this in Open vSwitch extension register number 14."
Logical egress port (16-bit)"OVN stores this in Open vSwitch extension register number 15." Trường này khởi tạo bằng 0 lúc gói mới vào logical pipeline, chỉ có giá trị sau khi flow logic quyết định port ra.

Đây chính là lý do khi Mục 6 chạy ovs-ofctl dump-flows trên một bridge br-int thật, bạn sẽ thấy metadata=0x... và reg14/reg15 xuất hiện dày đặc trong match/action — chúng không phải field bí ẩn, mà đúng là ba mẩu metadata Geneve mang qua tunnel, được OVN "giải mã" thành field OpenFlow ngay khi gói tới br-int.

Toàn bộ quá trình packet đi qua kể từ khi vào bridge được tóm gọn đúng hai bước đầu: "OpenFlow table 0 performs physical-to-logical translation. It matches the packet's ingress port. Its actions annotate the packet with logical metadata... Then it resubmits to table 8 to enter the logical ingress pipeline." — table 0 là nơi packet vật lý được "dịch" thành packet logic (gán metadata + reg14), sau đó mọi bảng từ table 8 trở đi mới thật sự mô phỏng hành vi logical switch/router.

6. CLI lab: dựng logical switch thật và verify bằng ovn-trace​

Trước khi tạo logical switch, một hypervisor cần "đăng ký" với OVN — bốn khóa cấu hình trong Open_vSwitch local mà ovn-controller đọc để biết nó là ai và nói chuyện với SB DB nào:

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"

external_ids:ovn-bridge mặc định là br-int — nếu bridge này chưa tồn tại, ovn-controller tự tạo khi khởi động: "The integration bridge to which logical ports are attached. The default is br-int. If this bridge does not exist when ovn-controller starts, it will be created automatically." Đây chính là lý do lab OVN không cần tự tay ovs-vsctl add-br như mọi lab OVS thuần túy từ Bài 4 tới giờ.

Năm Bước Walkthrough — Từ ovn-nbctl Tới OpenFlow ThậtBước 1-2 ghi NB DB — Bước 3-5 verify kết quả đã lan xuống tận OpenFlowBước 1ls-add + lsp-add +lsp-set-addressesBước 2Gắn port vào br-int,set external_ids:iface-idBước 3ovn-nbctl show —xác nhận port lên "up"Bước 4ovn-trace — verifylogic pipeline đúng ýBước 5ovs-ofctl dump-flows —khớp cookie ↔ logical flow

Bước 1 — tạo logical switch và port (đúng cú pháp đã dùng ở Mục 4):

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"

Bước 2 — mô phỏng một VM: gắn 1 cổng veth/internal port vào br-int, đúng khớp vif-id đã dùng khi tạo LSP (đây là bước mà trên hypervisor thật do phần tích hợp libvirt/Neutron làm tự động — xem lại Bài 7):

sudo ovs-vsctl add-port br-int vm1-port -- set Interface vm1-port type=internal
sudo ovs-vsctl set Interface vm1-port external_ids:iface-id=sw0-port1

Bước 3 — xác nhận port đã lên up:

ovn-nbctl show sw0
# Output minh họa — cấu trúc đúng theo ovn-nbctl show thật
switch 3f8a2b1c (sw0)
    port sw0-port1
        addresses: ["50:54:00:00:00:01 192.168.0.2"]

(Output minh họa — UUID và cấu trúc đúng theo ovn-nbctl show thật, giá trị cụ thể chỉ mang tính ví dụ.)

Bước 4 — verify logic bằng ovn-trace, không cần gửi packet thật. Đây là cách chính thức để trả lời câu hỏi "nếu tôi gửi đúng packet này, OVN sẽ làm gì" mà không cần dựng VM thứ hai trước:

ovn-trace --summary sw0 \
  'inport == "sw0-port1" && eth.src == 50:54:00:00:00:01 && ip4.src == 192.168.0.2 && eth.dst == ff:ff:ff:ff:ff:ff'
# Output minh họa — đúng cấu trúc summary output theo ovn-trace(8)
ingress(dp="sw0", inport="sw0-port1") {
    outport = "_MC_flood";
    output;
};

(Output minh họa — cấu trúc đúng theo ovn-trace(8), tên cổng multicast nội bộ _MC_flood là quy ước có thật của OVN cho broadcast/flood.)

Bước 5 — khớp trực tiếp một OpenFlow flow thật với đúng logical flow đã sinh ra nó. Đây là kỹ thuật ít người biết nhưng được ghi rõ trong ovn-sbctl(8): "ovn-controller sets OpenFlow flow cookies to the first 32 bits of the corresponding logical flow's UUID, this makes it easy to look up the logical flow that generated a particular OpenFlow flow."

sudo ovs-ofctl dump-flows br-int | grep "cookie=0x"
# Output minh họa — rút gọn, cookie chỉ mang tính ví dụ
 cookie=0x3f8a2b1c, table=19, priority=50,dl_dst=50:54:00:00:00:01 actions=load:0x1->NXM_NX_REG15[],resubmit(,32)
# Lấy đúng 32-bit đầu của cookie, tra lại logical flow tương ứng trong SB DB
ovn-sbctl lflow-list 3f8a2b1c

(Output minh họa — giá trị cookie thật sẽ khác, nhưng nguyên lý khớp 32-bit đầu với UUID logical flow luôn đúng theo tài liệu chính thức.)

Nếu ovs-ofctl dump-flows không cho ra flow nào khớp cổng vừa tạo, thứ tự debug đúng là: ovn-nbctl show (NB DB đã ghi đúng chưa) → ovn-sbctl show/lflow-list (đã biên dịch xuống SB DB chưa) → ovs-vsctl show trên chassis (port đã gắn iface-id đúng chưa) → ovs-ofctl dump-flows (đã lan tới OpenFlow chưa) — đúng thứ tự bốn tầng trong sơ đồ Mục 2, đi từ bắc xuống nam.

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

  1. Dựng lại đúng topology ở Mục 4 (2 logical switch nối qua 1 logical router) trên máy lab của bạn bằng các lệnh ls-add/lr-add/lrp-add/lsp-add-router-port đã học. Sau đó gắn sw0-port1 và sw1-port1 vào cùng một br-int (mô phỏng 2 VM trên cùng 1 chassis để đơn giản hóa lab, không cần 2 hypervisor thật). Verify bằng ovn-trace với một packet có ip4.dst thuộc subnet của switch còn lại (ví dụ gửi từ sw0-port1 tới 11.0.0.2) — logic router có đúng quyết định route sang sw1 không?
  2. Dùng đúng kỹ thuật khớp cookie ở Mục 6 Bước 5: chạy ovs-ofctl dump-flows br-int, chọn một dòng bất kỳ có cookie=0x... khác 0, rồi chạy ovn-sbctl lflow-list <8-ký-tự-đầu-cookie> để tìm đúng logical flow đã sinh ra nó. Đọc output lflow-list, xác định logical flow đó thuộc bảng logic nào (ví dụ ls_in_l2_lkup) và match/action là gì.
  3. Đọc lại bảng ở Mục 5 (logical datapath → field metadata, logical ingress port → reg14, logical egress port → reg15). Nếu một hôm bạn thấy hai VM trên hai logical switch khác nhau nhưng lại nhận được packet của nhau dù không có logical router nối giữa, hãy suy luận: khả năng cao nhất field nào trong ba field trên đã bị cấu hình trùng giữa hai logical switch, và vì sao trùng field đó gây ra đúng triệu chứng "lẫn lộn giữa hai mạng logic".

Nguồn tham khảo​

  • Thành phần kiến trúc OVN (CMS, OVN/CMS Plugin, NB DB, ovn-northd, SB DB, ovn-controller, ovs-vswitchd/ovsdb-server), sơ đồ ASCII gốc, ba loại bảng trong SB DB (PN/LN/Binding), cơ chế nb_cfg/sb_cfg báo trạng thái nam→bắc, toàn bộ 15 bước vòng đời một VIF (Logical_Switch_Port → Logical_Flow/Binding → cột chassis → cột up), định nghĩa VIF ("A VIF on a hypervisor is a virtual network interface attached either to a VM or a container..."), định nghĩa "chassis" ("Hypervisors and gateways are together called transport node or chassis"), định nghĩa logical switch/router/LSP/LRP, các loại LSP (VIF/router/localnet/localport/vtep/l2gateway), logical patch port, quy ước metadata trong tunnel key (field metadata, register 14, register 15), bước physical-to-logical ở OpenFlow table 0 → table 8 — ovn-architecture(7), ovn.org.
  • Cổng TCP mặc định của NB DB (6641) và SB DB (6642) ("tcp:x.x.x.x:6641", "tcp:x.x.x.x:6642", --ovnnb-db/--ovnsb-db) — ovn-ctl(8), ovn.org.
  • Cú pháp ls-add, lsp-add, lsp-set-addresses, lsp-add-router-port, lr-add, lrp-add (kèm ví dụ lrp-add lr0 lrp0 00:11:22:33:44:55 192.168.0.1/24 2001:db8::1/64 peer=lr1) — ovn-nbctl(8), ovn.org.
  • Ví dụ dựng 2 logical switch nối qua 1 logical router bằng ovn-nbctl (lệnh ls-add, lsp-add, lsp-set-addresses, lr-add, lrp-add, lsp-set-type, lsp-set-options router-port=), và cú pháp ovn-trace --minimal — OVN sandbox tutorial, docs.ovn.org.
  • Cấu hình ovn-controller qua external_ids (system-id, ovn-remote, ovn-encap-type, ovn-encap-ip, ovn-bridge mặc định br-int và tự tạo nếu chưa có), hai loại tunnel hỗ trợ (geneve, vxlan) và giới hạn hiệu năng/tính năng khi dùng vxlan — ovn-controller(8), ovn.org.
  • Lệnh ovn-sbctl lflow-list, cơ chế cookie OpenFlow = 32-bit đầu UUID logical flow ("ovn-controller sets OpenFlow flow cookies to the first 32 bits of the corresponding logical flow's UUID") — ovn-sbctl(8), ovn.org.
  • Cú pháp ovn-trace, ba định dạng output (detailed/summary/minimal) kèm ví dụ thật (ingress(dp="ls1", inport="lp111")...) — ovn-trace(8), ovn.org.
  • 55-bit metadata (24+15+16) và lý do OVN chọn Geneve thay vì VXLAN/GRE đã học ở Bài 9; VTEP schema cho gateway phần cứng cũng đã nhắc ở Bài 9; libvirt/tích hợp VM-OVS đã học ở Bài 7; pipeline nhiều bảng OpenFlow và ovs-ofctl dump-flows đã học ở Bài 6/Bài 12; kiến trúc OVN sơ lược ban đầu ở Bài 1 Mục 3.

Tiếp theo: Module 4, Bài 18 — OVS trong OpenStack Neutron.