Skip to main content

OVS Phần 16: Giám Sát — sFlow, IPFIX và Port Mirroring

Phần 16/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 15, nơi câu đúc kết cuối bài đã cảnh báo: bật hardware offload khiến số liệu n_bytes không còn đáng tin tuyệt đối vì TC đếm thiếu phần header L2. Bài 16 mở sang một câu hỏi rộng hơn: ngoài đếm byte trên từng flow, làm sao thật sự quan sát traffic đang chạy qua OVS — sao chép nguyên vẹn để bắt gói, lấy mẫu thống kê để nhìn xu hướng, hay xuất thành flow record để phân tích/billing? Đây là bài cuối của Module 3 — Nâng cao. Sau bài này, Bài 17 mở đầu Module 4 — Chuyên gia/SDN tích hợp, đi sâu vào OVN.

Mục tiêu bài học: sau bài này bạn phân biệt được ba cơ chế giám sát traffic hoàn toàn khác bản chất trên OVS — port mirroring (sao chép nguyên vẹn gói tin), sFlow (lấy mẫu thống kê ngẫu nhiên), và IPFIX (xuất flow record, có thể theo sampling toàn bridge hoặc theo đúng flow rule cụ thể) — biết cấu hình thật từng loại qua OVSDB, và verify bằng công cụ thật (tcpdump cho mirror, sflowtool cho sFlow).

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

  1. Port mirroring, sFlow, và IPFIX khác nhau ở cơ chế nền tảng nào (full copy / sample / flow record), và đánh đổi băng thông — CPU ra sao?
  2. Cấu hình thật qua ovs-vsctl cho từng cơ chế là gì, nằm ở bảng OVSDB nào?
  3. IPFIX trên OVS có thật sự xuất "mọi" flow như nhiều người mặc định, hay bản chất vẫn dựa trên sampling — và per-bridge sampling khác gì flow-based sampling?

Mục lục​

1. Ba cơ chế giám sát: liên hệ với switch vật lý bạn đã quen​

Ba khái niệm dưới đây không xa lạ — bạn gần như chắc chắn đã cấu hình ít nhất một trong số chúng trên switch vật lý (Cisco, Juniper, Arista...): SPAN/RSPAN (port mirroring), NetFlow/IPFIX (xuất flow record), và sFlow (lấy mẫu). OVS hỗ trợ cả bốn bảng cấu hình tương ứng trong OVSDB — Mirror, NetFlow, sFlow, IPFIX — và một bridge có thể bật đồng thời nhiều cơ chế cùng lúc, mỗi cơ chế phục vụ một mục đích khác hẳn nhau về bản chất, không phải chỉ khác tên gọi.

💡 Hình dung như thế này: một bưu cục xử lý hàng vạn lá thư mỗi ngày và muốn giám sát theo ba cách khác nhau. Cách thứ nhất — photocopy nguyên văn mọi lá thư gửi qua một địa chỉ cụ thể, giữ lại bản sao đầy đủ để đọc sau (đây là mirror: sao chép nguyên vẹn, tốn giấy/băng thông tỷ lệ thuận với traffic thật, chỉ áp cho traffic đã chọn). Cách thứ hai — cứ trung bình 400 lá thư thì bóc ra đọc ngẫu nhiên 1 lá để nắm xu hướng chung (đây là sFlow: lấy mẫu thống kê, chi phí gần như không đổi dù traffic tăng gấp 10 lần, nhưng không đảm bảo bắt được lá thư cụ thể nào). Cách thứ ba — không đọc nội dung thư, chỉ ghi lại một thẻ tóm tắt cho mỗi luồng thư (ai gửi, ai nhận, bao nhiêu lá, kéo dài bao lâu) rồi gửi thẻ đó về phòng thống kê (đây là IPFIX/NetFlow: xuất flow record, nhẹ hơn photocopy nhưng vẫn giữ được thông tin luồng, phục vụ billing/capacity planning).

