Kiểm thử packet broker trước microburst và oversubscription

Một liên kết egress 100 Gb/s nhận bốn nguồn 40 Gb/s không nhất thiết luôn quá tải. Tuy nhiên, nếu các nguồn phát burst đồng thời, tổng tốc độ tức thời có thể vượt egress dù trung bình 1 giây chỉ 30%. Queue nhỏ hoặc scheduling không phù hợp sẽ gây tail drop trước khi SNMP polling kịp phản ánh.

Với network packet broker, mất một phần packet có thể làm NDR bỏ lỡ phiên, APM sai transaction hoặc recorder không tái dựng được sự kiện. Vì thế acceptance test phải đo packet sequence và timestamp, không chỉ đọc utilization.

Topology gồm traffic generator đa cổng, TAP/SPAN hoặc nguồn mô phỏng, packet broker, hai nhóm tool egress và capture độc lập. Một đường reference bypass packet broker giúp xác nhận generator thực sự đã phát gì. Đồng bộ PTP/NTP phù hợp và sequence number trong payload giúp so sánh từng packet.

Không dùng counter của duy nhất thiết bị cần kiểm thử làm nguồn sự thật. Thu cả port counter, queue/drop counter, capture ở tool và thống kê generator. Nếu thiết bị cung cấp telemetry theo queue, lưu độ phân giải và chu kỳ lấy mẫu.

Khóa frame size, encapsulation, VLAN/MPLS/VXLAN, burst length, inter-burst gap, số nguồn đồng thời, phase offset và tỷ lệ fan-in. Với flow load balancing, khóa 5-tuple distribution và kiểm tra cả elephant lẫn mice flow.

Thử frame 64 byte, IMIX và jumbo riêng biệt vì packets per second và byte rate gây áp lực khác nhau. Ghi rõ FCS, preamble và inter-frame gap được công cụ tính hay không; sai cách tính wire rate có thể làm offered load lệch đáng kể.

• Biến: Burst duration · Mức thử gợi ý: µs, ms, 100 ms · Rủi ro cần quan sát: Buffer exhaustion
• Biến: Fan-in · Mức thử gợi ý: 2, 4, 8 nguồn · Rủi ro cần quan sát: Egress oversubscription
• Biến: Frame size · Mức thử gợi ý: 64, IMIX, jumbo · Rủi ro cần quan sát: PPS hoặc byte-rate bottleneck
• Biến: Filter · Mức thử gợi ý: none, allow/drop · Rủi ro cần quan sát: Rule capacity và precedence
• Biến: Replication · Mức thử gợi ý: 1:1, 1:N · Rủi ro cần quan sát: Fabric/egress amplification
• Biến: Slicing · Mức thử gợi ý: off/on · Rủi ro cần quan sát: Tool compatibility, truncation

KPI chính gồm packet loss tuyệt đối và theo tỷ lệ, burst loss window, latency qua broker, jitter, out-of-order, duplicate, timestamp accuracy và thời gian counter cập nhật. Với filtering, đo false pass và false drop; với load balancing, đo độ lệch flow giữa các tool.

Pass/fail phải gắn với use case. Recorder điều tra sự cố có thể yêu cầu zero unintended loss trong phạm vi test; công cụ sampling có thể chấp nhận chính sách khác nhưng phải chứng minh drop là chủ đích. Không gọi packet loss là “không có” nếu độ phân giải đo không đủ bắt burst.

• Trường hợp: Tổng ingress < egress · Kỳ vọng: Không drop ngoài chính sách · Bằng chứng: Sequence liên tục · Quyết định: Baseline
• Trường hợp: Burst > egress, trung bình thấp · Kỳ vọng: Xác định headroom/buffer · Bằng chứng: Loss window + queue · Quyết định: Cần sizing
• Trường hợp: Replication 1:N · Kỳ vọng: Mỗi tool nhận bản đúng · Bằng chứng: Hash/capture · Quyết định: Kiểm tra fabric
• Trường hợp: Filter conflict · Kỳ vọng: Precedence đúng · Bằng chứng: Packet marker · Quyết định: Kiểm tra rule
• Trường hợp: Tool port down · Kỳ vọng: Hành vi failover rõ · Bằng chứng: Event + capture · Quyết định: Runbook
• Trường hợp: Flow load balance · Kỳ vọng: Flow không bị split ngoài ý muốn · Bằng chứng: 5-tuple mapping · Quyết định: Tool fidelity

Pha A xác nhận cáp, FEC, link speed và baseline không filter. Pha B tăng steady load tới ngưỡng thiết kế. Pha C giữ average load nhưng co burst duration và đồng bộ nguồn. Pha D bật từng chức năng packet manipulation. Pha E gây lỗi tool port và khôi phục.

• 1. Gắn sequence ID và timestamp vào traffic.
• 2. Capture reference trước packet broker.
• 3. Chạy từng cổng độc lập để loại lỗi vật lý.
• 4. Fan-in theo bậc, tăng cả byte rate và PPS.
• 5. Quét phase offset để tìm worst-case alignment.
• 6. Bật filter, replication, load balancing rồi slicing từng bước.
• 7. Làm flap egress/tool port có kiểm soát.
• 8. So sánh counter với packet-level capture.
• 9. Lặp lại sau warm restart và config reload.
• 10. Xuất topology, cấu hình, traffic profile và pass/fail.

• Xác nhận wire-rate accounting và FEC.
• Có đường reference capture độc lập.
• Đã thử worst-case frame size/PPS.
• Đã quét burst duration và phase alignment.
• Phân biệt intentional drop với unintended loss.
• Rule filtering có test positive và negative.
• Load balancing giữ flow affinity khi yêu cầu.
• Packet slicing không làm công cụ downstream lỗi parser.
• Counter, telemetry và capture có thể đối soát.
• Có runbook khi tool port hoặc packet broker fail.

Kết quả phụ thuộc line card, firmware, license, mode fabric, packet manipulation và topology. Không được suy rộng một model sang toàn bộ dòng sản phẩm. Buffer thường là tài nguyên dùng chung; một bài test đơn cổng không chứng minh hành vi khi nhiều cổng cạnh tranh.

Capture software có thể tự drop vì CPU hoặc storage. Trước khi quy lỗi cho packet broker, chứng minh capture appliance đủ headroom và counter của NIC không tăng. Báo cáo nên giữ raw pcap có chọn lọc, sequence summary và cấu hình phiên bản.

• Microburst: Burst tốc độ cao tồn tại trong cửa sổ rất ngắn.
• Oversubscription: Tổng nhu cầu vượt capacity của tài nguyên chung.
• Fan-in: Nhiều ingress hợp vào một egress.
• Packet fidelity: Mức giữ nguyên nội dung và thứ tự packet.
• Flow affinity: Các packet cùng flow tới cùng một tool.
• Packet slicing: Cắt bớt payload trước khi chuyển tới công cụ.
• Headroom: Dư địa chịu burst trước khi drop.