Kiểm thử ECMP hashing: entropy, polarization, member failure và flow remap

ECMP cho phép nhiều next-hop có cùng chi phí tham gia forwarding. Tuy nhiên, control plane có đủ route không đồng nghĩa data plane chia tải đều. Phần lớn thiết bị chọn đường theo hash trên tập trường của packet hoặc flow; một elephant flow vẫn có thể chiếm trọn một member trong khi nhiều mice flow chia đều.

RFC 2991 và RFC 2992 mô tả các vấn đề multipath và một cách phân tích hash-threshold. Chúng không bắt buộc mọi thiết bị dùng cùng seed, trường hash hay thuật toán resilient hashing. Vì vậy mục tiêu không phải đoán thuật toán, mà chứng minh operating envelope: loại flow nào được phân phối, mức lệch tải chấp nhận được và ảnh hưởng khi membership đổi.

Topology tối thiểu gồm traffic generator, DUT có N next-hop, N receiver và điểm capture/counter ở ingress lẫn từng egress. Leaf–spine hai leaf và bốn spine là baseline để quan sát phân phối ở ingress leaf. Để kiểm polarization giữa nhiều lần chọn đường, dùng fabric nhiều tầng hoặc LAG/ECMP lồng nhau và thu counter tại từng tầng quyết định next-hop; không coi riêng topology hai leaf–bốn spine là bằng chứng đã thử hai tầng hash độc lập. Chạy direct baseline trước để xác nhận generator và receiver không tự giới hạn throughput.

Đồng bộ clock, thu route/FIB, adjacency, interface counter, queue drop, ECN marking và packet capture mẫu. Nếu overlay VXLAN hoặc SR-MPLS nằm trong phạm vi, lưu cả outer/inner header vì thiết bị có thể hash trên tập trường khác nhau.

Tạo ba nhóm: nhiều flow đồng kích thước; phân bố mice/elephant gần production; và adversarial profile chỉ đổi từng trường. Lần lượt quét source/destination IP, source/destination port, IPv6 flow label, VLAN/VNI hoặc entropy label nếu có. Giữ tổng offered load, frame size, duration và route state cố định khi đổi một biến.

Khóa software, configuration, hash seed nếu có, LAG/ECMP nesting, symmetric-hash mode, tunnel mode, MTU và QoS. RFC 6438 giải thích cách dùng IPv6 flow label cho load sharing; RFC 6790 định nghĩa entropy label cho MPLS. Sự hiện diện của trường không bảo đảm DUT thực sự dùng nó.

Đo tỷ lệ flow và byte trên từng member, coefficient of variation, max/min utilization, packet loss, latency p50/p95/p99, reordering và queue occupancy. Khi topology đổi, thêm convergence time, số flow bị remap, transaction failure và service restoration. Với workload lệch kích thước, fairness theo flow có thể đẹp trong khi fairness theo byte rất xấu.

Ngưỡng pass/fail nên được tính theo số flow và phân bố kích thước thực tế. Không áp một tỷ lệ “25% mỗi đường” cứng cho bốn member nếu mẫu chỉ có vài elephant flow.

• KPI: Flow distribution · Cách đo: 5-tuple/correlation ID · Bằng chứng: receiver log, sampled pcap · Cạm bẫy: Đếm packet thay vì flow
• KPI: Byte distribution · Cách đo: per-egress bytes · Bằng chứng: counter trước/sau test · Cạm bẫy: Counter nền hoặc wrap
• KPI: Loss/reordering · Cách đo: sequence number · Bằng chứng: generator/receiver capture · Cạm bẫy: Capture loss bị nhầm là network loss
• KPI: Remap ratio · Cách đo: flow→member trước/sau · Bằng chứng: mapping snapshot · Cạm bẫy: Tạo flow mới làm sai mẫu
• KPI: Service restoration · Cách đo: giao dịch hoàn tất · Bằng chứng: app log và trigger time · Cạm bẫy: Đồng nhất route convergence với dịch vụ

Ma trận phải tách control-plane event khỏi physical failure. Withdraw route, shutdown interface, drop BFD và blackhole downstream tạo tín hiệu phát hiện khác nhau, dù cuối cùng đều làm một path không dùng được.