Ba Cơ Chế Giám Sát: Cái Gì Thật Sự Được Gửi Đi CollectorCùng traffic gốc — ba cơ chế trích xuất ba loại dữ liệu hoàn toàn khác nhauPort MirroringsFlowIPFIX100% traffic quaport/VLAN đã chọn(select_src/dst_port)1/400 gói (mặc định)+ counter mỗi 30s(sampling, polling)Sample rồi trích thôngtin flow, có thể cachegộp trước khi gửiGửi đi: nguyên payloadgốc — chi phí băngthông = traffic thậtGửi đi: 128 byte đầugói mẫu — chi phí gầnnhư hằng sốGửi đi: flow record —không có payload,chỉ metadata luồngKhông cơ chế nào "tốt nhất" — chọn theo câu hỏi cần trả lời (Mục 5), không theo mặc định quen tayIPFIX vẫn dựa trên sampling như sFlow — khác ở chỗ trích flow record thay vì gói thô (Mục 4)

Sự khác biệt cốt lõi nằm ở cái gì được gửi đi: mirror gửi nguyên gói tin, sFlow gửi một mẫu gói tin đã cắt ngắn kèm số liệu, còn IPFIX/NetFlow gửi bản ghi tóm tắt về một flow (không phải payload gốc). Ba mục tiếp theo đi vào từng cơ chế theo đúng thứ tự chi phí tăng dần về độ chi tiết — và giảm dần về khả năng mở rộng ở traffic cao.

2. Port mirroring: sao chép nguyên vẹn, SPAN và RSPAN​

Tài liệu chính thức định nghĩa đúng cơ chế: "A port mirror configures a bridge to send selected frames to special 'mirrored' ports, in addition to their normal destinations. Mirroring traffic may also be referred to as SPAN or RSPAN, depending on how the mirrored traffic is sent." Bảng Mirror trong OVSDB có ba nhóm cột đáng chú ý:

Chọn gói tin nào bị mirror — bốn cách kết hợp được, đều được AND với nhau:

  • select_src_port / select_dst_port: tập port mà gói tin đi vào (nguồn) hoặc đi ra (đích) sẽ bị chọn.
  • select_vlan: giới hạn theo VLAN — "An empty set selects packets on all VLANs."
  • select_all: chọn toàn bộ, bỏ qua các điều kiện port/VLAN ở trên.
  • filter: lọc thêm theo cú pháp ovs-fields(7), áp dụng sau cùng, sau khi đã qua select_all/select_dst_port/select_src_port/select_vlan.

Đích đến của bản sao — hai cột này loại trừ nhau, đúng một trong hai phải khác rỗng:

  • output_port: gửi bản sao ra đúng một port vật lý/logic (SPAN cổ điển). Tài liệu nhấn mạnh port này bị chiếm dụng hoàn toàn: "Specifying a port for mirror output reserves that port exclusively for mirroring. No frames other than those selected for mirroring via this column will be forwarded to the port, and any frames received on the port will be discarded."
  • output_vlan: gửi bản sao ra một VLAN thay vì một port cụ thể — đây là RSPAN (Remote SPAN), cho phép traffic mirror đi xa qua trunk tới một thiết bị giám sát ở nơi khác trong mạng.
SPAN (output_port) So Với RSPAN (output_vlan)SPAN — output_portRSPAN — output_vlanBridge br0Port p1 (nguồn)Port p3(output_port)Thiết bị giám sát(gắn trực tiếp vào p3)Không qua thiết bị trung giannào — không rủi ro học nhầm MACBridge br0Port p1 (nguồn)Trunk port(output_vlan=100)Switch trung gian(phải quản lý được — xem cảnh báo)Thiết bị giám sát (ở xa)output_port và output_vlan loại trừ nhau — chỉ đúng một cột được khác rỗng trên mỗi Mirror record

⚠️ Tài liệu cảnh báo rất cụ thể về rủi ro của output_vlan: mirror vào VLAN có thể làm switch vật lý không quản lý (unmanaged) trong đường đi học nhầm địa chỉ MAC — gói tin mirror phản hồi ngược lại đúng port đã học trước đó, khiến switch ghi đè entry MAC learning đúng thành sai, làm gián đoạn kết nối thật của host gốc. Nếu dùng RSPAN qua VLAN, hạ tầng trung gian phải là switch quản lý được, biết cách tách port mirror ra khỏi luồng học MAC bình thường.

