Kiểm thử EVPN multihoming: DF election, all-active failover và split-horizon

Mục tiêu không phải chứng minh hai Provider Edge (PE) cùng quảng bá route EVPN. Cần chứng minh Ethernet Segment hoạt động đúng khi ổn định và khi lỗi: CE có dùng được cả hai link, frame BUM chỉ được chuyển tiếp theo vai trò DF phù hợp, split-horizon ngăn phản xạ lưu lượng về cùng segment, và MAC/IP route được hội tụ mà không tạo blackhole kéo dài.

Trước khi chạy, nhóm dự án phải chuyển ngôn ngữ kiến trúc thành câu hỏi đo: mất một member LAG gây bao nhiêu packet loss; mất toàn bộ PE làm gián đoạn bao lâu; traffic trở lại có bị reordering; cùng một frame có xuất hiện hai lần tại CE; phân phối flow giữa hai PE có phù hợp hash và traffic profile hay không. Mỗi câu hỏi phải gắn với điểm lấy packet, counter và timestamp.

Topology tối thiểu gồm CE dual-homed tới PE1 và PE2 qua một Ethernet Segment, một hoặc nhiều remote PE/VTEP, cùng thiết bị tạo lưu lượng ở hai phía. Underlay phải có đường độc lập đủ để tách lỗi access link khỏi lỗi fabric. Nếu dùng LAG, ghi lại thuật toán hash, member, tốc độ cổng, LACP timer và trạng thái đồng bộ.

Thiết bị đo phát traffic hai chiều gồm unicast đã học MAC, unknown unicast, broadcast, multicast và một tập nhiều flow để quan sát load distribution. Đồng hồ của traffic generator, packet capture và thiết bị mạng cần đồng bộ; độ phân giải timestamp phải nhỏ hơn mục tiêu failover. Capture nên đặt tại CE-facing link của cả hai PE và phía remote để phân biệt packet bị mất, bị nhân đôi hay chỉ đi đường khác.

Kết quả khó so sánh nếu thay đổi đồng thời timer, thuật toán DF, số lượng flow và loại route. Hồ sơ chạy phải ghi phiên bản NOS, chế độ single-active/all-active, ESI, ES-Import RT, EVPN route type sử dụng, DF election algorithm, preference, hold timer, LACP mode, BFD và chính sách MAC mobility. Với RFC hoặc draft có nhiều tùy chọn, phải xác nhận thiết bị thực sự triển khai tùy chọn nào.

Traffic profile cần khóa frame size, offered load, số flow, VLAN/VNI, tỷ lệ BUM, chiều truyền và thời gian steady state. Một flow duy nhất không đủ đánh giá cân bằng tải. Ngược lại, hàng nghìn flow có thể che một hash bias ở nhóm lưu lượng quan trọng; vì vậy nên chạy cả profile kiểm soát với tuple cố định và profile phân bố gần sản xuất.

• Nhóm biến: EVPN/ES · Giá trị phải ghi: ESI, mode, DF algorithm, preference · Rủi ro nếu bỏ qua: Không tái hiện được DF election
• Nhóm biến: Access · Giá trị phải ghi: LAG member, LACP timer, MTU, VLAN · Rủi ro nếu bỏ qua: Nhầm lỗi LACP/MTU thành lỗi EVPN
• Nhóm biến: Underlay · Giá trị phải ghi: IGP/BGP/BFD, ECMP, latency · Rủi ro nếu bỏ qua: Không phân biệt access với fabric
• Nhóm biến: Traffic · Giá trị phải ghi: frame size, flow count, BUM ratio, load · Rủi ro nếu bỏ qua: Kết luận sai về throughput và hash
• Nhóm biến: Đo lường · Giá trị phải ghi: điểm capture, clock, counter interval · Rủi ro nếu bỏ qua: Sai outage duration hoặc duplicate

Baseline bắt đầu khi tất cả neighbor, LAG và route đã ổn định. Lưu snapshot Ethernet Segment database, DF state theo VLAN/VNI, EVPN route type 1/2/3/4, next-hop, MAC table và counter cổng. Sau đó chạy traffic đủ lâu để loại ảnh hưởng warm-up, learning và ARP/ND ban đầu. Throughput nhận phải khớp offered load sau khi trừ overhead đã thống nhất; packet loss và duplicate ở trạng thái ổn định phải bằng ngưỡng nền đã định.

Baseline data plane cần xác minh ba tính chất riêng. Thứ nhất, known unicast tới CE không bị gửi trùng. Thứ hai, BUM từ remote chỉ được chuyển theo quy tắc DF và không tạo loop. Thứ ba, traffic từ CE vào fabric được chia theo hành vi triển khai đã công bố, không mặc định phải 50/50. Counter trên PE chỉ là bằng chứng bổ trợ; packet sequence và capture ở điểm đích mới cho biết người dùng thực sự nhận gì.

KPI cốt lõi là loss count, longest loss burst, convergence time, duplicate count, out-of-order ratio, latency p50/p95/p99 và throughput theo từng hướng. Convergence time nên định nghĩa từ thời điểm sự kiện vật lý hoặc lệnh fault injection đến packet hợp lệ đầu tiên của chuỗi ổn định mới. Nếu chỉ dùng polling một giây, không nên công bố kết quả ở đơn vị mili giây.

Control plane cần log thời điểm link/LACP thay đổi, DF election, withdrawal/update route, MAC mobility sequence và FIB programming. Data plane cần sequence number, timestamp và capture trước/sau DUT. Báo cáo pass/fail phải giữ raw counter và PCAP hoặc hash của PCAP; biểu đồ tổng hợp không đủ để điều tra duplicate hoặc micro-loss.

