Kiểm thử LACP và MLAG failover: đo hội tụ, phân phối hash và lỗi bất đối xứng

IEEE 802.1AX chuẩn hóa link aggregation, còn MLAG là tên gọi phổ biến cho cơ chế đa chassis với nhiều cách triển khai. Vì vậy, bài kiểm thử phải tách yêu cầu LACP khỏi tuyên bố riêng về peer-link, keepalive, dual-active detection và state synchronization.

Ba lớp bằng chứng cần có: control plane hình thành đúng aggregator; data plane không loop/duplicate/black-hole; và dịch vụ đạt ngưỡng packet loss, latency, throughput trong lỗi và phục hồi.

Topology tối thiểu gồm system under test hai switch MLAG, một thiết bị hoặc traffic generator dual-homed, peer-link, keepalive độc lập và đầu nhận phía upstream/downstream. Đặt capture ở cả hai member và phía nhận để phát hiện duplicate hoặc reorder.

Thử cả north–south và east–west nếu kiến trúc dùng hai loại. Ghi rõ VLAN, STP interaction, routing adjacency, MTU và LACP timer. Khi dùng virtual MAC hoặc anycast gateway, thu bảng MAC/ARP/ND trước và sau sự kiện.

Một TCP flow thường chỉ đi một member để giữ thứ tự; vì vậy không thể kỳ vọng một flow dùng tổng bandwidth của LAG. Tạo hàng trăm hoặc hàng nghìn flow với biến thiên địa chỉ IP, port và VLAN phù hợp hash input của thiết bị. Không giả định thuật toán hash nếu tài liệu phiên bản không xác nhận.

Đo riêng unicast, broadcast/multicast cần thiết và traffic hai chiều. Giữ packet size, offered load và flow duration cố định khi so sánh. Với elephant flow, kiểm tra mất cân bằng; với mice flow, kiểm tra tốc độ tạo/xóa state.

KPI gồm aggregator formation time, member utilization distribution, throughput/goodput, packet loss, latency, jitter, reorder, duplicate, MAC move, control-plane CPU và convergence time. Báo cả tổng lưu lượng và từng member; tổng throughput đẹp có thể che một member quá tải.

Bằng chứng gồm LACPDU capture, trạng thái actor/partner, log MLAG, counters interface/queue, MAC/FIB snapshots và sequence number của traffic generator. Định nghĩa convergence từ thời điểm sự kiện vật lý hoặc protocol tới thời điểm lưu lượng ổn định trong ngưỡng.

Không gom peer-link down và chassis down thành một ca; tác động và state machine khác nhau.

• Sự kiện: Một member link down · Nguy cơ: Mất flow đang hash vào link · Kỳ vọng pass: Chuyển sang member còn lại, loss dưới ngưỡng
• Sự kiện: Một member lỗi một chiều · Nguy cơ: Link có thể vẫn up · Kỳ vọng pass: Phát hiện/loại khỏi forwarding theo thiết kế
• Sự kiện: Peer-link down · Nguy cơ: State sync gián đoạn · Kỳ vọng pass: Không loop, hành vi orphan rõ ràng
• Sự kiện: Keepalive down · Nguy cơ: Mất health signal · Kỳ vọng pass: Không kích hoạt split-brain sai
• Sự kiện: Một chassis reboot · Nguy cơ: Nửa hệ thống mất · Kỳ vọng pass: Chassis còn lại chuyển tiếp đúng
• Sự kiện: Peer-link + keepalive lỗi · Nguy cơ: Dual-active/split-brain · Kỳ vọng pass: Cơ chế bảo vệ đúng tài liệu
• Sự kiện: Member phục hồi · Nguy cơ: Rehash/reorder · Kỳ vọng pass: Ổn định, không flapping

Đầu tiên xác minh LACP negotiation ở tải thấp và cả hai mode/timer được hỗ trợ. Sau đó chạy traffic nhiều flow ở 25%, 50%, 80% capacity, ghi phân phối từng member. Gây lỗi một member và đo loss cùng thời gian ổn định; phục hồi member rồi quan sát rehash.

Lặp với flow population khác nhau để tránh kết luận từ một hash seed thuận lợi. Nếu thiết bị có resilient hashing, xác minh tỷ lệ flow bị remap thay vì chỉ đọc trạng thái feature. Kiểm tra oversubscription: khi một member mất, tổng offered load có thể vượt capacity còn lại; loss do congestion phải tách khỏi convergence.

Trong lab được cô lập, thử mất peer-link, mất keepalive và mất đồng thời theo đúng thứ tự. Quan sát port nào bị suspend, chassis nào primary, MAC nào tiếp tục quảng bá và có duplicate frame không. Không thử split-brain trực tiếp trên production nếu chưa có change plan.

Orphan port chỉ nối một chassis cần được thử khi chassis đó hoặc peer-link lỗi. Với recovery, theo dõi state synchronization trước khi port được mở lại; một phục hồi quá sớm có thể tạo loop hoặc MAC churn.

• Chốt chuẩn LACP và các chức năng MLAG riêng theo phiên bản.
• Lưu running configuration và sơ đồ cáp.
• Đồng bộ thời gian, xóa counters và khởi tạo baseline.
• Dùng đủ flow entropy để kiểm thử hash.
• Đo từng member, tổng LAG và đầu nhận.
• Thử member down, lỗi một chiều, peer-link, keepalive và chassis.
• Kiểm tra orphan port, STP/routing adjacency và MAC/FIB.
• Thử phục hồi ở tải thấp rồi tải mục tiêu.
• Phân biệt convergence loss với congestion loss.
• Lưu pcap, logs, counters và tiêu chí pass/fail.

Hash distribution phụ thuộc header fields, phiên bản và flow population; không kỳ vọng cân bằng tuyệt đối. MLAG behavior không được chuẩn hóa đồng nhất giữa các hãng. Kết quả trên hai member không chứng minh quy mô tối đa hoặc tương tác với routing overlay.

Packet loss bằng không trong một lần chạy không chứng minh không có race condition. Cần lặp, thay thứ tự lỗi và kiểm tra ở tải khác nhau. Mọi tuyên bố về resilient hashing, sub-second convergence hoặc dual-active protection phải gắn với phiên bản và điều kiện đo.