Một chi tiết dễ bị bỏ qua về thời điểm mirror bắt gói trong pipeline — hành vi này từng đổi giữa các bản OVS: "In Open vSwitch 2.5 and later, mirroring occurs just after a packet first becomes eligible... In Open vSwitch 2.4 and earlier, mirroring occurs only after a packet has traversed all the flow tables, using the original packet as it entered the bridge." Nói cách khác: trên bản OVS hiện hành, nếu flow rule sửa gói tin (ví dụ chỉnh VLAN tag, NAT) trước khi output, bản mirror thấy đúng gói tin đã bị sửa đó — không còn là bản nguyên gốc lúc vào bridge như hành vi cũ trước OVS 2.5.

Cấu hình thật — ví dụ chính thức mirror toàn bộ traffic vào/ra eth0 và eth1 sang eth2 (SPAN, dùng output_port):

ovs-vsctl -- set Bridge br0 mirrors=@m \
  -- --id=@eth0 get Port eth0 \
  -- --id=@eth1 get Port eth1 \
  -- --id=@eth2 get Port eth2 \
  -- --id=@m create Mirror name=mymirror \
     select-dst-port=@eth0,@eth1 select-src-port=@eth0,@eth1 output-port=@eth2

Chú ý cú pháp select-dst-port (dấu gạch ngang) trong khi tên cột thật trong schema là select_dst_port (dấu gạch dưới) — đây không phải lỗi đánh máy trong tài liệu, mà là hành vi chính thức của ovs-vsctl: "Names of tables and columns are not case-sensitive, and - and _ are treated interchangeably." Xóa mirror (destroy luôn record vì không còn ai tham chiếu):

ovs-vsctl clear Bridge br0 mirrors

3. sFlow: lấy mẫu thống kê, không phải bắt trọn từng gói​

sFlow được chính dự án sFlow.org mô tả đúng bản chất: "sFlow is a sampling technology", và ưu điểm cốt lõi nằm ở khả năng mở rộng: "sFlow is scalable, enabling it to monitor links of speeds up to 10Gb/s and beyond without impacting the performance of core internet routers and switches." Khác hẳn mirror — sFlow không gửi nguyên gói tin, mà gửi một tỷ lệ mẫu đã cắt ngắn kèm số liệu thống kê, nên chi phí gần như không đổi bất kể traffic tăng bao nhiêu lần.

Bảng sFlow trong OVSDB thực chất kết hợp hai cơ chế độc lập chạy song song — điểm dễ gộp nhầm thành một:

CộtÝ nghĩa (trích nguyên văn ovs-vswitchd.conf.db(5))
sampling"Rate at which packets should be sampled and sent to the collector. If not specified, defaults to 400, which means one out of 400 packets, on average, will be sent to the collector." — đây là lấy mẫu gói tin ngẫu nhiên.
polling"Polling rate in seconds to send port statistics to the collector. If not specified, defaults to 30 seconds." — đây là đếm counter theo chu kỳ, hoàn toàn tách biệt với việc lấy mẫu gói tin ở trên.
header"Number of bytes of a sampled packet to send to the collector. If not specified, the default is 128 bytes." — chỉ gửi 128 byte đầu của gói mẫu, không phải toàn bộ gói.
agentĐịa chỉ IP báo cáo cho collector là nguồn dữ liệu sFlow — có thể chỉ định trực tiếp hoặc để OVS tự suy ra: "If not specified, the agent device is figured from the first target address and the routing table... If an agent IP address cannot be determined, sFlow is disabled."
targetssFlow collector, dạng ip:port.

Nói cách khác: một collector sFlow nhận được hai luồng dữ liệu khác bản chất từ cùng một bridge — luồng mẫu gói tin (tần suất phụ thuộc traffic, theo sampling) và luồng thống kê port counter (tần suất cố định mỗi 30 giây theo polling, không phụ thuộc traffic nhiều hay ít).

