Kiểm thử ECMP flow hashing: phân phối tải, flow affinity và hội tụ khi mất next hop

Equal-Cost Multipath cho phép nhiều next hop có cùng cost cùng tham gia forwarding. Routing table chỉ chứng minh control plane đã cài các đường; nó không chứng minh data plane phân phối đều, giữ đúng flow affinity hay phục hồi trong ngưỡng khi một thành viên lỗi.

RFC 3272 lưu ý ECMP phân phối dựa trên các flow và không xét trạng thái congestion của từng đường. Vì vậy, một số lượng nhỏ elephant flow có thể làm một path đầy trong khi path khác nhàn rỗi dù hash hoạt động đúng thiết kế. Câu hỏi kiểm thử phải là: với traffic profile xác định, độ lệch cho phép là bao nhiêu, flow có bị reorder không và bao nhiêu flow bị remap khi nhóm ECMP thay đổi?

Tách bốn mục tiêu: correctness của next-hop set; distribution giữa path; per-flow consistency; convergence/remapping. Không gộp chúng vào một số throughput tổng.

Topology tối thiểu gồm source generator, ingress router/leaf, ít nhất hai equal-cost path, egress router/leaf và receiver. Với fabric leaf–spine, nên thử một tầng và nhiều tầng vì cùng hash input tại các tầng có thể tạo polarization. Đặt capture hoặc counter tại ingress, từng member link và egress.

Thu đồng thời RIB/FIB, adjacency/ECMP group, per-interface packet/byte counter, queue/drop, CPU và event timestamp. Nếu thiết bị hỗ trợ flow telemetry, dùng nó để ánh xạ 5-tuple với next hop nhưng vẫn cần sequence ở data plane để phát hiện loss/reorder.

Hash thường dùng một tập trường L3/L4, nhưng chi tiết phụ thuộc thiết bị và cấu hình. Test cần thay đổi có kiểm soát source/destination IP, source/destination port, protocol, IPv6 flow label, VLAN hoặc tunnel outer/inner header. Không giả định thiết bị hash theo inner 5-tuple nếu chưa đối chiếu tài liệu phiên bản.

Chạy ít nhất ba profile: nhiều flow đồng kích thước để đánh giá thuật toán; mix mouse/elephant flow gần workload thật; và adversarial profile với ít entropy để phát hiện polarization. Khóa packet size, rate, duration và flow arrival pattern. Với bidirectional service, xác nhận hai chiều có yêu cầu symmetry hay chỉ cần per-direction affinity.

• Profile: Uniform flows · Mục tiêu: Đánh giá phân phối cơ bản · Biến chính: N flow, cùng bitrate
• Profile: IMIX/mouse-elephant · Mục tiêu: Gần traffic vận hành · Biến chính: Flow size, duration, arrival
• Profile: Low entropy · Mục tiêu: Bộc lộ polarization · Biến chính: Ít IP/port biến đổi
• Profile: Tunnel traffic · Mục tiêu: Kiểm tra outer/inner hash · Biến chính: VXLAN/GRE, VNI, inner 5-tuple
• Profile: Fragmented traffic · Mục tiêu: Kiểm tra consistency · Biến chính: IPv4/IPv6 fragment behavior

Đừng dùng duy nhất phần trăm băng thông từng link. Ghi cả số flow, packet và byte vì một path có thể nhận số flow bằng nhau nhưng nhiều elephant flow hơn. Có thể dùng coefficient of variation hoặc độ lệch lớn nhất so với trung bình, nhưng ngưỡng phải gắn với số flow và phân bố kích thước.

KPI tối thiểu gồm per-member utilization; max/min ratio; flow count per path; packet loss; reorder; duplicate; latency distribution; flow affinity violation; convergence time và remapped-flow ratio. Với consistent/resilient hashing, tỷ lệ remap sau khi bỏ một member thường quan trọng hơn cân bằng tuyệt đối.

Bằng chứng gồm traffic configuration, seed nếu tool hỗ trợ, snapshot ECMP group, counter trước/sau, per-flow mapping và capture có sequence. Lặp nhiều seed để tránh kết luận từ một phân bố ngẫu nhiên thuận lợi.

Hàng “congested path” là kiểm tra quan trọng: ECMP thuần túy không đồng nghĩa congestion-aware load balancing. Nếu traffic vẫn đi vào đường nghẽn, không tự động kết luận DUT lỗi nếu thiết kế không có telemetry hoặc cơ chế adaptive routing.