• KPI: Service interruption · Cách đo: Chuỗi packet có sequence · Bằng chứng đầu ra: Time series TX/RX · Tiêu chí mẫu: Theo SLA dự án
• KPI: Duplicate · Cách đo: Sequence xuất hiện >1 lần · Bằng chứng đầu ra: PCAP hai điểm · Tiêu chí mẫu: 0 ngoài trường hợp đã giải thích
• KPI: Reordering · Cách đo: Khoảng cách sequence · Bằng chứng đầu ra: Counter + PCAP · Tiêu chí mẫu: Ngưỡng theo ứng dụng
• KPI: DF transition · Cách đo: Event log có timestamp · Bằng chứng đầu ra: ES/DF state trước-sau · Tiêu chí mẫu: Vai trò duy nhất, đúng VLAN
• KPI: Load distribution · Cách đo: Bytes/packets theo PE/member · Bằng chứng đầu ra: Counter từng interface · Tiêu chí mẫu: So với hash profile, không ép 50/50
• KPI: Recovery consistency · Cách đo: Lặp N lần · Bằng chứng đầu ra: Phân bố min/median/p95/max · Tiêu chí mẫu: Không chỉ lấy lần tốt nhất

Không nên dùng một thao tác shutdown đại diện cho mọi lỗi. Link-down vật lý, mất một member LAG, mất toàn bộ access bundle, process restart, mất BGP EVPN, mất underlay và power-off PE kích hoạt các chuỗi phát hiện khác nhau. Mỗi sự cố phải chạy độc lập, phục hồi về baseline và lặp đủ số lần để thấy phân bố.

• Sự kiện: Mất 1 member LAG · Điều cần quan sát: LACP, hash lại flow, loss/reorder · Nguyên nhân nghi ngờ nếu fail: LACP timer hoặc member programming
• Sự kiện: Mất toàn bộ link CE–PE1 · Điều cần quan sát: ES state, traffic qua PE2 · Nguyên nhân nghi ngờ nếu fail: CE teaming, mass-withdraw, FIB
• Sự kiện: Dừng BGP EVPN trên PE1 · Điều cần quan sát: Route withdrawal nhưng link còn up · Nguyên nhân nghi ngờ nếu fail: Control/data-plane coupling
• Sự kiện: Mất underlay PE1 · Điều cần quan sát: BFD/IGP, next-hop recursion · Nguyên nhân nghi ngờ nếu fail: Underlay convergence
• Sự kiện: Power-off PE1 · Điều cần quan sát: Remote withdrawal, CE detection · Nguyên nhân nghi ngờ nếu fail: Timer, graceful behavior, stale state
• Sự kiện: PE1 trở lại · Điều cần quan sát: DF reelection, MAC relearn, duplication · Nguyên nhân nghi ngờ nếu fail: Startup ordering hoặc split-horizon

Một bài chạy chỉ được đánh dấu hợp lệ khi trigger có timestamp, trạng thái trước lỗi đã đạt baseline và không có lỗi ngoài phạm vi. Nếu traffic generator, capture hoặc đồng hồ gặp sự cố, lần chạy phải bị loại thay vì sửa số liệu thủ công.

• Lưu cấu hình, version, topology, inventory cổng và trạng thái thời gian.
• Xác nhận underlay reachability, MTU, BFD/IGP/BGP và không có loss nền.
• Xác nhận ESI, ES route, DF state, MAC table và LAG ở baseline.
• Chạy known unicast hai chiều; đo throughput, latency, loss, duplicate.
• Chạy BUM có kiểm soát; kiểm tra DF forwarding và split-horizon.
• Tăng số flow theo các bậc; lưu phân phối trên PE và member LAG.
• Chèn từng lỗi trong ma trận, giữ offered load và profile không đổi.
• Tương quan event log với sequence/timestamp của packet.
• Phục hồi, chờ trạng thái ổn định, kiểm tra stale MAC/route và chạy lại.
• Lặp tối thiểu theo kế hoạch thống kê; báo cáo median, p95 và worst case.

Loss khi failover không tự động chứng minh lỗi EVPN. CE có thể dùng timer LACP chậm, underlay chưa hội tụ, ACL chặn BFD, hoặc traffic chỉ có một flow nên bám vào member vừa mất. Duplicate có thể do capture tại hai điểm rồi gộp sai, SPAN oversubscription hoặc chính DUT. Quy trình triage cần bắt đầu bằng timeline và packet identity, sau đó mới quy lỗi cho lớp giao thức.

Kết quả chỉ có hiệu lực với model, phiên bản, topology, timer và traffic profile đã ghi. Không suy rộng từ một cặp PE sang toàn fabric, từ một VLAN sang mọi service, hay từ shutdown có kiểm soát sang power loss. RFC mô tả hành vi giao thức nhưng không cam kết latency hội tụ; con số pass/fail phải đến từ SLA và điều kiện đo của dự án.

• Ethernet Segment (ES): Tập link kết nối một site/CE tới một hay nhiều PE EVPN.
• ESI: Định danh Ethernet Segment dùng trong control plane EVPN.
• Designated Forwarder (DF): PE được chọn để chuyển một số loại lưu lượng tới segment, đặc biệt liên quan BUM.
• All-active: Nhiều PE/link có thể chuyển lưu lượng đồng thời theo hành vi triển khai.
• Split-horizon: Cơ chế ngăn frame học/nhận từ một ES bị phản xạ trở lại cùng ES.
• Mass-withdraw: Cơ chế rút nhanh reachability liên quan một Ethernet Segment khi lỗi.
• MAC mobility: Xử lý khi một MAC xuất hiện qua PE/ES khác, thường kèm sequence.