Cấu hình thật — ví dụ chính thức trỏ về collector 10.0.0.1:6343, dùng địa chỉ IP của eth1 làm agent:

ovs-vsctl -- --id=@s create sFlow agent=eth1 targets=\"10.0.0.1:6343\" \
    header=128 sampling=64 polling=10 \
  -- set Bridge br0 sflow=@s

Ví dụ chính thức trong ovs-vsctl(8) dùng target= (số ít) thay vì targets= — cột thật trong schema hiện hành là targets (số nhiều, "set of 1 or more strings"), và target= chạy được là nhờ đúng quy tắc "unique abbreviation" đã nhắc ở Mục 2 (target là tiền tố duy nhất khớp cột targets). Dùng targets= đầy đủ để chắc chắn không phụ thuộc cách viết tắt này ở mọi bản OVS.

4. IPFIX: xuất flow record, và sự thật về sampling​

IPFIX (IP Flow Information Export) là chuẩn IETF, định nghĩa trong RFC 7011: "This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network." Về mặt lịch sử, IPFIX kế thừa trực tiếp định dạng của Cisco NetFlow version 9 — bản thân RFC ghi rõ số hiệu version trong header IPFIX là "incrementing by one the version used in the NetFlow services export version 9". Điểm khác cốt lõi giữa hai bản là khái niệm template: thay vì mỗi bản ghi flow phải theo đúng một bộ field cố định (5-tuple: source/destination IP, port, protocol — như NetFlow v5 kiểu cũ), NetFlow v9/IPFIX gửi kèm định kỳ một template record mô tả trước "bản ghi flow sắp tới sẽ có những field nào, theo thứ tự nào" — nhờ vậy có thể thêm field tùy ý (ví dụ 7-tuple tunnel metadata sẽ nhắc ở dưới) mà không cần đổi hẳn giao thức. OVS vẫn giữ riêng một bảng NetFlow (kiểu cũ, cấu trúc field cố định, không có template) song song với IPFIX cho ai cần tương thích ngược với collector NetFlow v5-style.

Đây là điểm dễ hiểu lầm nhất trong cả bài: nhiều người mặc định NetFlow/IPFIX "xuất mọi flow, chính xác tuyệt đối" khác hẳn sFlow "chỉ lấy mẫu". Nhưng chính tài liệu OVS ghi rõ ngay trong định nghĩa bảng IPFIX: "The IPFIX implementation in Open vSwitch samples packets at a configurable rate, extracts flow information from those packets, optionally caches and aggregates the flow information, and sends the result to one or more collectors." — IPFIX trên OVS vẫn lấy mẫu, chỉ là đơn vị mẫu là "trích thông tin flow" thay vì "gửi nguyên gói cắt ngắn" như sFlow.

IPFIX trên OVS cấu hình được theo hai cách khác hẳn nhau, và đây là chi tiết hay bị gộp lẫn nhất:

  • Per-bridge sampling: OVS tự động sample mọi gói qua bridge, không cần đụng tới OpenFlow flow table. Chỉ cần tạo record IPFIX rồi trỏ cột ipfix của Bridge vào đó. Bảng Flow_Sample_Collector_Set không dùng trong cách này.
  • Flow-based sampling: việc sample do chính action sample trong OpenFlow flow table quyết định (Bài 6, Bài 12 đã học add-flow/action) — chỉ những gói khớp đúng flow rule có action sample mới bị xuất, không phải toàn bộ traffic qua bridge. Cách này cần thêm bảng Flow_Sample_Collector_Set trỏ tới đúng bridge và đúng record IPFIX; cột ipfix của Bridge không dùng trong cách này.

Vài cột đáng chú ý khác của bảng IPFIX:

CộtÝ nghĩa
cache_active_timeout, cache_max_flowsGộp nhiều gói cùng flow thành ít bản ghi hơn trước khi gửi — "If 0, caching is disabled" (mặc định 0, tức mỗi gói mẫu tạo một bản ghi riêng nếu không bật cache).
sampling (per-bridge)Giống hệt ý nghĩa sampling của sFlow — mặc định 400, một trong 400 gói được lấy mẫu.
obs_domain_id, obs_point_idĐịnh danh domain/điểm quan sát gửi kèm mỗi gói IPFIX — hữu ích khi một collector nhận dữ liệu từ nhiều bridge/host.
other_config:enable-tunnel-samplingBật mặc định — cho phép IPFIX báo cáo thêm 7-tuple header tunnel (VXLAN/GRE/Geneve — đúng ba loại tunnel đã học ở Bài 9), một khả năng NetFlow kiểu cũ trên OVS không có.

Một lưu ý fact-check nhỏ: chính văn bản ovs-vswitchd.conf.db(5) mô tả stats_interval bằng cách trích "IETF RFC 5101 Section 4.3" — nhưng RFC 5101 đã bị RFC 7011 thay thế từ 2013 (nội dung liên quan tới stats_interval không đổi giữa hai bản, chỉ là số RFC được tài liệu OVS trích đã lỗi thời).

Cấu hình thật — ví dụ chính thức bật per-bridge sampling, gửi flow record về 192.168.0.34:4739, có cache để gộp bớt bản ghi:

ovs-vsctl -- set Bridge br0 ipfix=@i \
  -- --id=@i create IPFIX targets=\"192.168.0.34:4739\" \
     obs_domain_id=123 obs_point_id=456 \
     cache_active_timeout=60 cache_max_flows=13

Cấu hình thật cho flow-based sampling — chỉ xuất IPFIX cho đúng traffic khớp một flow rule cụ thể, không đụng tới phần còn lại của bridge. Trước hết tạo IPFIX record và Flow_Sample_Collector_Set trỏ vào đúng bridge:

ovs-vsctl -- --id=@i create IPFIX targets=\"192.168.0.34:4739\" \
  -- create Flow_Sample_Collector_Set id=1 bridge=br0 ipfix=@i

Sau đó thêm một flow rule dùng action sample — cú pháp chính thức theo ovs-actions(7): "probability=packets — The number of sampled packets out of 65535" và "collector_set_id=id — The unsigned 32-bit integer identifier of the set of sample collectors to send sampled packets to". Ví dụ chỉ sample traffic từ dải 10.0.0.0/24 (đúng tình huống "chỉ giám sát 1 tenant" ở Bài tập 2), lấy mẫu 100% (65535/65535) traffic đã khớp rồi vẫn normal để traffic tiếp tục đi bình thường:

ovs-ofctl add-flow br0 \
  "priority=100,ip,nw_src=10.0.0.0/24,actions=sample(probability=65535,collector_set_id=1),normal"

Chú ý mẫu số của probability trong action sample là 65535, khác hẳn mẫu số của cột sampling ở per-bridge sampling (mặc định 400) — hai cơ chế dùng hai đơn vị đo tỷ lệ khác nhau dù cùng khái niệm "lấy mẫu".

5. Chọn cơ chế nào cho tình huống nào​

Tiêu chíPort mirroringsFlowIPFIX
Dữ liệu gửi điNguyên gói tinMẫu gói (128 byte đầu, mặc định) + counter định kỳBản ghi flow (không có payload)
Chi phí băng thông/CPUTỷ lệ thuận traffic thật — có thể rất lớnGần như hằng số, không phụ thuộc trafficTrung bình, giảm thêm nếu bật cache
Độ chi tiếtTuyệt đối — thấy nguyên payloadƯớc lượng thống kê, không đảm bảo bắt đúng 1 gói cụ thểChính xác theo flow, nhưng không thấy payload
Use case điển hìnhDebug sâu 1 vấn đề cụ thể, đưa traffic vào IDS/IPS full-captureGiám sát tổng thể ở traffic cao, phát hiện anomaly/DDoSBilling, capacity planning, phân tích flow theo tenant