• Kịch bản: Baseline N đường · Biến thay đổi: Nhiều 5-tuple · Câu hỏi cần trả lời: Hash có dùng đủ member?
• Kịch bản: Chỉ đổi port · Biến thay đổi: L4 entropy · Câu hỏi cần trả lời: NAT hoặc ứng dụng có tạo đủ biến thiên?
• Kịch bản: Chỉ đổi IP · Biến thay đổi: L3 entropy · Câu hỏi cần trả lời: Flow không port được xử lý thế nào?
• Kịch bản: Overlay · Biến thay đổi: Inner/outer header · Câu hỏi cần trả lời: DUT hash trên lớp nào?
• Kịch bản: Hai tầng ECMP · Biến thay đổi: Seed/algorithm mỗi tầng · Câu hỏi cần trả lời: Có polarization không?
• Kịch bản: Rút một member · Biến thay đổi: Membership N→N−1 · Câu hỏi cần trả lời: Bao nhiêu flow remap, mất bao lâu?
• Kịch bản: Thêm lại member · Biến thay đổi: Membership N−1→N · Câu hỏi cần trả lời: Rebalancing có gây reorder/drop?

Mỗi run chỉ đổi một biến. Nếu vừa đổi số flow, seed và topology thì không thể quy nguyên nhân cho hash hay convergence.

• Bước 1: Xác nhận FIB có đúng N next-hop và mọi interface ổn định.
• Bước 2: Chạy direct baseline ở offered load mục tiêu; lưu loss và latency nền.
• Bước 3: Ví dụ quét 10, 100, 1.000 rồi 10.000 flow đồng kích thước (mốc minh họa, điều chỉnh theo phạm vi lab); đo flow/byte distribution.
• Bước 4: Chạy traffic profile mice/elephant; kiểm max-link utilization và queue drop.
• Bước 5: Quét từng trường header để suy ra tập entropy quan sát được.
• Bước 6: Lặp với IPv4, IPv6 và từng overlay nằm trong production scope.
• Bước 7: Trong topology hai tầng, so sánh ma trận ingress×egress để tìm bucket bị khóa.
• Bước 8: Tạo failure có timestamp ngoài băng; đo loss, reorder, remap và phục hồi giao dịch.
• Bước 9: Thêm member trở lại, kiểm tra rebalancing và microburst.
• Bước 10: Lặp tối thiểu ba lần, lưu config, seed, software và raw result.

Với per-flow ECMP dùng hash cố định, giữ nguyên header, hash policy và membership thì flow cần giữ member ổn định. Nếu bật flowlet hoặc adaptive load balancing, việc chuyển member có thể là chủ đích và phải có bài đo riêng. Khi một member mất, các flow trên member đó phải được ánh xạ lại; một số triển khai resilient hashing cố giảm số flow bị xáo trộn, nhưng mức hỗ trợ và hành vi phụ thuộc nền tảng. Đo thực tế thay vì mặc định tính năng tồn tại.

Chèn link-down, route withdraw, adjacency loss và silent blackhole riêng biệt. Silent blackhole đặc biệt quan trọng: interface vẫn up nên phát hiện có thể dựa trên BFD, probe hoặc giao thức định tuyến. Thu trigger time, thời điểm FIB đổi, packet cuối bị mất và transaction đầu thành công.

Phân bố không đều không tự chứng minh thiết bị lỗi. Có thể workload thiếu entropy, một flow quá lớn, NAT làm co tập 5-tuple hoặc QoS khiến byte counter khác nhau. Ngược lại, chia flow đều không chứng minh dịch vụ tốt nếu một member có latency cao hay MTU sai.

Kết luận phải giới hạn theo model, software, topology, header, số flow, traffic mix và tải. Không suy kết quả từ unicast sang multicast, từ cleartext sang tunnel hoặc từ một tầng sang multi-stage fabric. Capture sample cũng không đủ chứng minh zero loss nếu packet capture có thể drop.

• Lưu baseline FIB, hash policy, seed và interface/queue counter.
• Mô phỏng đúng phân bố mice/elephant và số tenant/VNI.
• Đặt cảnh báo theo max-link utilization, không chỉ tổng fabric throughput.
• Canary thay đổi hash policy; chuẩn bị rollback.
• Kiểm tra failure và add-back member trong maintenance window.
• Tái kiểm thử sau nâng cấp network OS, đổi line card hoặc encapsulation.
• Lưu report gồm raw mapping, timestamps, pcap mẫu và tiêu chí pass/fail.

• ECMP: nhiều next-hop cùng chi phí cho một đích.
• Entropy: độ biến thiên của trường đầu vào dùng cho hash.
• Polarization: nhiều tầng hash dồn flow vào một tập đường nhỏ.
• Elephant flow: flow dài hoặc có lượng byte lớn chi phối tải.
• Resilient hashing: cách ánh xạ nhằm giảm số flow bị đổi khi membership thay đổi.
• Flow remap: flow chuyển sang member khác sau thay đổi topology.