• Tình huống: Baseline · Thao tác: Một path · Kỳ vọng: Không loss/reorder · Bằng chứng: Sequence + counter
• Tình huống: ECMP steady · Thao tác: 2/4/8 member · Kỳ vọng: Phân phối trong ngưỡng · Bằng chứng: Per-link byte/flow
• Tình huống: Low entropy · Thao tác: Cố định nhiều trường · Kỳ vọng: Ghi nhận polarization · Bằng chứng: Hash input vs path
• Tình huống: Add member · Thao tác: Thêm next hop · Kỳ vọng: Remap có giới hạn · Bằng chứng: Mapping trước/sau
• Tình huống: Remove member · Thao tác: Ngắt link/withdraw route · Kỳ vọng: Phục hồi trong SLA · Bằng chứng: Fault marker + loss
• Tình huống: Flap · Thao tác: Lặp down/up · Kỳ vọng: Không stale FIB · Bằng chứng: Event/FIB/counter
• Tình huống: Congested path · Thao tác: Giới hạn một member · Kỳ vọng: ECMP không tự nhận biết nếu không có cơ chế khác · Bằng chứng: Queue/drop
• Tình huống: Tunnel · Thao tác: Thay VNI/inner flow · Kỳ vọng: Đúng capability công bố · Bằng chứng: Capture/member map

Tạo fault bằng link down vật lý, shutdown interface, withdraw route/BGP, mất adjacency và lỗi upstream. Mỗi loại có detection chain khác nhau. Đặt marker chính xác lúc fault được áp dụng; đo packet cuối trên path cũ, packet đầu trên path mới và khoảng sequence bị thiếu.

Khi remove một member, tách flow vốn đi qua member lỗi và flow ở member còn tốt. Resilient hashing tốt phải hạn chế xáo trộn không cần thiết, nhưng hành vi cụ thể phụ thuộc nền tảng. Khi add member trở lại, kiểm tra rebalancing có làm reorder flow đang tồn tại hay chỉ ảnh hưởng flow mới.

RFC 7938 đề cập consistent hashing trong data-center BGP để giảm thay đổi flow-to-next-hop affinity khi member thay đổi. Đây là hướng thiết kế, không phải bảo đảm mọi switch triển khai cùng thuật toán hoặc cùng tỷ lệ remap.

Pass/fail mẫu: zero unexplained loss ở steady state; không reorder trong một flow nếu yêu cầu; utilization deviation dưới ngưỡng đã thống nhất tại số flow xác định; convergence dưới SLA; flow trên member không lỗi không bị remap vượt ngân sách.

• 1. Ghi model, firmware, hash configuration và topology.
• 2. Xác minh các route có cùng cost trong RIB và FIB.
• 3. Chạy một path để tạo baseline của tool/DUT.
• 4. Bật toàn bộ member, chạy uniform flow ở nhiều scale.
• 5. Lặp với mouse/elephant và low-entropy profile.
• 6. Thay đổi từng hash field để suy ra input thực tế.
• 7. Thử tunnel/fragment nếu thuộc phạm vi.
• 8. Remove/add từng member và đo remap/loss.
• 9. Tạo congestion có kiểm soát trên một path.
• 10. Lưu config, counter, pcap, per-flow map và verdict.

Nếu số flow đều nhưng byte lệch, xem flow-size distribution trước khi sửa hash. Nếu cả flow và byte lệch với nhiều entropy, kiểm tra member weight, LAG bên dưới, next-hop programming và hash polarization. Nếu chỉ tunnel lệch, kiểm tra thiết bị có hash inner header và parser nhận đúng encapsulation.

Loss chỉ xuất hiện khi failover có thể đến từ detection timer, FIB programming, neighbor resolution hoặc queue chuyển tiếp. Reorder có thể do flow bị remap giữa các path có latency khác nhau. Đối chiếu timeline control plane và data plane để tránh quy toàn bộ gián đoạn cho BGP/OSPF.

Nếu kết quả thay đổi mạnh giữa các lần chạy, lưu seed, thứ tự flow arrival và bảng mapping. Phân bố thống kê cần nhiều lần lặp; một đồ thị “đẹp” không đủ làm acceptance evidence.

Kết quả phụ thuộc ASIC, firmware, hash seed, số member, encapsulation và traffic profile. Không thể kết luận thiết bị A “cân bằng tốt hơn” thiết bị B khi số flow, flow size hoặc seed khác nhau.

ECMP distribution không chứng minh end-to-end application performance. Ứng dụng còn chịu congestion, transport behavior và server bottleneck. Bài ECMP phải được nối với latency/loss ứng dụng nếu mục tiêu cuối là trải nghiệm dịch vụ.