Không có cơ chế nào "tốt nhất" — ba cơ chế trả lời ba câu hỏi khác nhau: mirror trả lời "gói tin này thật sự chứa gì", sFlow trả lời "xu hướng traffic tổng thể đang ra sao", IPFIX trả lời "ai nói chuyện với ai, bao lâu, bao nhiêu dữ liệu". Một hệ thống giám sát trưởng thành thường dùng cả ba: sFlow chạy thường trực trên mọi bridge (chi phí thấp), IPFIX bật cho các tenant cần billing chi tiết, và mirror chỉ bật tạm thời khi đang debug một sự cố cụ thể (vì chiếm dụng hẳn một port và tốn băng thông đúng bằng traffic thật).

6. Walkthrough CLI: bật mirror thật và verify bằng tcpdump​

Khác hẳn DPDK (Bài 14) hay hardware offload (Bài 15) — port mirroring là tính năng thuần software trong OVS, không cần NIC đặc biệt nào. Lab dưới đây chạy được trên bất kỳ bridge OVS nào, kể cả dựng bằng veth/namespace như các bài đầu series.

Năm Bước Walkthrough — Bật Mirror Và Verify Bằng tcpdumpThuần software — chạy được trên veth/namespace, không cần NIC đặc biệtBước 1Xác định port nguồnvà port đích mirrorBước 2create Mirror +set Bridge mirrors=@mBước 3ovs-vsctl show —xác nhận mirror đã tạoBước 4tcpdump trênport/namespace đíchBước 5Gửi ping từ port nguồn,quan sát bản sao xuất hiện

Bước 1-2 — dựng mirror trên bridge lab (giả sử br0 đã có port p1 là nguồn, p2 là đích mirror — dùng lại lab veth kiểu Bài 4):

sudo ovs-vsctl -- set Bridge br0 mirrors=@m \
  -- --id=@p1 get Port p1 \
  -- --id=@p2 get Port p2 \
  -- --id=@m create Mirror name=labmirror \
     select_src_port=@p1 select_dst_port=@p1 output_port=@p2

Bước 3 — xác nhận mirror đã được tạo:

sudo ovs-vsctl show
# Output minh họa — cấu trúc đúng theo ovs-vsctl show thật, tên/UUID chỉ mang tính ví dụ
    Bridge br0
        Port p2
            Interface p2
        Port p1
            Interface p1
        Mirror "labmirror"
            Statistics: {tx_bytes=0, tx_packets=0}
            Select_src_port: [p1]
            Select_dst_port: [p1]
            Output_port: p2

(Output minh họa — cấu trúc và tên field đúng theo ovs-vsctl show thật, số liệu cụ thể chỉ mang tính ví dụ.)

Bước 4-5 — bắt gói ở port đích trong khi gửi traffic qua port nguồn:

# Chạy tcpdump trên namespace/interface tương ứng port p2
sudo tcpdump -i p2 -n

# Ở một terminal khác, gửi traffic qua port p1 (ví dụ ping từ namespace gắn p1)
sudo ip netns exec ns1 ping -c 3 192.168.0.2
# Output minh họa tcpdump trên p2 — thấy đúng gói ICMP đã gửi qua p1, dù p2 không phải đích thật của traffic
14:22:01.123456 IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 1, seq 1
14:22:01.123789 IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 1, seq 1

(Output minh họa — nội dung gói và timestamp chỉ mang tính ví dụ.)

Đúng cột Statistics: {tx_bytes, tx_packets} xem ở Bước 3 sẽ tăng lên tương ứng số gói/byte đã mirror — verify nhanh không cần tcpdump nếu chỉ cần biết mirror có hoạt động hay không, không cần xem nội dung.

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

  1. Cấu hình sFlow trên một bridge lab, trỏ targets về 127.0.0.1:6343 (hoặc IP máy chạy collector). Cài và chạy sflowtool -p 6343 làm collector test (https://github.com/sflow/sflowtool), tạo traffic qua bridge, và xác nhận sflowtool in ra sample nhận được. Đặt sampling=10 (thay vì mặc định 400) để dễ quan sát hơn trong lab traffic thấp — tự giải thích vì sao lab traffic thấp cần giảm sampling xuống mới thấy được sample thường xuyên.
  2. Đọc lại đúng đoạn ở Mục 4 phân biệt per-bridge sampling và flow-based sampling. Giả sử bạn chỉ muốn xuất IPFIX record cho đúng traffic của một tenant cụ thể (khớp một dải IP nhất định), trong khi các tenant khác trên cùng bridge không cần giám sát — cách nào trong hai cách cấu hình IPFIX phù hợp hơn, và vì sao cách còn lại không làm được việc đó mà không ảnh hưởng tenant khác.
  3. Đọc lại cảnh báo về output_vlan (RSPAN) ở Mục 2 — rủi ro làm switch vật lý không quản lý học nhầm MAC. Giả sử hạ tầng giám sát của bạn bắt buộc phải đưa traffic mirror đi qua ít nhất một switch trung gian trước khi tới thiết bị phân tích, hãy đề xuất một cách giảm rủi ro này (gợi ý: liên hệ lại khái niệm VLAN trunk/isolation đã học ở Bài 8).

Nguồn tham khảo​

  • Định nghĩa Mirror, ba cột chọn gói (select_all/select_dst_port/select_src_port/select_vlan/filter), hai cột đích loại trừ nhau (output_port/output_vlan), cảnh báo rủi ro RSPAN với switch không quản lý, thay đổi hành vi thời điểm mirror giữa OVS 2.4 và 2.5+ — Mirror TABLE, ovs-vswitchd.conf.db(5), openvswitch.org.
  • Cột bảng sFlow (agent, header, polling, sampling, targets) và giá trị mặc định (400 packet, 30 giây polling, 128 byte header) — sFlow TABLE, ovs-vswitchd.conf.db(5), openvswitch.org.
  • Cột bảng IPFIX, hai cách cấu hình per-bridge sampling và flow-based sampling qua Flow_Sample_Collector_Set, câu xác nhận IPFIX trên OVS vẫn dựa trên sampling ("The IPFIX implementation in Open vSwitch samples packets at a configurable rate..."), cache_active_timeout/cache_max_flows, enable-tunnel-sampling — IPFIX TABLE và Flow_Sample_Collector_Set TABLE, ovs-vswitchd.conf.db(5), openvswitch.org.
  • Bảng NetFlow (kiểu cũ, không template) — NetFlow TABLE, ovs-vswitchd.conf.db(5), openvswitch.org.
  • Ví dụ CLI chính thức cho Mirror, NetFlow, sFlow, IPFIX (mục "CONFIGURATION COOKBOOK"), và quy tắc "Names of tables and columns are not case-sensitive, and - and _ are treated interchangeably. Unique abbreviations of table and column names are acceptable" — ovs-vsctl(8), openvswitch.org.
  • "This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network"; số hiệu version trong header IPFIX "incrementing by one the version used in the NetFlow services export version 9" (RFC 7011 §3.1) — RFC 7011, IETF; RFC 5101 (được ovs-vswitchd.conf.db(5) trích cho stats_interval) đã bị thay thế bởi RFC 7011 từ 2013 — RFC 5101, IETF.
  • Cú pháp action sample (probability=packets — "The number of sampled packets out of 65535"; collector_set_id=id; obs_domain_id/obs_point_id) dùng cho flow-based IPFIX sampling — ovs-actions(7), openvswitch.org.
  • "sFlow is a sampling technology", "sFlow is scalable, enabling it to monitor links of speeds up to 10Gb/s and beyond without impacting the performance of core internet routers and switches" — sFlow.org.
  • Công cụ collector test sflowtool, cú pháp sflowtool -p <port> — sflow/sflowtool, GitHub.
  • Cách kiểm tra trạng thái bridge bằng ovs-vsctl show đã dùng từ Bài 4-5; action sample trong OpenFlow flow table liên hệ trực tiếp add-flow/action đã học ở Bài 6 và Bài 12; ba loại tunnel VXLAN/GRE/Geneve trong enable-tunnel-sampling đã học ở Bài 9; VLAN trunk/isolation liên quan tới rủi ro RSPAN đã học ở Bài 8.

Tiếp theo: Module 4, Bài 17 — OVN: logical switching/routing, distributed control plane.